Microsoft System Center Service Manager - Part 1: Introduction and Planning

Introduction

The newest entry in Microsoft’s System Center line, Service Manager further rounds out System Center’s ITIL/MOF-

focused architecture by bringing centralized, accessible incident and problem management capabilities to the table.

Service Manager has hooks into Configuration Manager, Operations Manager and Active Directory, allowing it to act

as a centralized repository of information from other products. In this series, you will learn how to install and use

Service Manager. Part 1 will provide information about Service Manager’s features as well as providing detailed

prerequisite information.

Whether or not you are into fully implementing the various IT operational frameworks – ITIL, MOF, etc. – that are out

there and available for consumption, the fact remains that there will always be baseline issues that all IT departments

need to handle. One such broad function that always needs appropriate processes and procedures revolves around

IT service management, a broad category that captures such functions as incident tracking and resolution, asset

management and change control.

In its simplest form, service management encompasses those aspects of Information Technology management that

involve the end user. End user support is arguably one of the most critical – and often the most challenging – aspect

of IT operations due to the sheer breadth of potential contact issues. Moreover, without methods in place for users to

handle some of their own support needs, the IT service desk ends up being overwhelmed with common, repeated

tasks.

Microsoft’s System Center Service Manager aims to improve and simplify the operations of the IT service desk and

can be used to streamline and normalize support processes across the IT organization as a whole as well. Besides

simply providing end users with a support submission tool and self-service tools (which I’ll discuss later in this article

series), Service Manager hooks into the other System Center products–including Operations Manager and

Configuration Manager—in an effort to improve IT operations. For example, when an alert is raised in Operations

Manager for, say, a disk space issue, Service Manager can automatically create an incident that is assigned

to someone to handle. There is no need for a staffer to go through a manual ticket creation process since it’s

all automated.

Why is this important? After all, as long as the problem gets fixed, does it matter if a ticket is opened?

The short answer is: Yes, it’s very important.

Any request, whether generated by a user or automatically generated due to a server fault should generate a work

log of some kind. Besides helping to make sure that tasks don’t fall off the radar, tracking all tasks helps IT

management better assess true workloads in order to be able to make decisions regarding staffing and budgets.

Service Manager Components

The Service Manager product is broken down into a number of individual components, each providing important

services leading to a cohesive product. In the case of Service Manager, there are six individual components:

Service Manager management server - This is the primary software portion of your Service Manager installation.

Service Manager database - Database servers are what makes the world work these days. In your Service Manager

environment, the database contains a number of different items, including:

- Configuration items from across the organization

- Incident records

- Change requests

- Service Manager environment configuration

Data warehouse management server - On this system you’ll find the server portion of the data warehouse.

Data warehouse database - Without reporting capability, there is no way to gauge the effectiveness of the Service

Manager environment. The data warehousing database handles long-term storage as well as reporting needs.

Service Manager console - The console provides the portal into the Service Manager environment, used by Help

Desk staff and other administrators, the console is the method by which these employees manage incidents, tasks

and change requests.

Self-service portal - One of the best ways to reduce IT workload is to enable users to handle some of their own

tasks such as password resets and providing users with a knowledgebase that they can use to try to find their own

solutions to problem. Under Service Manager, the self-service portal provides the first component necessary to

enable some of these capabilities.

Although it’s a great role, I won’t be focusing on the self-service portal in this article but will come back to it in a future

part.

System Requirements

System Center Service Manager has a number of hardware and software requirements that need to be considered

prior to deployment.

Hardware Requirements

As is the case with almost all of the products in the System Center line, Service Manager’s hardware requirements

are dependent on the level of support being provided by the product. At a minimum, if you intend to deploy all of the

Service Manager components, you need at least two servers. Bear in mind that you can't install the data warehouse

component on the same server that holds the management server; the two roles are incompatible with one another.

If you’re short of hardware and are running Service Manager in a relatively small environment, you can actually install

everything to a single physical server. Install everything other than the data warehouse to the physical server and

then deploy the data warehouse component inside a virtual machine on the same physical hardware. Microsoft’s

virtualization licensing policies make this a no-additional-cost option that can save you a few bucks since you don’t

need to buy two separate physical servers.

As per Microsoft guidance, for medium-sized deployments, two separate servers are required. The first server will

