One possible way of dealing with shipping alert traffic from SCOM to a ticketing system or ECA would be to use subscriptions within SCOM to flag the alerts and then simply have Orchestrator pass all flagged alerts onto the next system in the process. This is potentially the simplest, and if you are migrating from a SCOM 2007 R2 environment where you had these subscriptions in place, this may be an apples to apples migration.
Creating a Subscription:
Now, we can see the connector in Internal Connectors:
We will add a subscription for high priority SQL alerts:
Ok, now we need to generate some alerts from the SQL machines. To do this, I am just going to stop one of my SQL instances. A few minutes later:
Let’s see if the product connector picked up the alert:
It’s flagged. Now, we can create an Orchestrator workflow to grab the alerts that have been processed by this subscription.
Or
This will pick up the alerts, however, there is one side effect that may or may not be an issue in your environment:
After SCOrch has picked up the alert, the connector status is still in pending. This could be in issue if you have other subscriptions that need to process the alert after the fact. Also, depending on how you have your SCOrch runbooks defined you could end up in a loop. At this point, there are no activities within the SCOM 2012 IP that will process and move the connector status field forward.
In a future post, we will explore using Orchestrator a little more heavily and avoid using subscriptions. Rather, we will look at using purely resolution state to manage the traffic.