Update: Ryan Andorfer has posted some good information over at the Building Clouds blog on his experience with continuous running SMA monitors, some issues encountered, and how he has mitigated these issues. Check it out here - Automation - MVP Spotloght Series - SMA: DFS Share Creation Request Walkthrough In Depth .
Introduction: One of the more popular use cases I’ve encountered with System Center Orchestrator is the scenario where in a Monitor Alert (SCOM) activity is used to trigger automation as the result of a detected alert. A simplified yet practical example as seen in System Center Orchestrator may look like the following:
Parent Runbook monitors for alert. Once the alert is detected a child or component Runbook is invoked to perform some automated inspection / remediation. In the case of this example, the received alert indicates that the Print Spooler service has stopped on at least one monitored computer.
During the component or child Runbook the SCOM alert may be updated (resolution stated set to acknowledged), the print spooler examined, and an attempt made to start said service. Finally if the service cannot be started, an incident is raised in System Center Service Manager.
Again, this is an overly simplified example but will serve well conceptually for this post.
How then can we replicate this type of monitoring in System Center Orchestrator: Service Management Automation (SMA)?
You may have noticed that there is no native SMA activity for SCOM monitoring. Further more, because we need to write SMA automations using PowerShell workflows, the moitoring solution may not be obvious (at least is was not for myself).
During this blog posting I will be detailing how to replicate the behavior of the above Orchestrator Runbooks with Orchestrator SMA.
SMA and Monitoring:
Simply said, at this point, in order to achieve this type of monitoring in Orchestrator SMA we need to craft the monitor using an SMA Runbook / PowerShell workflow. As it turns out, the solution I will be showing here (one of potentially many) was very simple to create. What I have done is to use a simple Do-While loop to craft the Monitor. The following can be used as a template for a SCORCH SMA Monitoring Runbook.
Take note of the following items:
In the following full featured example I am using a Runbook to monitor SCOM for any new alerts that match specific criteria. The Runbook completes the following:
This solution includes many different Runbooks to perform all of these automated checks and remediation's, I will only be detailing the monitor itself. A copy of the complete solution can be found here for further investigation - TechNet Gallery .
Items to Note:
Wrap Up: As seen here, while we do not have a native SCOM monitoring activity in SMA, crafting our own is not difficult and provides some neat flexibility. A little bit of PowerShell, some fundamental automation logic, and a bit of SMA / PowerShell workflow specific concepts and I’ve almost identically replicated what was being performed with SCOM monitoring in my original SCORCH Rubook solution.
Happy Automating - neilp