Upload
sai-kumar
View
44
Download
1
Tags:
Embed Size (px)
DESCRIPTION
This is for knowledge purpose.... on SCSM implementation
Citation preview
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.