Getting Started with System Center Service Manager 2010

System Center Service Manager 2010 is a mystery to most people. Is it a ticketing system? Is it a change management system? Is it a workflow engine? It’s all of these and more.

In most organizations, IT operations are trying to reduce costs, improve the end-user experience, deliver services faster, and achieve better reporting and data sharing to meet internal and regulatory compliance requirements. To help meet these goals, Service Manager drives the implementation of four key concepts: standardization, compliance, automation, and self-service. These concepts complement each other. If you want to have compliant systems, you need to standardize the environment and the easiest way to standardize is through automating processes. Automation is the key to enabling self-service for end users and facilitates users triggering a certain workflow, which is completed without further human intervention unless desired.

Before looking at Service Manager in detail, it’s important to understand that it’s built around key IT Infrastructure Library (ITIL) concepts. Although not required, I recommend gaining a basic understanding of the ITIL fundamentals before implementing Service Manager. Right now, I’ll just focus on a few key ITIL terms you’ll need to know:

·         Incident management: An incident is an event that isn’t part of standard operations and might impact service delivery. The incident management process returns service to normal as quickly as possible, minimizing the incident’s impact. A user or system reports (i.e., raises) incidents. The incident might lead to a change request or problem ticket.

·         Change management: The change management process ensures standard methods and procedures are used for any change activity. Change requests are managed through the change management process.

·         Problem management: The problem management process identifies the causes of incidents and prevents recurrences of the issue.

·         Configuration items: A configuration item is ITIL’s term for an object, such as a computer or user.

·         Work items: A work item is ITIL’s term for something that needs some work performed, such as an incident, change request, or problem.

Now that you’re familiar with the terms used in Service Manager, let’s look at what it is, what you need to deploy it, and how to use it.

Background

Service Manager’s power comes from its configuration management database (CMDB) and its integration with other IT systems. CMDB links to IT systems and stores information about them. Service Manager provides various portals and workflows to access the information in CMDB.

Out of the box, Service Manager integrates with Active Directory (AD), System Center Operations Manager, and System Center Configuration Manager (SCCM), which gives Service Manager knowledge about your systems, people, hardware, and software. You can also integrate Service Manager with other products in the System Center family (e.g., Opalis) and Microsoft Exchange. Plus, you can use PowerShell to connect to third-party systems. Figure 1 shows Service Manager’s complete architecture and integration.

Figure 1: Service Manager’s main components

Integrating with other systems is great for collecting information and reporting—and a whole lot more. A powerful workflow engine lets Service Manager initiate complex sequences of actions on connected systems across multiple platforms. The actions can be initiated by users through web-based portals or in response to alerts generated by connected systems. Here are some examples:

·         If Operations Manager triggers an alert, Service Manager can automatically generate an incident, then follow a predefined workflow. The workflow might entail a number of steps, such as notifying groups by email about the alert, requesting input from an analyst, and using SCCM to perform an action. You can automate as little or as much as you want. More automation means better standardization, less administrator overhead, and better compliance with requirements. Even if automation isn’t used, you can use the Service Manager console to manage Operations Manager alerts and see information related to the incident. Being able to obtain information from all the management systems (e.g., AD, SCCM) rather than just the information from Operations Manager might expose details that will aid in the resolution of the incident.

·         When Service Manager is integrated with SCCM, all of the inventory and packaged application information is available to Service Manager. Thus, you can implement workflows that allow users to access the Service Manager self-service portal to request a software installation. Users are presented with a software list that’s automatically populated using the inventory and packaged application information in SCCM. If a user selects software that requires a license, Service Manager can send an email to the user’s manager, asking him or her approve the software installation. Once approved, the Service Manager workflow adds the user or the user’s primary computer (which is known based on SCCM asset intelligence) to a SCCM collection (i.e., a group of defined computers in SCCM that are used as the targets of deployments) to facilitate the installation of the software.