hold:

Service Manager management server

Service Manager database

On the second server, deploy the following:

Data warehouse management server

Data warehouse database

For large installations—those that encompass tens of thousands of users—deploy Service Manager to four different

servers.

Below, I’m going to outline Microsoft’s recommendations regarding server sizing which hold true whether you’re

deploying Service Manager to physical servers or to virtual ones. Personally, I believe that these requirements are

significantly overstated for all but the largest of environments. To follow the guidance to the letter in a virtual

environment, for example, would seriously tax the pooled resources in a way that would make a virtual deployment

not make much sense. Below the hardware requirements chart, I’ve provided some guidance as to how I’m deploying

Service Manager.

Role Processor RAM Disk

Service Manager database Dual Quad-Core 2.66 GHz 8 GB 80 GB

Service Manager management server Dual Quad-Core 2.66 GHz 8 GB 10 GB

Service Manager console Dual-Core 2.0 GHz 2 GB 10 GB

Data warehouse management server Dual-Core 2.66 GHz 8 GB 10 GB

Data warehouse database Dual Quad-core 2.66 GHz 8 GB 400 GB

Self-service portal Dual-core 2.66 GHz 8 GB 10 GB

For the example I’ll be using in this article, I’ll be deploying an English-only Service Manager environment to two

virtual machines, each with 2 GB of RAM and a single virtual processor. This will be for testing only. In my real world

deployment at Westminster College, Service Manager is also a dual server deployment, but each server has 4 GB of

RAM and has been assigned two virtual processors. Westminster College has fewer than 200 employees and around

1,100 students. Given the expected load, which I don’t expect to be significant, I’m confident that we’ve assigned

enough resources to the virtual machines. However, if we find that we’re having performance issues, it’s very easy to

add more resources to each of the virtual machines.

Software Requirements

Before you embark on your Service Manager journey, there are some software needs that require your attention.

First, all Service Manager components, with the exception of the service console, require the use of 64-bit editions of

Windows Server 2008 or Windows Server 2008 R2. As a best practice, make sure that you also install the latest

service pack for whichever Windows version you select. Although some of the Service Manager roles may work

under Windows Server 2003, not all roles are supported on this operating system, so stick with a newer operating

system.

For the database roles, you need to deploy the 64-bit edition of SQL Server 2008 SP1. When you do so, make sure

to also install the SQL Server Reporting Services role.

For ease of deployment, I also recommend that you deploy both the .NET Framework 3.5 with SP1and PowerShell

1.0 and/or 2.0 to each machine to which you will install Service Manager components.

I’m not going to cover the self-service portal requirements in this article as I will be fully covering that component in

another part of this series.

In order to prevent conflicts, before you deploy Service Manager, you should remove any Operations Manager agents

you may have installed on the Service Manager systems. Once Service Manager is deployed, you can reinstall the

Operations Manager agents.

SQL Server Specifics

When you install SQL Server 2008 SP1, there are some specific requirements that you need to handle at installation

time:

Make sure to install the SQL Full-Text Service.

During installation, install and configure the Reporting Services component in the native mode default configuration.

SQL Server must be configured to use case-insensitive databases.

You should not use the default SQL collation as this will prevent Service Manager from being able to support multiple

languages. If you’re English-only, you’ll be fine, but if you later decide to add additional languages, you will need to

reinstall SQL Server.

Configure the SQL Server execution account to be the Local System account.

I’ve included four screenshots below (Figures 1, 2, 3& 4) that show you screenshots from the SQL Server 2008

installation process.

Figure1

Figure 1 shows you which components you should select as a part of the SQL Server installation.

Figure 2

For Service Manager, configure SQL Server to use a Local System account.

Figure 3

Configure SQL Server with an accent sensitive Latin1_General_100 collation.

Figure 4

For Reporting Services, select the Install the native mode configuration option.

Active Directory Task

As the final step in your pre-deployment work, you’ll need to do a little Active Directory work. Create an Active

Directory group for Service Manager administrative usersfor both the data warehouse and Service Manager

management groups. I’ll be using a group named SM-Admins, as per Microsoft documentation.

Introduction

Microsoft continually improves the System Center line in their quest to provide IT organizations with one-stop

