If you want to learn technologies which are strategic to the Microsoft direction I recommend three: PowerShell, SMA and WAP. To quote Pete Zerger from a couple of years back during SCU "Learn PowerShell". Pete’s statement was simple, straight to the point and absolutely correct. WAP is the Windows Azure Pack for Windows Server which I personally summarize as your own Azure interface running on prem. SMA is Microsoft Service Management Automation which I personally summarize as a PowerShell based workflow engine running in WAP. During a recent client engagement we identified a process which we needed to develop which would automate the synchronization of management packs between different management groups in Operations Manager. To make this solution usable going forward we decided to use PowerShell.
Normally I as an Operations Manager person would have now dived into how to create a management pack which would use PowerShell to perform these actions. From my own history, embedding PowerShell scripts in Operations Manager is possible but not easy as you can’t run a PowerShell script directly from the Operations Manager console authoring experience. Additionally, the key functionality that is needed here isn’t to monitor something but rather to automate a something. While Operations Manager can perform automation (such as recoveries and diagnostics on monitors, tasks, and such) it is designed primarily for monitoring not automation. Orchestrator and SMA are designed to provide automation and since this is a PowerShell based solution anyways it sounds like it’s time to learn some SMA!
Luckily my colleague had already blogged the installation process for SMA in a lab which I used to install my SMA server. His instructions are available here: https://www.catapultsystems.com/mdowst/archive/2013/10/21/service-management-automation-lab-step-by-step-install.aspx which I used almost exactly as he described (other than using a remote SQL server in my lab instead of installing a local SQL server).
The big question once installing SMA was how to use what’s available to perform a simple runbook action. Luckily it appears that Microsoft considered this and made the path to perform these actions pretty straightforward.
Navigating the SMA user interface:
Upon opening the SMA portal, in the automation section under runbooks
And scroll down to the Sample-Managing-OperationsManager area shown below.
The sample-managing-operationsmanager script is shown below which connects to OperationsManager by a connection named "SCOM_Connection".
Creating a connection to Operations Manager:
Similarly to Orchestrator, we need to tell SMA where the Operations Manager server is. To do this we open automation, assets and add a setting.
We choose to add a connection as shown below.
And then we configure the connection type as OperationsManager and we name it as identified in the PowerShell script earlier "SCOM_Connection".
Next we configure the connection properties with the name of the computer, the account and password which will be used to communicate with OperationsManager (this is a lab screenshot as you can see, you wouldn’t want to use the administrator account in production of course).
Running the sample runbook:
Once we have created the connection, we can start the runbook!
The output was shown below which was details for the active alerts in the Operations Manager environment.
We can match this text to the active alerts in Operations Manager as shown below.
To see what the script does a quick read-through shows that this sample script is getting the active alerts with a resolution state of 0 (new).
So just to prove that this is not just smoke and mirrors, I acknowledge all alerts other than the one shown below in Operations Manager and re-ran the SMA runbook.
The output was what we expect – the details for the one alert still in new status in Operations Manager.
Scheduling the runbook:
Scheduling these runbooks are easy to accomplish which is the last piece of the equation needed to use this type of integration for what I am looking to develop (the script to automate the synchronization of management packs between different management groups in Operations Manager). From the runbook we can use the scheduling tab:
To add a new schedule for the runbook we give it a name and configure the schedule for it.
Summary: It only took an afternoon of work to spinning up the virtual, install SMA and run my first runbook (the majority of the time getting the virtual created on Hyper-V and installing SMA). If you haven’t already started working with SMA I highly recommend spending the time with this (and PowerShell and WAP) as they have every indication of being extremely strategic to the System Center space.