·         SCCM has a great feature named Desired Configuration Management. It allows a baseline to be created on how a system should look, which can be defined in terms of files, registry settings, software packages, and configurations. The baseline enables standardization and compliance on applied systems. If a system deviates from the baseline, SCCM reports on this deviation. However, it doesn’t take action to make the system compliant with the desired state. Service Manager fills this gap. For instance, when a machine falls out of the desired configuration, Service Manager can create an incident, which triggers workflows that will make the machine complaint again. Making the machine compliant is typically achieved by interacting with SCCM to re-install software or reset configurations.

Requirements

Before I go any further, I want to talk about the servers and software you’ll need to implement Service Manager. To begin, you’ll need at least two Service Manager servers, which can be physical or virtual. The Service Manager servers take on different roles: One becomes the Service Manager management server, and the other becomes the data warehouse management server. Both servers require the 64-bit version of Windows Server 2008 SP1 or later.

The Service Manager management server is Service Manager’s brain. It manages connections, manages the integration with other systems, executes workflows, and performs any other action that’s required. This server has its own database, which must be hosted on the 64-bit version of SQL Server 2008 SP1 or later.

Typically, a Service Manager management server can handle around 80 concurrent active console sessions. To handle more active console sessions, you can add additional servers to form a Service Manager management group. The servers in the group can share the same database.

The data warehouse management server houses and manages the data warehouse, which consists of three databases hosted on the 64-bit version of SQL Server 2008 SP1 or later. The data warehouse is used for the long-term archival of the information that Service Manager generates or gathers. In addition, all reports are run against the data warehouse. After you create the data warehouse management server, you connect it to the Service Manager management server to enable the transfer of data into the data warehouse and establish the link to the Service Manager console.

Service Manager uses SQL Server Reporting Services (SSRS) for reports. SSRS typically runs on the data warehouse management server, but this doesn’t have to be the case. Reports can be run from the Service Manager console or through the browser-accessible SSRS interface.

In test environments, the data warehouse management server doesn’t have to be running all the time. You can run it once a day to trigger the jobs that pull data from the Service Manager database into the data warehouse and when you want to run reports. When data is pulled into the data warehouse, it isn’t deleted from the Service Manager database because that data is needed for other Service Manager operations. Grooming processes run periodically on the Service Manager database, deleting data based on the status of the work items and the date and time of the last modification.

You can find detailed instructions for installing Service Manager in the System Center Service Manager 2010 SP1 Deployment Guide (technet.microsoft.com/en-us/library/ff460909.aspx). There are a few gotchas in the installation of Service Manager, which I cover in these FAQs:

·         Q. I’m preparing to install System Center Service Manager (SCSM) 2010. Any tips?

·         Q. What’s the correct order to update my System Center Service Manager (SCSM) 2010 installation to SP1 (or any other service pack)?

·         Q. I installed the System Center Service Manager (SCSM) Self-Service Portal onto my SCSM management server. I get an error and see that the SM_AppPool has errors and been disabled. What’s wrong?

Using Service Manager

There are three main types of Service Manager users:

·         Service Manager architects and administrators. They design and implement the Service Manager installation, customize workflows and forms, and manage Service Manager’s integration with other systems in the IT infrastructure.

·         Analysts. They use Service Manager to manage and work on incidents and change requests. They often work in the IT department or man Help desks. Sometimes they’re managers or HR staff members who need to authorize certain types of actions.

·         End users. They use Service Manager to request software, change their passwords, search the knowledge base (i.e., a collection of articles that can aid in the resolution of incidents and problems), log new incidents, look at announcements, and perform other actions.

Coincidentally, Service Manager provides three UIs out of the box:

·         Service Manager console. Like the consoles for the other System Center products, the Service Manager console is built on the common Service Manager UI framework and not the Microsoft Management Console (MMC). The big advantages with the Service Manager UI framework are its flexibility and its ability to only show items that a user has permission to access, which gives a much cleaner interface to users who have been granted specific rights to specific groups of objects. The Service Manager console is primarily used by administrators, analysts, and people who run reports.

·         IIS-based self-service portal. This self-service portal provides two separate websites. The first website is for end users. On this website, end users can search the knowledge base, check the status of change requests, raise new incidents, and more. The second website is for analysts. On it, analysts can approve change requests, view work items assigned to them, and more.

