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

If you would like to read the other parts in this article series please go to:

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 itens, 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.

Summary

In part two of this series, we’ll cover the installation and configuration of Service Manager.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top