TIP: Keep your Azure Automation runbooks healthy across PowerShell module updates

Here’s a quick tip that may help you ensure you’re protect yourself from a problem that happens occasionally.

Problem: I had a runbook that was broken when the PowerShell modules in the store were updated.

Solution: What can you do to prevent this problem? One thing you can do to protect yourself against breaking changes in new versions of PowerShell moduels is to configure your runbook to run on a schedule. Once schedule is created, that runbook will always run with the modules that were in the store at the time of the schedule creation.

Get a deep dive on Azure Automation in our comprehensive book on the Microsoft Operations Management Suite (OMS), which is available free on the TechNet Gallery or if you prefer, for a small price in paperback and Kindle formats on Amazon.com.

Creating ConfigMgr Console Folders and Collections with PowerShell

Below for reference a quick PowerShell sample for creating a query-based device collection in System Center Configuration Manager (ConfigMgr), as well as a new folder for organizing collections in the ConfigMgr Admin console. The script then moves the new collection to the new folder. Additionally, there is demonstration of some of the options you can supply to control collection population and refresh behavior.

You can download the up-to-date ConfigMgr PowerShell cmdlets at https://www.microsoft.com/en-us/download/details.aspx?id=46681.

The ConfigMgr PowerShell cmdlet reference documentation is available at https://technet.microsoft.com/en-us/library/jj821831(v=sc.20).aspx.

Sample script for device collections

# Import ConfigMgr PowerShell module 
Import-Module $env:SMS_ADMIN_UI_PATH.Replace("\bin\i386","\bin\configurationmanager.psd1")

# Change to ConfigMgr drive, where HOU is your site code
$SiteCode = Get-PSDrive -PSProvider CMSITE
Set-Location "$($SiteCode.Name):"

# Create schedule for refreshing collection membership
$MonSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Monday -RecurCount 1
 
# Create a new admin folder
New-Item -Name 'Server Collections' -Path "$($SiteCode.Name):\DeviceCollection"

# Define device collection we will create 
# If you want to enable incremental updating on the Collections, you can set the –RefreshType to 'Both'. 
New-CMDeviceCollection -Name "Pete Servers" -LimitingCollectionName "All Systems" `
-RefreshSchedule $MonSched -RefreshType Periodic

# Define query rule for my collection 
Add-CMDeviceCollectionQueryMembershipRule -CollectionName "Pete Servers" `
-QueryExpression "select * from SMS_R_System where SMS_R_System.SystemGroupName = 'CONTOSOCORP\\Pete Servers'" `
-RuleName "PeteServerQueryRule"

#Get my new collection by name 
$MyCollection = Get-CMDeviceCollection -Name 'Pete Servers'

# Move my new collection to the new admin folder
Move-CMObject -InputObject $MyCollection -FolderPath "$($SiteCode.Name):\DeviceCollection\Server Collections"

Questions or comments? Use the comments section below.

Creating ConfigMgr User Collections with PowerShell

Below for reference a quick PowerShell sample for creating a query-based user collection in System Center Configuration Manager (ConfigMgr), along with a demonstration of some of the options you can supply to control collection population and refresh behavior.

You can download the up-to-date ConfigMgr PowerShell cmdlets at https://www.microsoft.com/en-us/download/details.aspx?id=46681.

The ConfigMgr PowerShell cmdlet reference documentation is available at https://technet.microsoft.com/en-us/library/jj821831(v=sc.20).aspx.

Sample script for user collections

# Import ConfigMgr PowerShell module 
Import-Module (Join-Path $(Split-Path $env:SMS_ADMIN_UI_PATH) ConfigurationManager.psd1) 

# Change to ConfigMgr drive, where HOU is your site code
cd ‘c:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin’
Set-Location HOU:

# Create schedules for refreshing collection membership
$MonSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Monday -RecurCount 1
$TueSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Tuesday -RecurCount 1
$WedSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Wednesday -RecurCount 1
$ThuSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Thursday -RecurCount 1
$FriSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Friday -RecurCount 1
$SatSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Saturday -RecurCount 1
$SunSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Sunday -RecurCount 1

# Define user collection we will create 
# If you want to enable incremental updating on the Collections, you can set the –RefreshType to 'Both'. 
New-CMUserCollection -Name "Accounting Users" -LimitingCollectionName "All Users" `
-RefreshSchedule $MonSched -RefreshType Periodic