·         SharePoint-based self-service portal. This portal provides the same functionality as the IIS-based self-service portal. However, it uses SharePoint Web Parts, which enable the Service Manager web interface to integrate with the existing SharePoint infrastructure.

Other interfaces are available, but they’re primarily used for custom forms and workflows. You can create custom forms, workflows, and other components with the Service Manager Authoring Tool. To use this tool, you don’t need a huge amount of training because it uses drag-and-drop functionality. You can download the Authoring Tool here. For more information about customizing Service Manager, see the System Center Service Manager 2010 SP1 Authoring Guide.

The Service Manager Console Up Close

The easiest way to get a feel for the use and capability of Service Manager is to look at the Service Manager console. As Figure 2 shows, there are six workspaces in the console, which reflect Service Manager’s six main functionality areas: Administration, Library, Work Items, Configuration Items, Data Warehouse, and Reporting. Before I highlight the key points in each workspace, I want to point out that in Figure 2 I’m logged on as a full administrator so all the workspaces and options are displayed. If I were running the console as an end user, I would only see the workspaces and options I have permission to access. Role-based access control is a big feature of Service Manager and the rest of the System Center products.

Figure 2: The Service Manager console

Administration. The Administration workspace will be the starting point for any new Service Manager deployment. In it, you can configure Service Manager’s integration with other systems, such as AD, SCCM, and Operations Manager. You’ll definitely want to connect Service Manager to AD, as this will allow you to import your user, group, printer, and computer objects, along with any attributes you’ve set for them.

Note that the connector to AD is one-way. Thus, if you modify the attributes of configuration items (aka objects) in Service Manager, you also need to change the attributes in AD. Otherwise, the next time AD synchronizes with Service Manager, AD will overwrite the changes you made. You can have Service Manager synchronize with the entire AD namespace or a subset of it (in which case, you specify the types of objects that should be synchronized).

Besides configuring integration, you’ll need to assign user roles to users in the Security area of the Administration workspace. By default, there are 11 roles: Activity Implementers, Administrators, Advanced Operators, Change Initiators, End Users, Read-Only Operators, Authors, Problem Analysts, Workflows, Incident Resolvers, and Change Managers. If these roles don’t meet your organization’s needs, you can create custom user roles.

Another configuration you’ll probably want to make is setting the retention times for the data in the Service Manager database. You do this in the Settings area of the Administration workspace. This is also where you configure incident settings. For example, you can attach a prefix to the incident IDs that will be generated, specify how the priority should be calculated for an incident, and set limits for files that users can affix to incidents they raise (e.g., allow only two attachments up to 512KB each).

Making configurations isn’t the only thing you can do in the Administration workspace. You can perform a variety of other tasks, such as creating announcements and importing management packs. The Announcement area is where you create announcements that will appear on the self-service portal. You have the option of setting an expiration date, so you don’t have to worry about removing announcements once they’re no longer valid.

Management packs are .xml files that define forms, workflows, classes, views, and reports in Service Manager. When you create a new workflow, for example, you’re creating a new management pack. To import that management pack into Service Manager, you use the import functionality in the Administration workspace.

Library. The Library workspace exposes the various configuration data elements of the Service Manager system, which are used throughout the product. For example, all the options shown when creating an incident can be easily changed by modifying the relevant list item, which I’ll elaborate on shortly. You can define groups of configuration items, much like you can create containers for objects in AD.

The Library workspace’s Knowledge area is where you can create and maintain the knowledge base. The knowledge base articles are the primary vehicle for sharing knowledge. When users access the self-service portal, a list of the top knowledge base articles is automatically generated and shown on the start page.

Another key part of the Library workspace is the Lists area. When users create and modify work items, there are often drop-down lists they can use to select the type of problem they’re having and what system it’s affecting. If you want to change what options are displayed in the drop-down list, you go into the appropriate list and add or remove items, as Figure 3 shows. Figure 4 shows this drop-down list in a form.

Figure 3: The Incident Classification list

Figure 4: The Incident Classification list in a form