shopping for their service and management needs. As the newest entry to the System Center line, Service Desk fills

the end-user void in the company’s management line. In this article, you will learn how to install Service Desk’s base

services as well as the product’s data warehouse components.

As a brand new product in Microsoft’s System Center line, Service Manager rounds out Microsoft’s ITIL/MOF-focused

architecture by bringing centralized, accessible incident and problem management capabilities to bear. In Part 1 of

this series, I discussed in detail the requirements that must be in place before you can install Service Manager. In this

part, I’ll walk through the product’s installation step-by-step.

Install the Service Manager Management Server

As is typically the case with a new software installation, you will need to start the process by presenting the Service

Manager media to your new server. Either insert the installation DVD or mount the Service Manager ISO on the new

server. Once the media has been provided, navigate to the AMD-64 directory and double-click setup.exe. This begins

the setup process and results in the screen you see in Figure 1 below. From this screen choose the Install a Service

Manager management server option.

Figure 1: The Service Manager installation window

The installation program’s second step involves providing your name, organization name and agreeing to the product

license agreement. Click the Next button to continue the process. Figure 2 shows you this window.

Figure 2: Service Manager license agreement

The default installation location for Service Manager is C:\Program Files\Microsoft System Center\Service Manager

2010. If you’d like to choose an alternate location, click the Browse button and identify the location to which you’d like

to install Service Manager. The installation location window is shown in Figure 3. Click the Next button to move on

with the process.

Figure 3: Choose a Service Manager installation location

At this point, the installation tool verifies that your server meets the requirements. The installer checks the amount of

RAM in the system, the processor speed and also checks to see whether or not two prerequisites have been

installed. If either of those two prerequisites are missing, a download link will appear in the system check results

window. As you can see in Figure 4, my lab system has only 1GB of RAM installed while Microsoft recommends

having at least 4GB installed.

Before installing Start downloading ― Authorization Manager Hotfix ―

Figure 4: Service Manager system check results

The real work starts on the next page of the installation wizard where you’re asked to provide information about the

Service Manager database. The primary need here is to specify the name of the database server on which the

Service Manager database is to be housed. If you are running a SQL Server instance that is not supported by Service

Manager, that instance will not be listed for your use. Once you provide the name of a database server, the other

details, including the database name, initial database size and data and log file locations will be filled in automatically.

You can change any of these options. In Figure 5, you’ll note that I’ve selected the default options for my Service

Manager installation.

Figure 5: Service management database configuration

Like other System Center products including Operations Manager, Service Manager creates a management group

that can represent one of a number of different aspects of your company – name, division, department, location or

anything else you might like. I’ve decided to create my service manager management group with a name of HQ.

Further, you need to tell Service Manager the name of the Active Directory group that contains user accounts allowed

to management this management group. In part 1 of this series, I created an Active Directory group named SM-

admins and populated it with some user accounts. I’ve specified that Active Directory group name on the

management group configuration page shown in Figure 6.

Figure 6: Configure the initial management group

Service Manager’s services can run under the context of the Local System account or under a domain account. For

security reasons, the use of a domain account is generally preferred. During the installation process, you can click the

Test Account button to make sure that the credentials are correctly configured. In Figure 7, you’ll notice that the

account provided was not a member of the Administrators group on the local machine. Once that account was added

to the local Administrators group – Figure 8 – the credentials are accepted as valid.

Figure 7: The account is not yet correctly configured

Figure 8: The account is configured correctly

Service Manager routes information using workflows which run under a separate service account. As is the case with

the basic Service Manager service account, this account can be either Local System or a domain service account. In

Figure 9, you will notice that I’m using the same domain account for both the Service Manager and the Service

Manager workflow services.

Figure 9: Service Manager workflow account

With many of their products, Microsoft gathers usage information that can help the company correct any issues that

might arise during program use. If you’d like to take part in this Customer Experience Improvement Program, select

Yes and click Next.

Figure 10: Customer Experience Improvement Program participation

Software updates keep your new installation protected from flaws that crop up from time to time. Some administrators

prefer to handle all updates manually in order to test them in a lab environment before deployment while other simply

want updates to be installed as quickly as possible. If you want updates quickly and automatically, choose the Use

Microsoft Update option on the next screen of this wizard. Otherwise, select I do not want to use Microsoft