# Define query rule for my collection 
Add-CMUserCollectionQueryMembershipRule -CollectionName "Accounting Users" `
-QueryExpression "select * from SMS_R_User where SMS_R_User.UserGroupName = 'CONTOSO\\Accounting'" `
-RuleName "AcctingUsersQueryRule"

Questions or comments? Use the comments section below.

Creating ConfigMgr Device Collections with PowerShell

Below for reference a quick PowerShell sample for creating a query-based device collection in System Center Configuration Manager (ConfigMgr), along with a demonstration of some of the options you can supply to control collection population and refresh behavior.

You can download the up-to-date ConfigMgr PowerShell cmdlets at https://www.microsoft.com/en-us/download/details.aspx?id=46681.

The ConfigMgr PowerShell cmdlet reference documentation is available at https://technet.microsoft.com/en-us/library/jj821831(v=sc.20).aspx.

Sample script for device collections

# Import ConfigMgr PowerShell module 
Import-Module (Join-Path $(Split-Path $env:SMS_ADMIN_UI_PATH) ConfigurationManager.psd1) 

# Change to ConfigMgr drive, where HOU is your site code
cd ‘c:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin’
Set-Location HOU:

# Create schedules for refreshing collection membership
$MonSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Monday -RecurCount 1
$TueSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Tuesday -RecurCount 1
$WedSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Wednesday -RecurCount 1
$ThuSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Thursday -RecurCount 1
$FriSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Friday -RecurCount 1
$SatSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Saturday -RecurCount 1
$SunSched = New-CMSchedule -Start "01/01/2017 10:00 PM" -DayOfWeek Sunday -RecurCount 1

# Define device collection we will create 
# If you want to enable incremental updating on the Collections, you can set the –RefreshType to 'Both'. 
New-CMDeviceCollection -Name "Pete Servers" -LimitingCollectionName "All Systems" `
-RefreshSchedule $MonSched -RefreshType Periodic

# Define query rule for my collection 
Add-CMDeviceCollectionQueryMembershipRule -CollectionName "Pete Servers" `
-QueryExpression "select * from SMS_R_System where SMS_R_System.SystemGroupName = 'CONTOSOCORP\\Pete Servers'" `
-RuleName "PeteServerQueryRule"

Questions or comments? Use the comments section below.

Optimized Group Maintenance Mode PowerShell for OpsMgr: 2012 R2 Edition

Below is the latest sample of optimized group maintenance mode for System Center Operations Manager (SCOM), which leverages the .ScheduleMaintenanceMode function, which allows for the inclusion of a request for recursion….the implementation of the “this object and contained objects”. This minimizes SDK calls and processing overhead for large groups.

Syntax:
GroupMaintMode -ScomServer “mmsscom01” -GroupDisplayName “SQL Server 2008 Computers” -DurationInMin 10 -Reason “ApplicationInstallation” -Comment “Scheduled weekly maintenance”

#--------Begin Sample Script----------------
#*****************************************************************************
#
# Name: OpsMgr 2012 Group Maintenance Mode 
#
# Description: Puts Groups into Maintenance Mode 
#
# Authors: Pete Zerger and Matthew Long  
#
# Parameters:
#
# -ScomServer: mandatory parameter containing mgmt server name (Netbios or FQDN)
# -GroupDisplayName: mandatory parameter containing display name of the target group
# -DurationInMin: mandatory parameter containing integer of desired duration in minutes
# -Reason: mandatory parameter containing reason. Acceptable values are UnplannedOther, 
#           PlannedHardwareMaintenance, UnplannedHardwareMaintenance,

#           PlannedHardwareInstallation, 
#           UnplannedHardwareInstallation, PlannedOperatingSystemReconfiguration, 
#           UnplannedOperatingSystemReconfiguration, PlannedApplicationMaintenance, 
#           ApplicationInstallation, ApplicationUnresponsive, ApplicationUnstable, 
#           SecurityIssue, LossOfNetworkConnectivity
# -Comment: optional parameter with free text description of your choice
#
#
#*****************************************************************************

Function GroupMaintMode 
#($ScomServer, $GroupDisplayName, $DurationInMin, $Reason, $Comment)
(
[Parameter(Mandatory=$true)][string]$ScomServer,
[Parameter(Mandatory=$true)][string]$GroupDisplayName,
[Parameter(Mandatory=$true)][Int32]$DurationInMin,
[Parameter(Mandatory=$true)][string]$Reason,
[Parameter(Mandatory=$false)][string]$Comment
){

Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName $ScomServer

ForEach ($Group in (Get-ScomGroup -DisplayName  $GroupDisplayName))
    {
   If ($group.InMaintenanceMode -eq $false)
         {
            $group.ScheduleMaintenanceMode([datetime]::Now.touniversaltime(), `
            ([datetime]::Now).addminutes($DurationInMin).touniversaltime(), `

             "$Reason", "$Comment" , "Recursive")
         }
    }

}

#Usage (calling the GroupMaintMode function)
GroupMaintMode -ScomServer "mmsscom01" -GroupDisplayName "SQL Server 2008 Computers" `
-DurationInMin 10  -Reason "ApplicationInstallation" -Comment "Scheduled weekly maintenance"

