Geek of All Trades: Complete automation for service requests

System Center Service Manager 2012 can handle automating the process of managing service requests.

Greg Shields

Service requests are the bane of every IT pro’s existence, as well as the entire reason for our existence. Over the years, these requests have become something we both love and hate. On one hand, they’re always an opportunity to prove our value. On the other, they add yet another service we’ll be asked to manage for the foreseeable future.

The requests themselves aren’t the real issue. After all, provisioning and managing IT services is why we get paid. What gets under our skin is the highly manual nature of fulfilling those requests. Even in today’s modern world of omnipresent Windows PowerShell exposure and a zillion management consoles, true complete automation for an entire end-to-end workflow is hard to come by—or is it?

Actually delivering on that promise of complete automation is an unspoken mission statement of Microsoft System Center Service Manager 2012. At first blush, this might seem like another in a long line of help desk ticketing applications. But dig a bit deeper and you’ll find some eye-opening automation surprises.

Request then deliver

By itself, Service Manager appears fairly indistinguishable in concept from your average, everyday work order tracking system. Open its console and navigate to the Work Items pane and you’ll find a list of Activities straight out of the IT Infrastructure Library (ITIL) lover’s standard playbook.

Service Manager has six primary work items: Activity Management, Change Management, Incident Management, Problem Management, Release Management and Service Request Fulfillment (see Figure 1). These six activities define an IT department’s everyday function. Click around even more and you’ll find that Service Manager is enormous.

Figure 1 The six work items available in System Center Service Manager 2012.

Defining these activities requires a litany of templates and other setup configurations where you define who does what, when and where. Service Manager can seem so big at first that merely getting started can seem a challenge for smaller environments.

With great responsibility comes great power. If you’re willing to invest the up-front effort, your downstream reward will be complete automation for service requests. That benefit becomes manifest the moment you integrate Service Manager with System Center Orchestrator “glue.” (Read more about using Orchestrator in part one of this series.)

Navigate to the Service Manager Administration pane and you’ll find a link called Connectors. These Connectors are the point of integration between Service Manager and the other System Center components. In Figure 2 you can see Service Manager connected to Orchestrator, System Center Virtual Machine Manager (VMM) and Active Directory.

Figure 2 System Center Service Manager Connectors to other System Center components.

Most of us live in a world without Orchestrator-like automation. In that frustratingly manual world, the workflow surrounding a service request goes a bit like this:

1. Someone requests a new service.
2. Someone else approves that request.
3. There’s a service request ticket generated and assigned to an admin.
4. The admin provisions the service and closes the ticket.

Every organization embraces automation differently. The paper trail required for these four steps will be different for you than for others. However, even the most-automated organizations still struggle with automating Step 4: actually doing the work. It’s fixing that limitation where the Service Manager-to-Orchestrator connection truly shines.

Automate a new VM request, step-by-step

The first of this two-part series introduced the notion that Orchestrator is the glue for the other bits of System Center. By connecting Orchestrator activity objects, you can create rich automations across systems, platforms and applications for regular tasks. And you can create most of those automations without scripting.

Like Service Manager, Orchestrator is worth integrating with the rest of System Center. Doing so exposes a menagerie of higher-order activity objects for performing tasks within the other System Center components. One notable integrated relationship is between Orchestrator and VMM. Connecting these two lets Orchestrator build runbooks for all manner of VMM activities.

Automations are nice, but how they’re executed is where things get interesting. Let’s assume you’ve created your own Deploy VM runbook. In it you defined two parameters—Cloud and VMName. These give the requesting user choices in defining the VMM cloud and name for the VM. You’ve also configured the necessary connectors between Service Manager, Orchestrator and VMM. Your final task is to create a service request that enforces any necessary approvals and (upon approval) automatically provisions the VM.

Accomplishing this task in Service Manager requires layering a series of objects (see Figure 3). Each layer defines some element of the request that’s bound by configurations from the layer above.

Figure 3 The many layers of System Center Service Manager 2012.