Updatesoption.

Figure 11: Decide how you want to handle software updates

At this point, you’ve made the necessary choices that get Service Manager up and running. On the Installation

summary page, click the Install button to commence the installation.

Figure 12: Service Manager installation summary

When the product is finished installing, you’ll get a completion screen like the one shown below in Figure 13.

Figure 13: Service Manager is installed

Install the Data Warehouse Management Server

With the base management server now installed, you can turn your attention to installing the data warehouse

management server which manages, as you might guess, Service Manager’s data warehouse components. These

components add to System Manager the ability to report against historical data and provides a historical analysis

about what’s been going on in your environment.

To get started with installing the data warehouse component, navigate back to the installation location and double-

click setup.exe. On the launch page, click Install a Service Manager data warehouse management server. If you’d

like a refresher on what this screen looks like, take a look back at Figure 1.

Since a lot of the data warehouse installation is identical to the base Service Manager installation, I’m not going to

rehash all of those screens again but will show you what is different.

Before you begin the installation, there is one important configuration step that you must take if you decide to use

different SQL servers for the data warehouse components and reporting services. You must make some manual

configuration changes to SQL Server Reporting Services in order to enable it to work with Service Manager. Microsoft

makes available very clear instructions for this step.

The first screen of the installation wizard that’s of interest is the one on which you configure the data warehouse

databases. In Figure 14, you see that there are three default databases created during installation:

DWstagingAndConfig

DWRepository

DWDataMart

As was the case with the main Service Manager product, the data warehouse component’s database needs to be

configured. During the installation, you’ll see a window that looks very much like the one shown in Figure 14. Unless

you’re in a huge infrastructure, you can use the same database server as you do for Service Manager itself. You can

choose different options for different Service Manager databases if you like. You can also name the databases

anything you like and choose the storage location for the database files.

Figure 14: Data warehouse default installation options

You might recall that you had to create a Service Manager management group during the earlier installation. With the

data warehouse component, you also need to create a management group, but this time for the data warehouse

component. In Figure 15, you’ll see that I’ve chosen to use the name DW_EXAMPLE for this article. I’ve also decided

to use the same SM-admins group administrators that I used for the Service Manager installation.

Figure 15: Data warehouse management group

During the installation of SQL Server, you probably didn’t do a whole lot with regard to the configuration of SQL

Server Reporting Services (SSRS). SSRS is used heavily by Service Manager’s data warehouse component and

needs to be configured. In Figure 17, you can see that I will be using the server named SCSM for the various Service

Manager databases as well as for the Service Manager reporting component.

Figure 16: Provide reporting services information

For reporting to work, Service Manager usesa domain account that you configure to generate reports and to read the

data warehouse data sources. In the interest of simplicity, I’m using the sm account here that I’ve used for the various

service accounts.

Figure 17: Reporting account

Once you’ve run through the various configuration items, the data warehouse installer provides you with an

installation summary that you should review. Once you’ve made sure that the selections are correct, click the Install

button to proceed with the installation.

Figure 18: Data warehouse installation summary

Summary

So far, in part one of this series, you’ve learned how to handle all of Service Manager’s prerequisites and part two

has demonstrated a successful installation process. In the next article in this series, you’ll learn how to start using

Service Manager.

Microsoft System Center Service Manager - Part 3: Initial Configuration

Introduction

Microsoft continually improves the System Center line in their quest to provide IT organizations with one-stop

shopping for their service and management needs. As the newest entry to the System Center line, Service Desk fills

the end-user void in the company’s management line. In this article, you will learn how to install Service Desk’s base

services as well as the product’s data warehouse components.

As a brand new product in Microsoft’s System Center line, Service Manager rounds out Microsoft’s ITIL/MOF-focused

architecture by bringing centralized, accessible incident and problem management capabilities to bear. In Part 1 of

this series, I discussed in detail the requirements that must be in place before you can install Service Manager.

In Part 2, you learned how to install the various Service Manager components.

In this part, you will learn how to initially use and configure Service Manager to most effectively meet the needs of

your organization.

A First Look

At the end of Part 2 of this series, we left Service Manager in a fully installed, ready to be run state. Now, it’s time to

run the software to discover how it operates and to learn how to unlock its capabilities. To start Service Manager,