#--------End Sample Script----------------

#Usage (calling the GroupMaintMode function)
GroupMaintMode -ScomServer "mmsscom01" -GroupDisplayName "SQL Server 2008 Computers" `
-DurationInMin 10  -Reason "ApplicationInstallation" -Comment "Scheduled weekly maintenance"

#--------End Sample Script----------------

Questions or comments? Use the comments section below.

Cloning OpsMgr Notification Subs with PowerShell: 2012 R2 Edition

The following is the latest version of my script for cloning notification subscriptions in System Center Operations Manager 2012 R2.

The critical components to copy, all of which are hanlded by this script, are:

  • Group Filters
  • Class Filters
  • Criteria (severity, priority and other details…everything else basically)

You’ll also need to copy:

  • Notification Channel (this sample assumes you’re using SMTP)
  • Recipients (this example assumes only To: recipients, but cc: and bcc: would be very easy to add with the sample below)
Function CloneOMSub($SourceSubName, $TargetSubName) {
 
#Connect to the SCOM 2012 Server 
$ScomServer = 'mmsscom01'
Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName $ScomServer
 
#----------------------------------------------------
# Clone parameters from the existing subscription: 
# Recipients, Class Filters, Group Filters, Criteria 
#----------------------------------------------------
 
$TemplateSub = Get-SCOMNotificationSubscription -DisplayName $SourceSubName
$TemplateToRecipients = $TemplateSub.ToRecipients
$TemplateCriteria = $TemplateSub.Configuration.Criteria
$TemplateClassTargets = $TemplateSub.Configuration.MonitoringClassIds | select `
-ExpandProperty Guid
$TemplateGroupTargets = $TemplateSub.Configuration.MonitoringObjectGroupIds | select `
-ExpandProperty Guid
$TemplateChannel = $TemplateSub.Actions | select -ExpandProperty DisplayName
 
#Retrieve SMTP Channel used by existing subscription
$Channel = Get-SCOMNotificationChannel -DisplayName $TemplateChannel
 
#Create new subscription 
Add-SCOMNotificationSubscription -Name $TargetSubName -Channel $Channel -Subscriber `
$TemplateToRecipients -Criteria $TemplateCriteria
 
#Retrieve new subscription and update with Class and Group Targets
$NewSubscription = Get-SCOMNotificationSubscription -DisplayName $TargetSubName
$NewSubscription.Configuration.MonitoringClassIds.Add( $TemplateClassTargets )
$NewSubscription.Configuration.MonitoringObjectGroupIds.Add( $TemplateGroupTargets )
$NewSubscription.Update() 
}

