This article will detail a method by which you can have Orchestrator build you a VM in Virtual Machine Manager by transferring a Service Manager Incident into a Support Group. With slight modification, this process can also work from Service Manager Change Management requests or Service requests. I will detail that when we get to that point.
In order to complete this runbook, you will need the “SC 2012 Service Manager” and “SC 2012 Virtual Machine Manager” integration packs for Orchestrator. Both of these can be downloaded here: https://technet.microsoft.com/en-us/library/hh830706.aspx.
Overview
Here is an overview of our runbook:
This runbook will execute on a set schedule. It will pull all incidents assigned to a particular support group and create the VM from a specified template. Finally, if the VM was created successfully, it will resolve the incident. If the VM was not successfully created, it will transfer the incident to another support group. This will prevent Orchestrator from continually attempting to create the VM.
Monitor Date/Time
This activity allows us to execute this runbook on a schedule. To add this activity, drag it into your runbook from the “Scheduling” node. Double click it, and define the properties as you wish. I have mine set to execute every 5 minutes.
Get Incidents
This step connects to your Service Manager environment and pulls any incidents assigned to a particular support group. You can make Orchestrator pull incidents on any value, though support group is probably easiest. If you need Orchestrator to do something with an incident, you simply transfer it to Orchestrator’s support group.
To do this, I set up an “Orchestrator” support group in the Service Manager console. This is done by modifying the “Support Group” list. If you have multiple runbooks executing tasks for Service Manager, then you may want to label your support group something like “Orchestrator – VMM”, that way you can target your runbooks appropriately.
To add “Get Incidents”, drag a “Get Object” activity from the Service Manager node of Orchestrator into your runbook. Double-click it and select your connection. Change the “Class” to “Incident”. Next, add the “Support Group” filter and make the value equal “Orchestrator” (or “Orchestrator – VMM” if that is what you named your support group). Now Orchestrator will only pick up incidents that are assigned to its support group.
This is where we can modify the process if you would rather use a change management or service request. Service request also has the support group option, so I would use that, just as we do for incidents. Instead of selecting the “Incident” class, select the “Service Request” class.
If you want to do it from Change Management, the process is a little more complicated. I would do it by creating a new template just for VM requests. I would then add a value to the “Change Area” list that is something like “New Virtual Machine”. I would then have a workflow that assigns the template for VM’s to any request that is for that “Change Area”. In the template, define whatever approval method you need when someone requests a new VM. Now, in Orchestrator, we have our “Get Object” activity look for completed change management requests with an area of “New Virtual Machine”.
With this process, once the request goes through the change management procedure, Orchestrator will pick it up and create the VM.
Create VM from Template
Now we have the step that actually creates the VM. Drag a “Create VM from Template” activity into your runbook. Double-click it and select your connection. A few properties automatically show up. You need fill in all of these properties so that the VM is generated properly. Most of these settings will depend on your environment. The only one that doesn’t is “VM Name”. For this step, I would create a field on my Service Manager web portal that says “VM Name” and have it map to a property in the Service Manager incident. The “Get Object” activity gets all of the information about the incident and stores it in Published Data. To populate the “VM Name” field for our “Create VM from Template” activity, all we need to do is add the correct “Published Data” from “Get Incident”. I personally like the “Description” field, but you can use whichever field you want.
I would encourage you to look at the “Optional Properties” and see you need any of those specified as well. I have most of that information stored in my template.
Resolve Incident
This step will execute if the VM was successfully created. For this activity, we need the “Update Object” activity from the Service Manager node. Double-click it to open it. Select your connection and class. For “Object GUID”, add the Published Data “SC Object Guid from Get Incidents”. The “Get Object” activity pulls the GUID of the incident, which is what we need to resolve it. Finally, click the “Select optional fields” button and add the “Status” field. Change it to “Resolved”.
Transfer Incident
Finally, this step will transfer the incident to another support group if the VM failed to create. I do this so that Orchestrator does not continue to try and create the VM after it has failed once. To set up this activity, drag another “Update Object” activity into your runbook. Set it up just like the previous example, only add the “Support Group” field and change it to your failed support group (something like “Orchestrator Failures”).
This is another example of how you integrate multiple System Center products to streamline your environment. I encourage you to look for other ways to leverage Orchestrator and Service Manager to help automate tasks in your organization.
