Operations Manager 2012 Integration Pack Overview for Orchestrator 2012
For those that may not be aware, System Center 2012 Orchestrator is a workflow automation tool that allows integration between heterogeneous environments. As an example, many organizations have multiple monitoring tools and need to transfer data (such as alerts) between them. Orchestrator, with the use of Integration Packs, provides the ability to facilitate this integration.
In this post I’m going to provide a general overview of the System Center 2012 Operations Manager Integration Pack for System Center 2012 Orchestrator.
The first thing we need to do is download the Integration Pack from the Microsoft Download center. All of the Integration Packs for System Center 2012 products as well as earlier products come in the form of one download which is currently found here.
Once we have the Integration Packs downloaded and extracted to the file system we can then use Deployment Manager to register and deploy the IP. I won’t review this procedure in this post as there is a fairly straight forward procedure for this on Technet which can be found here.
Before we can dive in to the activities that this IP provides for us we’ll need to perform a few steps.
1. We need to register at least one Operations Manager 2012 connection. We can do this in the Runbook Designer by going under the ‘Options’ menu and selecting ‘SC 2012 Operations Manager’. Fill in the connection information as appropriate for your environment similar to what is shown below.
2. We need to make sure we install the OpsMgr console on every server that hosts the Runbook Server or the Runbook designer. If you don’t do this you will get an error similar to the following when you try to run certain activities such as ‘Create Alert’:
Could not load file or assembly 'Microsoft.EnterpriseManagement.OperationsManager, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified
Now let’s have a look to see what this Integration Pack provides for us. I can see that there is now an ‘SC 2012 Operations Manager’ category under my Activities pane and within there are 8 pre-defined activities.
Here is a brief overview of what each one does
Create Alert |
This activity does exactly as its name describes. The properties of this activity allows us to set several alert properties such as Name, Description, Priority, Severity, and Owner as well as any of the custom fields.
Here is a screenshot of the alert that was generated by using this activity
Notice that the Alert generating rule is
Microsoft.SystemCenter.Orchestrator.Integration.Library.AlertOnEventForComputer.
This is a rule that exists in the ‘Microsoft System Center Orchestrator Integration Library’ MP that you likely didn’t import yourself. The first time an activity runs that needs this MP then it will import it for you in to your OpsMgr environment.
Also note my artistic blacking out of sensitive information such as my server hostname. I have yet to master the art of the straight line within the Snipping Tool.
Get Alert |
This activity does exactly as its name describes as well. It retrieves alert data that matches the criteria you select. The criteria you can select for retrieving alerts is actually quite extensive and you can select multiple criterion as well as shown in the screen shot below
You would probably not use this activity for proactively looking for new alerts that have occurred in a time sensitive manner. The ‘Monitor Activity’ activity would be a better choice for that. A better use of this activity would be to use this in a regularly scheduled Runbook that retrieves alert data and takes some sort of maintenance action upon them.
For instance, you could use this activity in a Runbook that retrieves all warning alerts that are older then ‘x’ amount of days and increase the severity to critical using the ‘Update Alert’ activity.
Get Monitor |
This activity is used to retrieve information from a specific monitor or set of monitors that match specified filter criteria. This information can be used in many ways such as input to a corrective action or as input to a problem incident in another tool.
Monitor Alert |
This activity has nothing really to do with monitors in Operations Manager terminology. It is actually used to detect new or updated alerts so that they can be used as input for some other action when they occur. The detected alert can be generated by a rule or a monitor.
It is similar to ‘Get Alert’ but it is a better candidate for proactively taking action upon the occurrence of an alert being generated. For instance, you could use this to trigger some sort of corrective action that should occur when that alert occurs. The criteria for which alerts are detected is quite extensive and is similar to those for the ‘Get Alert’ activity.
Monitor State |
This activity is used to retrieve information about an Operations Manager object when the Health State of that object enters a specific state. For example, a Logical Disk object in Operations Manager that changes to a Critical state.
This information can then be passed to additional automation such as a procedure for grooming log files.
This activity accepts the name of the Object and health state to be monitored as parameters.
Start Maintenance Mode |
This activity does exactly as its name describes and shouldn’t need further explanation about when this would be used. I will point out however one interesting thing about the interface and documentation that I don’t necessarily agree with. As shown below the interface asks you to select a ‘Monitor’ to place in to Maintenance Mode. This is not accurate as we don’t actually place monitors in to Maintenance Mode within Operations Manager. Instead, we place monitored objects in to Maintenance Mode.
When you click the Ellipsis it actually gives you a list of monitored objects and not monitors
Stop Maintenance Mode |
Much like the ‘Start Maintenance Mode’ activity this one is self-explanatory. Again though, ‘Monitor’ here should mean ‘Monitored Object’.
Update Alert |
This activity does exactly as its name describes as well. You use the Alert ID to determine which Alert to update and you can choose to update the Owner, ResolutionState, TicketId or any of the Custom Fields in the Alert properties. This would be most useful if proceeded by another Activity such as ‘Get Alert’ to first retrieve an alert. This way there is an Alert ID in the published data for you to use as criteria for this activity.
This has been a very high-level overview of the System Center 2012 Operations Manager Integration Pack for System Center 2012 Orchestrator. For more detailed information about these activities you can refer to the official TechNet documentation found here.
In an upcoming post, I will use some of these activities in some real-world scenarios to help illustrate their potential use further.
Comments
- Anonymous
February 28, 2014
Every business leader has found themselves, at one time or another, dealing with something unforeseeable - Anonymous
May 20, 2014
Pingback from Success with Hybrid Cloud: By Scenario ??? Cloud Bursting | Dot Net RSS