In my last blog post I talked about the new Service Request Work Item type and how to use them. Service Requests are great, but it would be even cooler to automate the IT processes behind it. This is possible when you are using Service Manager 2012 together with System Center Orchestrator 2012. This product allows you to design runbooks to completely automate things. Those runbooks can be imported into Service Manager and then be used as “”Runbook Automation Activities” in Service Request Templates. This brings the automation of your infrastructure to the next level.
****************************************************
The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks
****************************************************
This blog post will guide you to the complete process of automating Service Requests with Service Manager. Now let’s start from the very beginning … and be prepared for a long post 
Step 1 – Create runbooks
First, create a runbook that automates one of your processes. In this example I have created a very simple runbook to create new ADDS Users with System Center Orchestrator (SCO).
The first activity in the runbook defines the runbook parameters. These will later be used to create the User Accounts. The second activity is a Powershell script that uses the input from the first object to create the user in ADDS. In Orchestrator this is called “published data”.
When the runbook is started (e.g. with the “Runbook Tester”) we need to provide the parameter values, otherwise the runbook cannot run. The cool thing with this is, that you can design very dynamic runbooks using this technology.
Step 2 – Import runbooks into Service Manager
Service Manager 2012 brings a new “System Center Orchestrator Connector” that allows you to import runbooks and use them later in Activities and Service Requests. Let’s create a new runbook connector and get those runbooks.
We have to enter the URL of the SCO Web Service. Ask your SCO-Admin for this. Normally the URL in the following Screenshot is correct, but maybe in your environment the SCO Web Service is using another port. Also define a connection Account that enough rights to read runbooks from Orchestrator.
Now select the Folder that contains the runbooks that you want to import. In this example I import all runbooks that exist in SCO.
As a last information enter the URL of the SCO Web Console. This URL is later used to access more information about runbooks. Again, ask your SCO-Admin for details.
Now the connector is up and running. You can manually start a synchronization of the connector and should see the runbooks in the library after a few seconds.
Step 3 – Create Runbook Activity Templates
Now as the runbooks are available in Service Manager, we can create so-called “Runbook Automation Activity Templates”. Start the task from the task window to create such an activity for our SCO runbook that creates User Accounts in ADDS. Define a good Name for the Template.
Now you can configure the Runbook Automation Template and enter the needed values. In this example I only enter a Title and (very important) mark the option to automate the execution of this activity. In a more complex scenario some more configuration is needed here, but I will cover such scenarios in a later blog post. For now it’s OK to go like that.
Now save the template – that’s it. This activity template can now be used in a Service Request.
Step 4 – Create a Service Request Template
Now it’s time to create a Service Request template and use our new Runbook Automation Activity in it. I will not go into any details on how to create Service Requests as this can be read in my previous blog post here –> http://blog.scsmfaq.ch/2011/10/28/news-in-scsm12-beta-2-service-requests/.
Create a new Template and configure the desired values. Then add the activities as needed. You can now select the prepared Runbook Automation Activity and use it in your process.
Step 5 – Create a new Service Request
Now it’s time to test it! Create a new Service Request and use your template.
Enter the information you need. Then change to the activities tab and configure the Runbook Automation Activity. To create the user Account we need to provide some information that the runbook needs for execution. On the details of the runbook activity switch to the runbook tab and enter the appropriate information.
Now close the Service Request and check what happens. First, the Service Request will be shown in the list of Open Requests and have the Status “New”. After some seconds this will change to “In Progress”. Then the workflow engine follows your process defined in the Service Request.
As soon as the Runbook Automation Activity becomes active, the runbook is triggered in System Center Orchestrator. Check the System Center Orchestrator log of the runbook to see if it was triggered and if it was successful or not. In this example it looks pretty good.
At the end the Service Request should automatically change the status to “Completed” and – tho most important thing – the User Account should have been created in ADDS.
Wow, this is great! The new possibilities to connect Service Manager with System Center Orchestrator gives us complete new possibilities to drive automation to the next level and is a vital element in a private cloud strategy.
In this example there is only one downside: the process of creating a new Service Request and fill in the needed data is not very comfortable – and it has to be done by a technician using the Service Manager console. In the next blog post we will go one step further and bring our Service Request to the Service Catalog to offer it directly to the end users (or other consumers). This allows us to give the end users access to several Offerings they can access directly using a Web Portal. So make sure you don’t miss the next blog post!
regards
Marcel