from any machine to which you’ve installed the Service Manager Console, go to Start >All Programs > Microsoft

System Center > Service Manager 2010 > Service Manager Console.

The first time you run Service Manager on a new system, you’ll be presented with the dialog box that you see below

in Figure 1. You need to specify the name of your Service Manager server and click the Connect button in order to

proceed. Once you do so, the system is initialized, a process that can take a few moments to complete.

Figure 1: Connect to a Service Manager system

Once the initialization process is complete, you get your first look at the Service Manager console itself, which you

can also see below in Figure 2.

V

Figure 2: The Service Manager console

As you can see, there are a number of ―first steps‖ that you need to take in order to make your Service Manager

system usable. However, the first step you need to perform is to register your Service Manager system with the Data

Warehouse component. This is the step that enables reporting in your Service Manager environment.

Register with the data warehouse

The registration process is run via a wizard that you initiate by clicking the link entitled Register with Service Manager

Data Warehouse. The first screen of the registration wizard is shown in Figure 3. This is an information screen that

outlines the purpose of the wizard. Click the Next button to continue.

Figure 3: Start the Data Warehouse Registration Wizard

The first screen of significance (Figure 4) asks you to specify the name of your warehouse management server. Type

the server name and to make sure that the connection works, click the Test Connection button.

Figure 4: Choose the DW server name

Tip:

If the connection doesn’t succeed, verify that the Windows firewall on your data warehouse server is configured to

allow communication from your Service Manager Management server. In Figure 5, I’ve provided a communications

diagram to help you configure the Windows firewall for each of your Service Manager components. For example, if

you intend to eventually import information from your Active Directory, you need to allow incoming traffic from your

Service Manager system on port 389.

Figure 5: A Service Manager Communications diagram

Once you’ve verified that communications with your Data Warehouse server work correctly, move on to configuring

the credentials that you plan to use to access the data warehouse server. In Figure 6 you will see that I’ve chosen the

default account of DW_EXAMPLE SecureReference. This account name will be different for you… unless you’ve

named your environment EXAMPLE! Whatever account you choose needs to be a member of the local

Administrators group on the data warehouse server.

Figure 6: Provide credentials to use for the DW

Before you click the Create button to initiate the process, review your options to make sure that they will work in your

installation.

Figure 7: Review your selections

After the registration is complete, you will receive a notice indicating that the data warehouse registration was

complete. Click the Close button to finish.

Figure 8: DW registration was successful

It can take quite some time (read: hours) for the full deployment process to take place and for your console to be able

to access all of the information stored in the data warehouse. You’ll get a message like the one shown in Figure

9. You can safely ignore this message as it’s for information purposes only. Just understand that you’ll need to wait to

get to your information.

Figure 9: Notification message regarding report availability

Even if the process has not yet completed, you’ll see a couple of new options in the navigation area. Specifically, as

shown in Figure 10, there are now Data Warehouse and Reporting items on the menu. Select the Data

Warehouseoption and then click Data Warehouse Jobs to get a list of the jobs related to the Service Manager Data

warehouse component. This figure also shows you a list of some of Service Manager’s default jobs.

Figure 10: A new navigation option is available

Configure the Data Warehouse jobs

By default, not all of the schedules for these jobs are enabled, but you can fix that.

To enable the jobs necessary for the Data Warehouse component, you need to start PowerShell as an administrator.

Once you’ve done so, execute the commands that you see in the table below.

Command Command description

Add-PSSnapIn SMCmdletSnapIn This adds a snap-in to PowerShell that enables the Service

Manager commands.

Enable-SCDWJobSchedule -JobName

Extract_DW_Example

Enable the job schedule that handles data warehouse

synchronization. Replace "DW_Example" with the name of

your Data Warehouse management group.

Enable-SCDWJobSchedule -JobName Extract_HQ Enable the job schedule that handles extraction of data from

the Service Manager database. Replace "HQ" with the name

of your Service Manager management group.

Enable-SCDWJobSchedule -JobName

Transform.Common

Enables the job that takes raw data and cleanses, reformats,

and aggregates it in order to get it into a final format for

reporting.

Enable-SCDWJobSchedule -JobName Load.Common This command enables the job that queries the data from the

data warehouse.

