This article will detail a process to tie Service Manager and Orchestrator together, thereby creating a process to automate certain tasks using Service Manager Incidents. Orchestrator will look for a particular SM Support Group, and any incident in that group will be picked up, a process run against it, and the incident closed.
This process can be helpful for tasks that are performed often with the same basic information. Two things that come immediately to mind are assigning permissions to network folders and printers. While this article will not detail that particular process, it will show you how to tie the two systems together and where to put the process that you want to execute.
Service Manager Setup
First, we must configure Service Manager. Orchestrator must monitor a property for it to know which incidents to handle. I choose to use a Support Group, but you could use any property that you want. I created a support group called “Orchestrator” by going to the Library node, then the List option. If you open the “Incident Tier Queue” list, this is where you can add your new group.
I am also going to add a second Support Group called “Orchestrator Failures”. We will use this later in the runbook. It will be a place for incidents to go back too if something happens with the runbook and it is not successful. We need to remove the incident from the Orchestrator group so that Orchestrator does not continue to execute a failing incident.
Once this is added, you can begin to assign tickets to the Orchestrator queue. To do this, go an incident, open it, and change the “Support Group” option to Orchestrator.
Now we are ready to move on to the runbook.
Orchestrator Setup
Here is what your runbook will look like.
It is a fairly simple runbook. You must have the Service Manager Integration Pack imported into your runbook designer. This can be downloaded at https://www.microsoft.com/en-us/download/details.aspx?id=28725. I start with the “Monitor Date/Time” activity. This allows your runbook to loop instead of it needing to be executed by the console. Drag this activity from the “Scheduling” node of the Runbook Designer. Double-click it and configure as best for your environment. You should weigh your organization’s requirements when deciding this. How critical is the system that Orchestrator is acting on? Does it need to be ran every 30 seconds, or will once every 5 minutes be OK?
Next, we are going to get the incidents that are assigned to our Orchestrator support group. To do that, drag the “Get Object” activity from the “SC 2012 Service Manager” node. Double-click it and select the correct connection (this is configured in the Options menu of the designer). Next, select “Incident” from the Class box. Now, click the “Add” button, select “Support Group”, and select the appropriate group.
Now we need to execute our process. Take a look at the available published data that is available from the “Get Object” activity. This is what you can use to script your process. Remember that this information will have to be in a standard form, meaning that if you want to use this process to assign rights to a network folder, the field that is used for the path must be standard across all incidents submitted. I have a placeholder “Run .NET Script” option in my runbook. You can insert any Orchestrator activity here that you want.
Next we need to resolve the incident if our process was successful. Add the “Update Object” activity from the “SC 2012 Service Manager” node. Fill in the correct connection and select “Incident” as your class. For the “Object Guid” box, right-click, go to “Subscribe”, and then “Published Data”. Change the “Activity” box to “Get Incidents” (or “Get Object” if you did not rename it) and select “SC Object Guid”. Finally, click the “Select optional fields…” button. Add “Status”. Finally, switch the option to “Resolved”.
Finally, we need to add catch-all incase our process fails. Add another “Update Object” activity to your runbook. Fill it out like the example above, only change the field to “Support Group” and select “Orchestrator Failures” as the group.
When you link your process to this final activity, be sure to change the link properties to from “success” to “failed”. To do this, double-click the link. Click on “success” and check the failed box while unchecking the success box.
In addition to simply kicking the incident back to another group for review, you could also generate an Operations Manager alert or send an email. I encourage you look into that process if it would benefit your organization.
Summary
This is just a quick example of a process that you could use to automate incidents in your environment. I encourage anyone using Service Manager (or any System Center product) to look at Orchestrator also. It is a great tool and can be used to automate many tasks.
