Author: Brody Kilpatrick | Created: May 3, 2013
Update:
As you read through below, you will notice that Microsoft has been nice enough to use some of the IDs I was using with the release of SP1. (This post was pre SP1) You will have to make small modifications to your script and Ids but the below solution still works.
The Issue
If you use Operations Manager and Service Manager, you know by now that SCOM will automatically create Incidents in Service Manager. However, for most organizations, this just doesn’t make sense because they do not have a 1-to-1 Alert-to-Action ratio. You can set up basic criteria to limit the automatic creation, but this usually still results in too many unnecessary incidents. As a result, most organizations do not utilize this connector, which at one point was one of the most requested features of SCOM – to do really cool things with ticketing systems.
The Solution
So, instead, I have created a solution that will allow you to create incidents on demand directly from a SCOM Alert, while utilizing all the cool features of the Service Manager SCOM Alert connector. All you have to do is right click the alert(s) to create the on-demand tickets.
What are some features of the solution in conjunction with the native Connector:
How Does it Work
The solution utilizes the following components:
Workflow:
Step One
Copy the following PowerShell script code and save on your SCOM management server as UpdateCustomFieldPowershell.ps1. (I took this code from another blog online and modified it as my own. Unfortunately, I don’t know who wrote the original script.)
Param($alertid)
$alertid = $alertid.toString()
write-eventlog -logname “Operations Manager” -source “Health Service Script” -eventID 1234 -entrytype “Information” -message “Running UpdateCustomFieldPowershell”
Import-Module OperationsManager; “C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\Functions.ps1”; “C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\Startup.ps1”
$alert = Get-SCOMAlert -Criteria “Id = ‘$alertid’”
write-host $alert
If ($alert.CustomField2 -ne “AlertProcessed”)
{
$AlertResState = (get-SCOMAlertResolutionState -ResolutionStateCode ($Alert.ResolutionState)).Name
$AlertResState
# $alert.CustomField1 = $alert.NetBIOSComputerName
$alert.CustomField1 = $AlertResState
$alert.CustomField2 = “AlertProcessed”
$alert.ResolutionState = 254
$alert.Update(“”)
}
exit
Step Two
We need to create some new alert resolution states. The alert resolution states will trigger the script. You want to create a resolution state for each support group you would assign an alert. You can use whatever format you want. I used the format of “Assign to GROUPNAME”. Also keep in mind the Resolution State Ids and order you will use. I made my alphabetical. DO NOT use the resolution state 0,1,254, or 255.
To create new resolution states:
After you create your alert resolution states, you will need to create one more that triggers the SCSM Connect. Name this Alert Resolution State “Generate Incident.” Also, make sure this is the exact name as the script requires. If you want to change the name, you will have to update the script. Also, set the Id to 254.
Step Three
We need to set up a command channel and subscription that will trigger and run the script.
Next, we need to set up the subscriber for the command channel.
Next, we need to set up the Command Subscription
Step Four
The last thing we have to do in SCOM is set up the Alert connector. The alert connector will be triggered based on the resolution status of “Generate Incident”.
Step One
The first thing you want to do is enable and connect your SCSM SCOM Alert Connector. If you do not know how to do that, you can refer to technet. http://technet.microsoft.com/en-us/library/hh524325.aspx. Verify it works before moving any further.
Step Two
Step Three
Now you are ready to test. Find an alert in SCOM, right click the alert and set it to a resolution state for assignment. Give the subscription time to run and the SCSM connector time to run. Usually, if the connector is running every 2 minutes, it takes the total process about 5 minutes to complete. While the actual workflows are running in a second, it simply takes time for both of them to trigger.
If there are any issues with the configuration, the event logs will usually tell you about failures. If it is not working, but you don’t see any failures, your criteria probably do not match.
This is a great alternative solution to automatically creating tickets from SCOM. You can still automatically create tickets as well simply by adding subscriptions to the SCSM SCOM Alert connector. If you have any issues, question, leave a comment.