As a side note, once you’ve enabled a job and it’s running, you can get a look at the specifics by double-clicking the

job name in the Service Manager console. For example, if I double-clicked on Extract_DW_Example as shown in

Figure 10, I’d see a screen much like the one shown in Figure 11. This tells you exactly which modules have

completed. For now, don’t worry too much about the modules. Just understand that you can see status.

Figure 11: Job status

Connecting to Active Directory

With your data warehouse connected to your Service Manager system, turn your attention to connecting to Active

Directory. Service Manager’s Active Directory connector allows you to import users, groups, printers, and computers

from Active Directory as configuration items in the Service Manager database. You’re able to import items from the

whole domain or from a single organizational unit.

Create the connector by clicking the Import user accounts with the Active Directory connector option on the

Administration Overview screen you saw in Figure 2. This starts the Active Directory Connector, the details screen for

which is shown in Figure 12.

Figure 12: Start up the Active Directory connector wizard

You need to provide a name for your new Active Directory connector. If you like, you can also provide a description,

but this is optional. Figure 13 gives you a look at the screen on which you provide this information.

Figure 13: Provide a name for the connector

The next step of the wizard (Figure 14) is one of the two most important parts of the wizard. In this step, you need to

decide on a scope for the Active Directory connector; do you want to allow the connector an unfettered look at the

current Active Directory domain (Use the domain: example.com) or would you rather choose a different domain or

limit the connector’s scope to an organizational unit (Let me choose the domain or OU).

In the Run As account box, provide credentials for a user account that has read rights to Active Directory. I’ve chosen

to use the Operational System Account. This is the same account you specified at the time that you installed Service

Manager. In my case, the Operational System Account is linked to example.com\sm. Once you’ve clicked

the Nextbutton to move on, the Credentials dialog box will open asking you to provide the password for the account.

Figure 14: Determine the connector scope

Once you’ve decided on a scope, move on to object selection. This is the second major part of this wizard. You can

choose to import everything by choosing the All computers, printers, users and user groups option or you can import

specific items by selecting Select individual computers, printers, users and user groups option. If you choose to select

individual objects, click the Add button, choose the object type and then choose the individual objects. In Figure 16,

I’ve chosen to add individual computers to Service Manager.

Figure 15: Decide which objects should be included

Figure 16: Object selection

As always, Microsoft’s wizards are most helpful when it comes to helping you to avoid errors by providing you with a

summary screen outlining the decisions you made during the process. Click the Create button to create the new

Active Directory connector.

Figure 17: Confirm your selections

Success means a green arrow is in your future! If you see a green arrow like the one in Figure 18, you’ve done well.

To verify that the connector actually exists in your Service Manager environment, go to Administration >

Connectors. Figure 19 shows you the new ADtoSM connector that I just created. If the synchronization has yet to

commence, select the connector and click the Synchronize Now button. To view the status of the synchronization,

you might need to move the Task Pane out of the way (click the > symbol to the left of the word Tasks). Figure 20

shows you more.

Figure 18: The connector was created

Figure 19: The new connector has been created

Figure 20: Connector synchronization status

At the end of the synchronization process, you can get a look at a number of the objects that were imported from

Active Directory – such as the list of computer objects – by going to the Configuration Items navigation area and

chooseConfiguration Items > Computers > All Windows Computers. In Figure 21, you’ll see that three computer

objects have been imported from Active Directory. These are the Service Manager systems (plus the domain

controller) in my example domain. In Figure 22, I’ve selected the Users option under Configuration Items to give you

a look at the users that were imported.

Figure 21: Three computer objects were imported

Figure 22: A list of the users imported into Service Manager

Summary

At the conclusion of part three of this series, your new Service Manager system’s installation is complete and the

Service Manager and data warehouse components are talking nicely to one another. In part 4, you’ll learn about

configuration steps that you need to take to start using your Service Manager system, including settings options

related to problems, incidents, activities, change requests and data retention

Microsoft System Center Service Manager - Part 4: Initial use of the product

In the first three parts of this series, you learned about the prerequisites, installation and initial configuration steps

associated with Microsoft’s newest entry in the System Center line: Microsoft System Center Service Manager. As

the newest entry to the System Center line, Service Desk fills the end-user void in the company’s management line.