You have to call the function with a single line of code right below the function itself in the script. It is worth noting that I found behavior to be pretty inconsistent when I used subscriptions with spaces in the name.

SYNTAX:

The script requires two arguments, the display name of the source subscription followed by the display name of the target copy.

CloneSub <SourceSubscription> <TargetSubscription>

For example:

CloneOMSub "Critical_SQL_Alerts" "SQL_Escalation_Sub"

Questions or comments? Use the comments section below.

OpsMgr Overrides Report: 2012 R2 Edition

The following is latest tweak of my custom Overrides Report for System Center Operations Manager 2012 R2:

# ==============================================================================================
#
# NAME: OpsMgr Overrides Report
#
# ORGINAL AUTHOR: Daniele Muscetta and Pete Zerger
# ORGINAL DATE : 8/24/2010
#
# EDITED BY: Arjan Vroege
# EDITED DATA : 1/24/2014
#
# COMMENT: This report will output the overrides in your OpsMgr environment including
# override settings, target, source rule/monitor and source management pack.
# ==============================================================================================
#---Save the following text as script "Export-Overrides.ps1"

#Parameters
Param(
[Parameter(Mandatory=$true)] [string]$MS,
[Parameter(Mandatory=$true)] [string]$MP_Name,
[Parameter(Mandatory=$true)] [string]$output
)

#Connect to SCOM Environment
Import-Module OperationsManager
New-SCOMManagementGroupConnection -ComputerName $MS

#define the path you want to export the CSV files to
$exportpath = ""
$MPRpt = $null
$MPRows = $null

#gets all UNSEALED MAnagement PAcks
$mps = Get-SCOMManagementpack | where {$_.DisplayName -eq $MP_Name}

#loops thru them
foreach ($mp in $mps) {
$mpname = $mp.name
Write-Host "Exporting Overrides info for Management Pack: $mpname"

#array to hold all overrides for this MP
$MPRows = @()

#Gets the actual override objects
$overrides = $mp.GetOverrides()

#loops thru those overrides in order to extract information from them
foreach ($override in $overrides) {
#Prepares an object to hold the result
$obj = new-object System.Management.Automation.PSObject

#clear up variables from previous cycles.
$overrideName = $null
$overrideProperty = $null
$overrideValue = $null
$overrideContext = $null
$overrideContextInstance = $null
$overrideRuleMonitor = $null

#give proper values to variables for this cycle. this is what we can then output.
$name = $mp.name
$overrideName = $override.Name
$overrideProperty = $override.Property
$overrideValue = $override.Value

trap { $overrideContext = ""; continue } $overrideContext = $override.Context.GetElement().DisplayName
trap { $overrideContextInstance = ""; continue } $overrideContextInstance = (Get-SCOMClassInstance -Id $override.ContextInstance).DisplayName

if ($override.Monitor -ne $null) {
$overrideRuleMonitor = $override.Monitor.GetElement().DisplayName
} elseif ($override.Discovery -ne $null) {
$overrideRuleMonitor = $override.Discovery.GetElement().DisplayName
} else {
$overrideRuleMonitor = $override.Rule.GetElement().DisplayName
}

#fills the current object with those properties

#$obj = $obj | add-member -membertype NoteProperty -name overrideName -value $overrideName -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideProperty -value $overrideProperty -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideValue -value $overrideValue -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideContext -value $overrideContext -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideContextInstance -value $overrideContextInstance -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideRuleMonitor -value $overrideRuleMonitor -passthru
$obj = $obj | add-member -membertype NoteProperty -name MPName -value $name -passthru
$obj = $obj | add-member -membertype NoteProperty -name overrideName -value $overrideName -passthru

#adds this current override to the array
$MPRows = $MPRows + $obj
}

#Store up the overrides for all packs to a single variable
$MPRpt = $MPRpt + $MPRows
}

if($output -eq "csv") {
#exports cumulative list of overrides to a single CSV
$filename = $exportpath + "overrides" + $mp.name +".csv"
$MPRpt | Export-CSV -path $filename -notypeinfo
} elseif ($output -eq "html") {
$filename = $exportpath + "overrides" + $mp.name +".htm"
$MPRpt | ConvertTo-Html | Out-File $filename
}

