Sometimes, the purpose of Service Manager in relation to the other System Center 2012 components is misunderstood: Some people think of Service Manager as a “ticketing system.” The reality is that Service Manager is a central hub for all of System Center 2012 and indeed the entire IT infrastructure in System Center 2012. (It also performs ticketing!) If you’ve ever seen a graphic representation of the System Center 2012 components, Service Manager is typically drawn in the middle (as you see in Figure 1), emphasizing its centrality to the full power of System Center 2012.
Related: "System Center 2012 Suite"
I should point out that I’m using the word “component” rather than “product” to describe Service Manager. Remember that System Center 2012 is a single product that includes multiple components. Prior to this release, these pieces were separately purchasable products. That is no longer the case. If you own System Center 2012, you own all its components.
I think of Service Manager as the Configuration Management Database (CMDB) for the entire organization. Because Service Manager has connections to most of the other System Center components, it knows what they know and consolidates that knowledge into a single data warehouse. When you look at a Configuration Item (e.g., a computer) in Service Manager, you see its hardware and software inventory, its patch status, its Active Directory (AD) information, any monitoring alerts that relate to it, information about its virtualization, and so on. You see everything. The Service Manager 2012 data warehouse also allows the inclusion of custom data sources, permitting the collection of data from other sources beyond System Center. Work items such as incidents, change requests, problem records, release management records, and service requests are all native to Service Manager.
There are also strong partners—such as asset management—that enhance Service Manager with additional capabilities. Tiers of support and different groups can be defined, allowing work items to be routed to the right group of people. Service level agreements (SLAs) can be defined, triggering automatic escalation if an SLA reaches a certain threshold. Service Manager is a library in which you store knowledge about your environment and processes. Many areas of Service Manager got improvements in the 2012 version, including a welcome overall performance boost, but I want to focus on some specific key new features.
There are many new capabilities in Service Manager 2012 and even newer ones in SP1. However, I want to focus on what I think of as “the big three” new features that work closely together to enable the System Center 2012 Private Cloud solution.
Integration with Orchestrator and Virtual Machine Manager
Think of any set of activities that you need to perform on any number of systems and on all the different consoles you use. Consider the various paths of your actions, and all the complex procedures that need to be followed. Whatever you think of—provided that set of activities has some way to be communicated with digitally through an API, PowerShell, SSH, commands, REST, a defined set of activities provided in an Integration Pack, or anything else—can be automated as a runbook within System Center Orchestrator. Once most people get a look at what’s possible with Orchestrator and see how simple it is to create runbooks through a graphical designer, they quickly regard Orchestrator as the System Center component they can’t live without. They quickly begin creating runbooks to automate manually intensive processes.
Service Manager 2012 is tightly integrated with Orchestrator, allowing all defined runbooks to be synchronized into the Service Manager 2012 database, using the built-in Orchestrator connector. (Note that the actual runbook code isn’t synchronized but rather the list of available runbooks and the data-initialization parameters necessary to launch each runbook.) This allows Service Manager to remotely trigger the execution of a runbook by passing the required parameters. Using this approach, it’s possible to create runbook-automation activity templates, which can then be used in standard service request templates, incident templates, or any other kind of work item. These runbook activities can be included in the overall process for these different types of work items to automate the process (or portions of the process).
Virtual Machine Manager (VMM) also integrates with Service Manager, and the built-in connector pulls information about the virtual environment into Service Manager. This includes objects such as virtual machines (VMs), VM templates, networks, hosts, and clouds. (Some of this functionality comes via Operations Manager, as well.) Giving Service Manager information about the virtual infrastructure enables a number of private cloud management scenarios, such as creating VMs and entire clouds via requests made through Service Manager. A further change in Service Manager SP1 is VM chargeback. Chargeback is a new set of objects in Service Manager that allows pricing to be defined for different virtualization resources such as VMs, CPUs, memory, or storage. As VMs are consumed by business units, reports can be generated that show each business unit the actual dollar charge for the virtualization resources it has used. Figure 2 shows a sample pricing sheet object in Service Manager. Note that the options include not only pricing for common resources such as CPU, memory, and storage but also for more advanced features such as the use of high availability and a static IP address.
Request Offerings, Service Offerings, and the Service Catalog
Service Manager 2012 introduces a number of capabilities that relate to offering services to users—a key building block of the industry shift toward IT organizations acting as service providers to the broader organization. The first step in offering a service is to create a request offering. Each request offering is based on either an incident template or service request template that defines some default values such as the title, the urgency, and the group it will be assigned to when a user requests it. These templates also define the process to be followed to fulfill that request. As a simple example, the template might have a two-step process to get approval from the requestor’s manager and then to execute a runbook in Orchestrator to provision a new VM. A request offering can be given a title, a custom 32×32 image, and a description, and then the administrator can define a number of questions for the user, requesting specific pieces of information. The administrator then defines how each user response is mapped to the resulting service request or incident on creation.
Figure 3 shows a sample request offering that will prompt the user for a new VM name, its owner, a cloud to deploy to, and a VM template to use. Rather than creating just simple text boxes, you can also create lists for users to select from. In Figure 3, I’m using the list option for the cloud and template selections; however, you could also make this a Query Result, which would display a list of options based on what had has been populated in the Service Manager CMDB from VMM. In my sample scenario, which calls a runbook, some of the user responses would likely be mapped to the inputs expected by the runbook. When creating request offerings, it’s important to set the status to Published which is in the Publish section of the Request Offering or they won’t be visible to the user nor be available to be placed into our next step: a service offering.
A service offering allows the logical grouping of request offerings. Like a request offering, a service offering has a title, its own icon and description, a category, and information such as SLAs and cost. One or more request offerings are added to a service offering, as Figure 4 shows. In my example, I’ve created a virtualization service offering and I’ve added all my virtualization-related request offerings to it. Essentially, you’re defining a type of service, and the request offerings are the actual services that the user can request. So, virtualization is the service, whereas creating a VM, changing VM ownership, and changing quotas are all services that the user might want to request.
The request offerings and the service offerings make up the service catalog, which is the sum of the services and assistance you want to make available to the end users to request.
In the previous section, I talked about making offerings available to users, but how do users access them? Service Manager 2010 had a web-based self-service portal, but it was functionally limited and hard to use. Service Manager 2012 features a brand-new self-service portal built on SharePoint 2010. (Yes, even with Service Manager 2012 SP1, at the time of this writing, only SharePoint 2010 can be used, which means although every other component of System Center 2012 SP1 supports, the web portal for Service Manager needs to run on Windows 2008 R2. However, this should change soon.) The new portal uses Silverlight, which means all the customization of SharePoint can be leveraged for the portal. Additionally, the web parts that make up the Service Manager 2012 web portal can be integrated into an existing SharePoint deployment. Figure 5 shows the self-service portal home page, and the emphasis on the service catalog is immediately evident: All the service offerings you’ve created are presented in the default Category view. There’s also a List view (which Figure 6 shows), showing all the request offerings created. As you can see, the Category view is a better experience for users, allowing them to select the type of service they’re interested in. Once selected, the specific request offerings for that service are displayed, as Figure 7 shows.
When a user selects a specific request offering, he or she is taken to a new page showing any related Help articles and service offerings, with a button to go to the actual request form. A common request I hear from customers is to cut out this page because it just slows down users’ attempts to get where they want to go. However, the goal is to be able to present users with information, so perhaps they don’t need to fill out the request at all. Figure 8 shows the actual request offering form. Remember the fields that were configured in the request offering way back in Figure 3? Well, this is what the user sees as a result of those the information prompts. Once the user completes all the fields, he or she is taken to a review screen when the request is submitted and the user will be given the ID of the new service request.
Notice the links on the left side of the self-service portal. The Homelink takes you to the home page of the service catalog. There’s also a link to Help Articles, with which you can search for help. My Requests lets you see your open requests and update them—for example, to add more information. My Activities shows only activities for you to do, such as performing some task or approving somebody else’s request. Returning to the VM creation scenario, in which the manager has to approve the request prior to the actual VM creation, that approval is a review activity assigned to that manager. The manager could log on to the self-service portal, and those review activities would be listed under My Activities. Assuming the manager approves the review activity, Service Manager would kick off the automated runbook in Orchestrator to create the VM.
What Do We Get?
When you put these three things together, you have the ability to present users a catalog of services that they can request. Each type of request can gather specific information needed by the IT organization to fulfill that request. Because the information from the user is captured in a structured way and mapped to either a Service Request or an Incident, you can easily pass that data into an Orchestrator runbook to automatically fulfill all of or part of that request.
Users have a single place to go to request any kind of service. It could be a new VM running an Orchestrator runbook that triggers things on VMM. It could be a request for an application running an Orchestrator runbook that triggers activities on Configuration Manager (and you can download Application Approval Workflow to help with this). It could be resetting Apache on 20 Linux boxes that triggers Orchestrator to run some SSH commands on the target boxes that application owners can leverage instead of having to bother the IT administrators. It could be requesting a new chair that just raises a request ticket in Service Manager. Pretty much anything. I walk through this entire process in this video.
The Best of the Rest
There are many features beyond the big three I’ve discussed, and I’ll just touch on some of them here. I mentioned SLAs earlier; this concept was present in Service Manager 2010 but SLAs weren’t very usable because they basically just started a clock, and when a certain amount of time had passed, the SLA threshold was triggered. That was unfortunate if the ticket was opened at 5:00 pm on Friday. In Service Manager 2012, calendars can be created and different calendars assigned to different groups of work items. Normal work items can be tracked only during working hours, but for special groups of work items the SLA can extend later into the evening.
Service Manager 2012 introduces a new type of work item called the release record, which can be used to coordinate the release management process of rolling out a line-of-business (LOB) application or applying changes during a maintenance window. Service Manager now also allows the creation of parent-child relationships for incident, change, and release management work items. With the new parent-child capability, incidents can be linked to an existing parent incident. This means that when the parent incident is resolved, all the child items will also be (optionally) resolved. This is useful when your email server goes down and you have 500 tickets related to no email service. Now, when you fix the email server and resolve the associated parent incident, all those user tickets get resolved automatically.
Each component of System Center 2012 has different upgrade processes. Some can be migrated, and some have to be reinstalled while pointing to an existing database. Service Manager is one of the best in this regard, allowing an in-place upgrade from Service Manager 2010, making the adoption of Service Manager 2012 fairly painless.
Note that Service Manager 2012 SP1, like the rest of System Center 2012 SP1, now supports Windows Server 2012 and SQL Server 2012, making it possible to deploy on the latest OS and SQL Server versions. Note that Service Manager doesn’t support an installation on Server Core, as confirmed at TechNet.
For most organizations, the new Service Catalog feature available in the web portal, coupled with the tight integration with Orchestrator, will be the must-have feature. However, many organizations haven’t yet taken advantage of many existing features or even tried Service Manager yet. Hopefully, this article will get you excited enough to start planning a Service Manager deployment in your organization.