In this article, you will move from the more behind-the-scene items related to Service Manager to initial actual use of

the product. Specifically, you’ll learn about configuration steps that you need to take to start using your Service

Manager system, including settings options related to users, problems, incidents, activities, change requests and data

retention.

Terminology

You can tell that massive frameworks are complex when they require thousands of pages of literature and teams of

consultants to implement them. The Information Technology Infrastructure Library (ITIL) is an example of one such

framework. Based on ITIL, the Microsoft Operations Framework (MOF) has the following definitions:

Incident. In ITIL-speak, an incident is defined as anything that takes place that results in any kind of failure in the

infrastructure. In some cases, an incident may be symptomatic of a larger problem. An example of an incident might

be a failed network switch or a crashed PC.

Problem. Problems arise as a result of incident identification in an environment. A problem comes into play when an

incident can’t be solved or when a group of incidents begins to point to some common root cause that needs to be

solved. For example, if the same user keeps calling with a PC crashing incident and a reboot solves the incident,

there is evidence of a larger problem that needs to be solved.

Change Request. Any kind of modification – addition, change, removal – of anything to or from currently supported

and baselined infrastructure items such as desktop computers, network components, application settings or software

programs.

Activity. An activity is a unit of work that is performed as part of managing a problem, resolving an incident, or

completing a change request or any other work item.

Configuring incident settings

Bearing in mind that incidents will be the most common item addressed by the service desk, we’ll start by discussing

some configuration options that you have with regard to incidents. These settings are configured by going to

Administration > Settings > Incident Settings. Select Incident Settings and from the Tasks pane at the right-hand side

of the screen, click Properties. This opens the Incident Settings window.

On the General tab of the Incident Settings window, shown in Figure 1, provide to Service Manager a prefix that will

be used as new incidents are raised. As users report incidents to the service desk, more detail is better. Therefore,

users might be inclined to attach files to the incident report to help define the scope of the incident. Also on the

General tab, specify the maximum number of files as well as the maximum size of the files that can be attached to an

incident report. Finally, choose the default support group to which incoming incidents are assigned.

Figure 1: Incident General Settings

When you click on the Priority Calculation option in the Incident Settings window, you will get the screen shown in

Figure 2. On this screen, you see that there is a matrix that shows Urgency and Impact on a chart. By default, there

are nine drop down items with each accepting a value from 1 to 9. In Service Manager’s defaults, 9 is the lowest

priority while 1 is the highest. So, a high urgency, high impact incident would be a priority 1 item while a low impact,

low urgency incident deserves a 9 priority. These priority calculations are created based on the needs of each

individual organization.

Figure 2: Incident priority calculation

When it comes to service desk response time, a priority 1 issue certainly requires faster turnaround than a priority 9

issue. On the Resolution Time tab, choose a target resolution time for each priority level. As you can see in Figure 3,

you can associate each priority level a target resolution time. For example, for priority 1 issue – high urgency, high

impact – might have a 1 hour resolution time, but priority 9 issues might get a week, a month or even a year by

default. Make sure that you define realistic resolution times.

Figure 3: Determine resolution SLAs per priority level

Service Manager can integrate with both Configuration Manager and Operations Manager to create a full-service IT

management and monitoring system. If you’re running System Center Operations Manager and you want to integrate

it with Service Manager, provide the address for the web console URL on the Incident Settings tab shown in Figure 4.

Figure 4: Provide the Operations Manager web console URL

Finally, if you want to enable your Service Manager installation to pick up email messages, configure the settings on

the Incoming E-Mail tab with locations for both the SMTP drop folder and the bad folder. Also, if you want to limit the

number of incoming messages, change the value in the field next to Maximum number of e-mail messages to

process at a time.

Figure 5: Configure incoming e-mail settings

You probably noticed that everything shown was defaults – blanks and a default number of urgency and impact

options. You can add additional impact and urgency levels if you like. Go to the Library navigation item and choose

Lists. On the list of Lists, you’ll see options for Impact and Urgency (Figure 6). Double-click one of the lists to open

the Properties page for that list. On the List Properties page, click the Add Item button to add a new item to the list.

You’ll be asked to choose a management pack in which to store updates. You can save them to the unsealed Default