Questions or comments? Use the comments section below.

Launch an OMS Automation Runbook on a Hybrid Worker from Orchestrator

While the Operations Management Suite (OMS) and Azure Automation are the future of process automation, there are still many customers still using System Center Orchestrator (SCO). In fact, when polling audiences I have spoken to in the last six months, they are still the majority. For customers taking their first step into hybrid cloud automation, often OMS Automation and the Hybrid Runbook Worker are that first step (OMS enables the Hybrid Runbook Worker capability for Azure Automation).

A few users have asked how to trigger Azure Automation runbooks from Orchestrator, so I thought it was time to write up a quick how-to on the easy way to meet the need. While webhooks are a great tool, only people with the URL can use it, and passing that URL around to multiple teams via e-mail and the like may be less desirable than simply letting authorized teams in your org use their Azure credentials with delegated permissions. So we will look at triggering the runbook directly in this installment.

If you want to launch an Azure Automation runbook on a Hybrid Runbook Worker from System Center Orchestrator, here is the easy way complete the task in three steps, including a parameterized PowerShell script to use in your first runbook.

Step 1: Configure Orchestrator to use the latest version of PowerShell

By default, Orchestrator wants to use an ancient version of PowerShell (v2), where you cannot successfully load the Azure PowerShell module. While you could result to more complex PowerShell scripts to work around this, MS has provided an unadvertised registry key in System Center Orchestrator that you can use to work around this. This eliminates the need for any complexity in your PowerShell script.

1. Use regedit to navigate to the following key on your runbook servers: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework

2. Add a new DWORD entry and value of: OnlyUseLatestCLR = 1

From this point on, Orchestrator will call the latest version of PowerShell. You should have PowerShell v5 if you are working with Azure Automation and OMS. I am using PowerShell 5, Azure SDK 2.9 and latest version of Azure Automation PowerShell, dated 3/30/2016.

DISCLAIMER: I have not heard from MS that this breaks the support agreement. After all, they are the ones who put the registry key there! I do know there are at least a few companies using this in production today. If concerned, always check with Microsoft directly.

Step 2: Add credentials as variables

In figure 1, you will see I have added Azure logon credentials as variables in Orchestrator. Make sure to add your password as an encrypted variable, so it is not visible to others, as shown in the image below. Also, make sure to use credentials from your Azure AD instance. Authentication with a Microsoft (Live) account via Azure PowerShell will fail.

SCO variables

Figure 1. Azure subscription username and password

Step 3: Add sample script in SCO

Here is the sample script, which you will add to a Run .Net Script activity in Orchestrator, as pictured below. Notice in the images below I have also replaced the hard-coded values of the variables for Azure user and password, as well as the Hybrid Worker Group with the appropriate script variables and parameters. I have also replaced the one parameter of a simple ‘Hello World’ Azure Automation runbook (the ‘Message’ parameter), which accepts the message of your choice and logs it to a HelloWorld.txt file on the Hybrid Worker where it runs. There are several ‘Hello World’ examples for Azure Automation available (such as this from TechNet Gallery), so grab one for testing.

TIP: By making Hybrid Worker Group a parameter in your SCO runbook, you can effectively trigger an Azure Automation runbook on hybrid workers in any datacenter in the world from a single Orchestrator instance! You will see how this is done in figures 3 and 4 below.

SCO Runbok

Figure 2. Sample SCO runbook for calling our Azure Automation runbook on a hybrid worker.

Here is a simple PowerShell script you can use in Orchestrator to trigger a runbook in your Azure Automation account. Make sure to update the value of the -AutomationAccountName in the last line of the script as well!

# Import Azure Modules
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\AzureRM.Profile\AzureRM.Profile.psd1"
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\AzureRM.Automation\AzureRM.Automation.psd"

# Authenticate with Azure AD credentials
$MyUserName=’username@yourdomain.onmicrosoft.com’
$MyClearTextPassword=’YourPassword’

# Hybrid Worker Pool
$HRWPool = 'ConfigMgrPool'
$SecurePassword=Convertto-SecureString –String $MyClearTextPassword –AsPlainText –force

