From time to time, it may be found necessary to raise an alert directly into SCOM 2012 from Orchestrator. Contained within the SCOM 2012 IP is an activity named ‘Create Alert’. Per the documentation on TechNet (here), the ‘Create Alert’ activity will raise an alert into SCOM and has access to the following fields:
Ok, this seems pretty straight forward.
From the TechNet Article: The first time you run this object in a policy, it installs the Opalis Integration Library Management Pack in System Center Operations Manager. The Create Alert object creates an event in System Center Operations Manager, which the Opalis Integration Library Management Pack then translates into a System Center Operations Manager alert.
This seems like it needs to be updated (as of 12/21/2012 – still here so I guess the Mayans were wrong). Let’s check it out by running the activity.
The first time the activity is ran, it loads an MP into SCOM. Let’s take a peek.
I cracked open the MP and it basically contains one rule that targets the RMS as well as a data source to map the fields set in the activity to the alert being generated.
Firing the runbook again, we get an alert:
Here it is and it is set just as the activity was configured. Alert Suppression?
Nope. And since they are raised through the same rule, each of these has the same MonitoringRuleID which is the field that is typically used for driving alert traffic to the right owner. With the ‘Create Alert’ activity being attached to the same rule every time, a different field would have to be used to move this traffic around if the ‘Create Alert’ activity were to be used in different runbooks with the intent to send traffic to different support teams.
All and all, a very useful activity just be aware of the potential to alert storm as well as the fact that the alerts may need special handling for notification and/or routing.