Management Pack or create a new management pack just for changes. You should avoid using the Default

Management Pack for these kinds of changes when you can and choose instead to create a new management pack

by clicking the New button on the requested screen (Figure 7).

Figure 6: Library list items

Figure 7: Select management pack

In Figure 8, you’ll see that I’ve clicked the New button and I am creating a new management pack called

Customizations. I’ve provided a name for the management pack as well as a description.

Figure 8: Create a new management pack

Once you’ve created the new management pack, you can add new items to the list. You’ll see in Figure 9 that I’ve

added two new items – Low/Medium & Medium/High to the list. Now, if I go back to the Incident Settings page, I see

the priority options show in Figure 10. As a note, you’ll see that there are no assigned priorities for the new options.

You have to set those after you create the new list items.

Figure 9: New list options have been added

Figure 10: The new priority matrix

Configuring problem settings

You learned earlier about the differences between incidents and problems and also learned that you should have

fewer problems than incidents in your organization. In Figure 11, you’ll see the settings available for configuring

Problem records. As was the case with incidents, problem records get a prefix, which defaults to ―PR‖. In the Priority

section, you’ll see that the new urgency and impact items we created earlier have made their way to the problems

page.

Figure 11: Problem settings configuration

Configuring change settings

Changes that are made to your infrastructure are recorded via change requests in Service Manager with the default

prefix of CR, as you can see in Figure 12. Change requests can include files that document the change. On the

Change Request Settings page, you can decide how many files can be attached and the size of those files.

Figure 12: Configure your change request settings

Configuring activity settings

Any time a technician works on a problem, incident or change request, that activity should be logged so that there is a

clear activity record that can be traced for future reference, if necessary. If you go to the Activity Settings area (Figure

13), you’ll have a place where you can decide which prefixes to use for different kinds of activity logging. There are

three activity prefixes to configure:

Activity prefix. The default prefix is AC.

Manual activity prefix. The default prefix is MA.

Review activity prefix. The default prefix is RA. When activities are reviewed, this prefix will be used.

Figure 13: Configure activity request settings

Configuring e-mail notifications

Go to Administration > Notifications > Channels and select E-Mail Notification Channel. Next, from the Tasks pane,

click the Configure option. Your first task is the select the checkbox next to Enable e-mail notifications. Then, click the

Add button to open the Add SMTP Server window. Provide the fully-qualified domain name for your SMTP server, a

port number and an authentication method. If you choose an anonymous authentication, make sure to configure your

mail server for relay from the Service Manager system. If you use multiple SMTP servers, use the Up and Down

buttons to change the order in which SMTP servers will be used. Figure 14 shows you more.

Figure 14: Configure an e-mail notification channel

Managing incident classifications

Service Manager comes with a number of default incident classifications, including networking problems, software

problems, e-mail problems and more. It’s expected that you will change the default incident classifications list to meet

the needs of your organization. To do so, go to the Library, select Lists and choose Incident Classification. From the

Tasks pane, click the Properties option. Use the Add Item button to add new items to the list. You can also choose to

remove existing items by selecting that item and clicking the Delete button.

Figure 15

Creating an incident

With some basic information now in place, let’s create a sample incident using the Service Manager console and see

what happens. Go to the Work Items navigation area and choose Work Items > Incident Management. From the

Tasks pane, click Create Incident. This opens up a page like the one shown in Figure 16.

Figure 16: New incident creation form

On the page shown in Figure 16,

Affected user. I’ve selected an affected user by clicking the ―…‖ button to the right of the Affected user box.

Title & description. In the title and description boxes, I’ve typed in relevant information.

Classification category. Use the drop down arrow at the right hand side of the box and choose an appropriate

category.

Source. There are many ways for a new incident to be raised in Service Manager. In this case, I’ve used the console

to add a new incident. Other options include e-mail, phone, the self-service portal and Operations Manager.

Impact. What kind of impact does this incident have?

Urgency. What is the urgency for getting the incident resolved?

Priority. You can’t change the priority here since it’s a function of the matrix we discussed earlier. This is pulled from

that matrix.

Support group. To what group is this incident assigned.

Assigned to. The name of the specific person handling the request.

Summary

In this part of the series, you learned how to start using Service Manager to record incidents and learned what impact

your configuration changes have on the process.