Templates are another great feature in the Library workspace. Besides using the self-service portal, users can submit incidents and changes by email or phone. Rather than have the analyst waste time repeatedly typing in the same information and settings, they can quickly apply a template that populates most of the common fields for various types of common requests. Templates can also be automatically applied by workflows to route and classify work items based on certain conditions.

Work items. Analysts often use the Work Items workspace, as it contains the incident, problem, change, and activity items they work on. In each workspace area (e.g., Change Management area, Incident Management area), there are a number of default views. For example, Figure 5 shows the default views for Incident Management (e.g., All Incidents, All Open Incidents, All Open Portal Incidents). On the right, note the tasks pane. Each view includes the tasks that are available for that type of work item. In this case, there are many available tasks for incidents. For example, analysts can change an incident’s status, create a change request based on an incident, escalate an incident, and even perform certain tasks to help resolve an incident, such as perform a ping. Any task performed is automatically logged in the incident’s history, giving a full account of the actions taken and progress made. By default, end users can see the history for the incidents they create. However, analysts have the option to mark certain items in the history (e.g., comments) as private so they won’t be visible to end users. Analysts also have the ability to create custom views.

Figure 5: The Incident Management default views

Configuration items. The Configuration Items workspace gives you access to the computers, printers, users, software, software updates, business services, and any other type of defined or imported configuration item within your organization. In most environments, there isn’t a lot of manual management of configuration items in Service Manager. Instead, the configuration items are managed through their respective connected systems (e.g., AD, SCCM, Operations Manager).

The Configuration Items workspace doesn’t provide a “dumb” view of the configuration items replicated from different sources. Because the configuration items from the connected systems are consolidated in CMDB, relationships are ascertained. So, when you examine a configuration item in the workspace, you’ll see AD, SCCM, and Operations Manager information about that item as a single entity, which helps with analyses. For example, if you’re examining a software package, you’ll see any related change requests or incidents that involved that piece of software.

Data warehouse. In the Data Warehouse workspace, you perform the tasks that relate to populating, managing, and securing the data warehouse management server.

Reporting. The Reporting workspace exposes all the available reports, which actually run on the SSRS instance. You can also run the reports directly on the SSRS instance, as Figure 6 shows. You can create your own custom reports and display them in the Reporting workspace by following the instructions in the SCSM Engineering Team blog, How to create a custom report and display it in the console.

Figure 6: Service Manager reporting on the SSRS instance

The Self-Service Portal Up Close

End users and analysts interact with Service Manager through the self-service portal. On the end user website, end users can easily raise an incident, request new software, and request other types of changes. Once submitted, they can use the portal to easily see the state of all their open and resolved incidents and requests. The ability for end users to self-resolve problems by searching for known issues in the knowledge base can cut down on the number of incidents the users actually raise, reducing the overhead for the Help desk team.

On the analyst website, analysts can view and manage the incidents and change requests assigned to them. This site could also be used by managers who need to approve a change for an employee or sign-off on a document.

Figure 7 shows the IIS-based portal out of the box, with no changes made to it. The source code for the self-service portal is available, so you can customize the look, feel, and functionality of it. For more information on the customizations possible, see Service Manager Portal Source Code Released!

Figure 7: IIS-based self-service portal

As I previously mentioned, if you use SharePoint, you don’t need to use the IIS-hosted portal. Instead, you can use the SharePoint-based portal. You can even place Service Manager Web Parts on users’ My Sites to give them easy access to Service Manager information.

More Than Just a Ticketing System

It’s important not to think of Service Manager as a ticketing system. Yes, it has great ticket-management features, but its true power lies in its integration with the rest of the IT infrastructure and in the CMDB, which enables workflows to get separate systems working together. Although Service Manager is in its first released version, it already has a rich partner network, including a key partnership with Provance, which adds asset-management capabilities to Service Manager.

I’ve spoken to a number of Service Manager adopters, and the common message from all of them is just how quickly they were able to achieve great results. The SCSM Engineering Team Blog has been instrumental in a number of successful Service Manager rollouts and has a lot of great content about implementing Service Manager.