In part 1 of the OMS Automation series I reviewed how to configure the Hybrid Runbook Worker to run Azure Automation against on-premises servers, specifically OpsMgr (here). Additionally, we covered how to import and configure an existing Azure Automation integration module on the Hybrid Worker agent and in Azure Automation, and then demonstrated how to execute a workflow using the module. In part 2 of the series, I will dig a little deeper and demonstrate how to create a custom Azure Automation Runbook and execute the workflow against OpsMgr on-premises using the native OpsMgr PowerShell cmdlets. Let’s get started!
The first step is to install the Operations Manager PowerShell Module on the Hybrid Runbook Worker. The easiest way to accomplish this is to install the OpsMgr console on the server. However, there are a few posts that outline how to work around installing the console by manually copying the SDK binaries to the Global Assembly Cache on the server and copying the Operations Manager PowerShell module folder from the OpsMgr installation directory on a management server to a directory at the same path on the Worker agent (Details in Stefan Roth’s blog here) . In my testing, I simply installed the console, and after a bit of testing, I’ve found 2 configuration methods where Azure Automation Runbooks executed successfully.
- Install the OpsMgr console on the Hybrid Runbook Worker and copy the Operations Manager directory from c:\Program Files\System Center 2012\Operations Manager\PowerShell to c:\Windows\System 32\Windows PowerShell\v1.0\Modules. To verify, once I confirmed that the Runbooks were executing successfully, I removed the Operations Manager PowerShell module from this location and attempted to rerun the Runbooks. With the module removed, the workflow failed to import the Operations Manager module causing the Runbook to fail.
- Create an Azure Automation Variable Asset which defines the default path to the Operations Manager PowerShell module. Using this method, I was able to hard code the path to the OperationsManager.psm1 module (C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\\PowerShell\OperationsManager\OperationsManager.psm1) in an Azure Automation variable Asset and call this variable as part of my workflow. I will demonstrate this process in detail below.
Since I chose option number 1 in Part 1 of this series, I will go with option 2 and create a variable Asset in Azure Automation and call the variable in my workflow to import the Operations Manager PowerShell module from the default installation path.
- Log into to the Azure portal at https://portal.Azure.com.
- Navigate to the Assets blade at Automation Accounts –> [Account] –> Assets (1,2).
- From the Assets blade, select Variables (3).
- Select the New Variable button (1).
- Fill out the Name, Description, and Path fields and press Create (2).
Now that we have our variable configured, let’s create a workflow! In this example, I will create a Runbook to remove the management pack which we created in part 1, but this time I will utilize the native OpsMgr cmdlets.
- Navigate to the Runbooks blade (1).
- Select Add A Runbook –> Quick Create (2,3).
- Fill out the Runbook fields and select PowerShell Workflow from the Runbook Type drop down list (4).
- When you select the Create button, you will be redirected to the Edit page. This is where we will configure the workflow.
- For the purpose of this post, I have pasted the full code and broken down most of the PowerShell workflow specific aspects. The first section defines the parameters and the connection variables.
- The second section is where the OpsMgr PowerShell cmdlets are executed. PowerShell cmdlets and scripts must be executed within an InlineScript script block. You can read more about InlineScript here.
- Before we execute this workflow, let’s verify that the OMS Test management pack exists.
- Ok, let’s see how this looks when we execute if from the Azure Automation console. The parameter fields correlate to the Connection and MP we created in Part 1 of this series. Simply fill in those values, select Hybrid Worker to execute the workflow against the on-premises OpsMgr management group, and choose the Hybrid Worker group created when registering the Hybrid Runbook Worker via PowerShell.
- The output should look like this if everything ran correctly.
- Let’s spot check the console to see if the management pack has been removed.
- Awesome! Our management pack has been successfully deleted.
That’s all for this post, stay tuned for my next post demonstrating how to use the OMS Search API and OpsMgr to collect log files and used saved search queries to trigger Azure Automation Runbooks.