Introduction
This is the 3rd instalment of the Automating OpsMgr series. Previously on this series:
- Automating OpsMgr Part 1: Introducing OpsMgrExtended PowerShell / SMA Module
- Automating OpsMgr Part 2: SMA Runbook for Creating ConfigMgr Log Collection Rules
Today, I will demonstrate a rather simple runbook to create a blank management pack in the OpsMgr management group. Additional, I will also demonstrate executing this runbook not only on your On-Premise Service Management Automation (SMA) infrastructure, but also from an Azure Automation account via Hybrid Workers.
Since the Hybrid Worker is a very new component in Azure Automation, I will firstly give a brief introduction before diving into the runbook.
Azure Automation Hybrid Worker
Ever since Azure Automation was introduced, it was great solution for automating around your assets and fabric on Azure, but there was lack of capabilities of reaching out to your on-prem data centres. Last month during Microsoft Ignite in Chicago, Microsoft has announced an additional component: Hybrid Workers, which is a Azure Automation runbook worker that you can setup on a on-prem server computer. To find out more, you can watch this Ignite session recording: Automating Operational and management Tasks Using Azure Automation. and my buddy and fellow SCCDM MVP Stanislav Zhelyazkov has also written a good post on this topic: https://cloudadministrator.wordpress.com/2015/05/04/azure-automation-hybrid-worker-setup/
I am not going to go through the steps of setting up hybrid workers as Stan has already covered in his post. As Stan pointed out in his post, currently, any Integration Modules that you imported into your Azure Automation account does not get pushed out Hybrid Workers. Therefore in order to execute the New-OpsMgrMP runbook on your hybrid workers, after you’ve imported the OpsMgrExtended module in your Azure Automation account, you must also need to manually copy the module to all your hybrid worker servers. To do so:
- log on to the hybrid worker, and look up the PSModulePath environment variable. You can do so in PowerShell using $env:PSModulePath
- Copy the OpsMgrExtended module to a folder that is on the PSModulePath list. Please do not copy it to any folders that are part of your user profile. I have copied it to “C:\Program Files\WindowsPowerShell\Modules” folder.
Operations Manager SDK Connection
The “Operations Manager SDK” connection must be created in the Azure Automation account, the same way as your On-Prem SMA environment:
The server name I used is the FQDN of one of my OpsMgr management server. The user name is a service account I created in my on-prem Active Directory (I believe it’s called Legacy AD or LAD now 
). i.e. Domain\ServicecAccount. This is connection is created exactly the same as the one I created in my On-Prem SMA environment.
New-OpsMgrMP Runbook
workflow New-OpsMgrMP
{
Param(
[Parameter(Mandatory=$true)][String]$Name,
[Parameter(Mandatory=$true)][String]$DisplayName,
[Parameter(Mandatory=$false)][String]$Description,
[Parameter(Mandatory=$false)][String]$Version = "1.0.0.0"
)
#Get OpsMgr SDK connection object
$OpsMgrSDKConn = Get-AutomationConnection -Name "OpsMgrSDK_TYANG"
#Create MP
$MPCreated = InlineScript
{
#Validate MP Name
If ($USING:Name -notmatch "([a-zA-Z0-9]+\.)+[a-zA-Z0-9]+")
{
#Invalid MP name entered
$ErrMsg = "Invalid Management Pack name specified. Please make sure it only contains alphanumeric charaters and only use '.' to separate words. i.e. Your.Company.Test1.MP."
Write-Error $ErrMsg
} else {
#Name is valid, creating the MP
New-OMManagementPack -SDKConnection $USING:OpsMgrSDKConn -Name $USING:Name -DisplayName $USING:DisplayName -Description $USING:Description -Version $USING:Version
}
Return $MPCreated
}
If ($MPCreated)
{
Write-Output "Management Pack `"$Name`" created."
} else {
Write-Error "Unable to create Management Pack `"$Name`"."
}
Write-Output "Done."
}
The runbook in Azure Automation and SMA is exactly identical. Please note I have configured the Operations Manager SDK connection name to be identical on Azure Automation and SMA. you will need to update Line 11 of this runbook to the name of the connection you’ve created:
Executing the runbook on SMA:
Fill out the required parameters. the parameter “Version” is configured as optional in the runbook (with default value of “1.0.0.0”), so I did not enter a version number in that field:
Result:
And you can then see the management pack in OpsMgr operational console:
Executing Runbook on Azure Automation via Hybrid Worker:
Fill out the input parameters and select “Hybrid Worker”. As you can see, the default value for “Version” parameter has already been prepopulated in the Azure portal:
Result:
And then the management pack appeared in OpsMgr operational console:
Conclusion
This is a rather simple runbook sample, the key to this runbook is the “New-OMManagementPack” activity from the OpsMgrExtended module.
For those who do not have SMA in their environment, I have just demonstrated how to leverage Azure Automation and Hybrid Workers to perform the same activities. As shown in Stan’s blog post, it’s rather easy to setup a Hybrid Worker in your environment, all you need is a Windows server with Internet connection. Unlike SMA, you do not need any database servers for Hybrid Workers.
I’d also like to point out, even if you have not opened an Azure Automation account yet, I strongly recommend you to do so and give it a try. You can go on a free tier, which gives you 500 job minutes a month. For testing and up skilling purposes, this is more than enough!
Lastly, if you would also like to see the ability to automatically push out custom modules to Hybrid workers in the future, Please help me and vote this idea in Azure user voice:
Leave a comment