At the center is the Orchestrator runbook itself—this is the object that actually does work. Connecting all these layers requires a precise series of steps:

Step 1. Synchronize Service Manager to Orchestrator. Once connected, Orchestrator runbooks can take a while to show up in Service Manager. You’ll want to navigate to Library | Runbooks and ensure your runbook is present before taking the next step.

Step 2. Create a Runbook Automation Activity Template. Name the template (see Figure 4) and create a new Management Pack (MP). Ensure in each of the following steps that everything is saved to that MP. Doing so makes the automation portable. It’s also easier to remove should it become obsolete. Click OK to load the template form.

Figure 4 Creating a Runbook Automation Activity Template.

Provide a title for the Runbook Activity and check the box marked “Is Ready For Automation” (see Figure 5). This checkbox makes the difference between merely creating a request and automatically provisioning that request via an Orchestrator runbook. Select the template’s Runbook tab and verify the parameters you identified in the Orchestrator Runbook Designer are correctly mapped.

Figure 5 Provide a title for your Runbook Activity and enable it for automation.

Step 3. Create a Service Request Template. Right-click Library | Templates and click Create Template. Name the template and select the Service Request class (see Figure 6). Then associate the template with your previously created MP. Click OK to open the template form.

Figure 6 Create a Service Request Template.

Select the template’s Activities tab. This is where you’ll link the approval activity with the runbook automation. Click the green plus sign to add an activity and select the Default Review Activity. Title the activity and configure the Approval Condition and Reviewers (see Figure 7).

Figure 7 Provide a title for your Review Activity and configure the Approval Condition and Reviewers.

Click OK to close the form. Then click the green plus again to add a second activity. This second activity will be the Runbook Automation Activity you created in Step 2 (see Figure 8). Because you’ve already configured this activity, you can click OK to close the template.

Figure 8 Adding a second activity to the Service Request Template.

Step 4. Create a Request Offering. Right-click Library | Service Catalog | Request Offerings and choose Create Request Offering. The request offering defines what information you’ll ask from and provide for a requesting user. Title the template that appears and associate it with the Service Request Template you created in Step 3.

The next series of wizard pages offer a place to enumerate user prompts (see Figure 9) and map them to runbook parameters. These define the questions you’ll ask users as they make a request, the answers of which flow directly into the runbook’s automation. Change the Offering status to Published when you’re ready to deploy this service request into production.

Figure 9 Establish User Prompts for a request.

Step 5. Create a Service Offering. Service Offerings contain Service Requests in much the same way that a catalog contains products for sale. Right-click Library | Service Catalog | Service Offerings and choose Create Service Offering. Provide a title and MP, and then add the Request Offering you created in Step 4 when prompted (see Figure 10). As before, change the Offering status to Published when you’re ready for production.

Figure 10 Create a Service Offering.

All these configurations snap together for end-user consumption the moment your Service Request and Offering are published. Publishing them makes them available in the Service Manager Self-Service Portal. This gives requesting users a place to document their request. Two questions asked earlier fill in the activity’s Provide Information step (see Figure 11). Once submitted and approved, the request then automatically invokes the Orchestrator runbook to generate the new VM.

Figure 11 The System Center Service Manager Self-Service Portal.

Automation bound by imagination

Our industry has long dreamed of automation bound only by our imagination. For the most part, that dream has been exactly that—a dream. We’re somewhat limited by the technologies at hand. There’s evidence of this in how earth-shatteringly mature System Center needed to become before complete automation became a reality.

To fully benefit from such automation requires no small amount of up-front effort. Each building block you create becomes yet another investment in future automation. Start now, because what you’re seeing in System Center today is what you can expect to get out of your IT environment in the future.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek of All Trades tips and tricks at ConcentratedTech.com.

Related Content

• Geek of All Trades: VMM 2012 and Server App-V: happy together
• Geek of All Trades: Script-free glue for automation
• Geek of All Trades: GPPs for the GPP-less