$cred=New-object System.Management.Automation.PSCredential $MyUserName,$SecurePassword

Login-AzureRmAccount -Credential $cred

#Runbook parameters
$params = @{"Message"="Hello Azure Community!";}

Start-AzureRmAutomationRunbook –AutomationAccountName "contoso-testrba" –Name "Hello-World" `
-ResourceGroupName 'Default-Networking' –Parameters $params -RunOn 'ConfigMgrPool'

Notice I have replaced the values of the aforementioned hard-coded parameters, as shown in figure 4 below.

SCO Runbook Params

Figure 3. SCO Runbook Parameters

Paramized_SCO_Runbook

Figure 4. Parameterized PowerShell script in Orchestrator (Run .NET Script activity)

Step 4: Test Your SCO Runbook

To test my configuration, I’ll use the Orchestrator Runbook Tester. Once I see success reported in the Runbook Tester, I will then check Azure Automation and the HelloWorld.txt on the Hybrid Runbook Worker as an initial end-to-end validation my solution is working as intended.

Trigger Runbook

 Figure 5. Testing the runbook from the Orchestrator Runbook Tester

About 3 minutes after I started the job, I see a completed message in the Jobs area of my Azure Automation subscription, as well as an entry in HelloWorld.txt from my own Hello World runbook I use for testing.
Runbook Results

Figure 6. Runbook successfully triggered in Azure Automation and run on Hybrid Worker

That’s it for this installment. Let me know if you struggle with any of the above or have questions. Good luck!

5 TIPS FOR MODERNIZING YOUR PROCESS AUTOMATION STRATEGY

Don’t get me wrong, I love System Center Orchestrator (as you will see here AND here), but it is important to know when it is time to move on. Well my friends, it’s time. Some months ago now, Microsoft publicly announced that their investment in new features Orchestrator had come to an end, and that a cloud-first strategy would be the norm. The Microsoft Operations Management Suite (OMS), together with Azure Automation, is actually the bridge for organizations wishing to modernize their automation strategy,..even organizations not quite ready to go “all-in” with Microsoft Azure.

In this article, I will share five tips to help optimize your journey in modernizing your process automation strategy.

Tip #1: Don’t make big investments in legacy tools

Since Orchestrator is a legacy component, it is probably best not to rush into costly investments in Orchestrator-based solutions that you will only have to rewrite later. However, I am not saying not to use Orchestrator at all. If you find a runbook for free (or cheap) you can download that solves a problem, go ahead! If the development cycle is fairly short, no problem! However, think twice before spending tens of thousands of dollars on Orchestrator-based development or solutions.

“How would you suggest I move forward” you ask? Read on.

Tip #2: Don’t count on the Orchestrator Migration Toolkit to handle everything

The System Center Orchestrator Orchestrator Migration Toolkit will convert some of your runbooks, as well as your custom activities developed with the Orchestrator Integration Toolkit (OIT) to an Azure Automation / Service Management Automation (SMA) friendly format. It also provides a converted set of (most of) the standard activities from Orchestrator.  However, there are some caveats:

  • Some activities cannot be converted. For example, the Map Published Data activity, used heavily by runbook authors everywhere, cannot be converted for Azure Automation and SMA at present.
  • Activities in integration packs not created with the OIT cannot be converted.

What’s more, you may have created custom logging, checkpointing and other workarounds in your Orchestrator runbooks that are native features of Azure Automation, which you will need to write out of converted runbooks. The bottom line here is that at least some runbook redesign and rework is going to be necessary on the road to a simplified, modern process automation strategy. Embrace this reality and use it as a learning opportunity.

Tip #3: Use hybrid to take your first step…

If your organization is not yet in the cloud, walking in the door and singing the praises of an “all-in cloud strategy” may not be the best approach. Your message may not be well-received by the cloud doubters and cloud fearful in your ranks. Some of these concerns may be well-founded and may take time to overcome. This is where OMS can help, by giving you a fantastic compromise…the Hybrid Runbook Worker. Without rehashing everything explained in the hyperlinked article, the key point here is that linking OMS to an Azure Automation subscription enables you to execute Azure Automation runbooks on a server enabled as a Hybrid Runbook Worker inside your datacenter with no additional outside-in firewall ports required!

This is an olive branch with another bonus. With Hybrid Runbook Workers enabled throughout your data centers, you can Azure Automation as your centralized, simplified, global back-end orchestration infrastructure. An Orchestrator instance per-datacenter, and the headaches that come with keeping them all in sync in terms of patches, runbooks and security, are a thing of the past.

Tip #4: Don’t build what Microsoft is going to build for you

This tip is an easy one to follow. Never spend a lot of time and money building or buying a solution Microsoft promises to build for you. Watch the product roadmap for OMS, which includes a long list of Microsoft’s planned feature releases that may eliminate your need to build certain types of automation. The current public roadmap includes a host of great features, including solutions focusing on

  • Office 365
  • Patch Management
  • Remote OS Management
  • Containers
  • Network Performance and Analytics
  • Configuration Management Database

That is just the tip of the iceberg. Since OMS Is cloud-based platform, features come on a rapid release cycle…at a cloud cadence. Talk to your MS account team and focus on closing the gaps MS is not already working to close for you. This likely means you will be able to focus on more organizationally-specific, high ROI scenarios the business side of your org care about.

Talk to your Microsoft account rep for the latest OMS feature roadmap.

Tip #5: Start with a “quick win”

One important point I used to stress with Orchestrator was the need to “start small”, and the same is true with OMS and Azure Automation. To introduce your organization to hybrid automation with OMS and Azure Automation with the Hybrid Runbook Worker (and to ensure they love it), start with a manageable scenario. Find an automation need that you can develop and demonstrate in a proof-of-concept in a short time (nor more than one or two days) to get your colleagues and management stakeholders acquainted…and on board.

Before you start, look at what is already available from the community. There are lots of runbook samples out there demonstrating common scenarios like group maintenance mode in System Center Operations Manager, Active Directory user onboarding, as well as adding computers to collections in System Center Configuration Manager (SCCM). Since Azure Automation supports PowerShell, a freely available PowerShell script may help jumpstart your efforts!

Next Steps

Your first step is to get in the game. Sign up for the free tier of OMS, which includes 500 automation minutes per month. Sign up for a free Azure trial, or sign up for the pay-as-you go option to limit your spend. Watch some of OMS and Azure Automation videos on the MS Channel 9 website. Download some of the many sample runbooks shared in those sessions.

Good luck!

Free E-book: Inside the Microsoft Operations Management Suite

Tao (@MrTaoYang), Stan (@StanZhelyazkov), Anders (http://contoso.se)  and I have been working on a project for the last few weeks. We wanted to bring a learning resource for the MS Operations Management Suite to the community that is complete, comprehensive, concise…and free (as in beer). While we finish final editing passes over the next couple of weeks, we wanted to share an early copy of the book so you can start digging in while we finish our work!

Description: This preview release of “Inside the Microsoft Operations Management Suite” is an end-to-end deep dive into the full range of Microsoft OMS features and functionality, complete with downloadable sample scripts (on Github). The chapter list in this edition is shown below:

  • Chapter 1: Introduction and Onboarding
  • Chapter 2: Searching and Presenting OMS Data
  • Chapter 3: Alert Management
  • Chapter 4: Configuration Assessment and Change Tracking
  • Chapter 5: Working with Performance Data
  • Chapter 6: Process Automation and Desired State Configuration
  • Chapter 7: Backup and Disaster Recovery
  • Chapter 8: Security Configuration and Event Analysis
  • Chapter 9: Analyzing Network Data
  • Chapter 10: Accessing OMS Data Programmatically
  • Chapter 11: Custom MP Authoring
  • Chapter 12: Cross Platform Management and Automation

This early edition is being shared with the community while final edits are being completed. Please send questions, comments or errata you find to insidemscloud@outlook.com.

You can download for free from the TechNet Gallery at:
https://gallery.technet.microsoft.com/Inside-the-Operations-2928e342