Microsoft System Center 2012 - Service Manager

The Planning and Design Series Approach

This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies.

Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics:

  • Defining the technical decision flow (flow chart) through the planning process.
  • Describing the decisions to be made and the commonly available options to consider in making the decisions.
  • Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
  • Framing the decision in terms of additional questions to the business to ensure a comprehensive understanding of the appropriate business landscape.

The guides in this series are intended to complement and augment the product documentation. It is assumed that the reader has a basic understanding of the technologies discussed in these guides. It is the intent of these guides to define business requirements, and then align those business requirements to product capabilities and design the appropriate infrastructure.

Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective service manager technology.

Benefits for Business Stakeholders/Decision Makers:

  • Most cost-effective design solution for an implementation. Infrastructure Planning and Design (IPD) eliminates over-architecting and overspending by precisely matching the technology solution to the business needs.
  • Alignment between the business and IT from the beginning of the design process to the end.

Benefits for Infrastructure Stakeholders/Decision Makers:

  • Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
  • Business validation questions to ensure the solution meets the requirements of both business and infrastructure stakeholders.
  • High-integrity design criteria that includes product limitations.
  • Fault-tolerant infrastructure, where necessary.
  • Proportionate system and network availability to meet business requirements.
  • Infrastructure that is sized appropriately to meet business requirements.

Benefits for Consultants or Partners:

  • Rapid readiness for consulting engagements.
  • Planning and design template to standardize design and peer reviews.
  • A "leave-behind" for pre- and post-sales visits to customer sites.
  • General classroom instruction/preparation.

Benefits for the Entire Organization:

Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for achieving stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.

Introduction to Microsoft System Center 2012 - Service Manager Guide

Microsoft System Center 2012 - Service Manager provides an integrated platform for automating and adapting an organization's IT service management best practices, such as those found in the Microsoft Operations Framework (MOF) and IT Infrastructure Library (ITIL). It provides built-in processes for incident and problem management, change management, service request fulfillment, release management, service level management, and configuration management. This guide assumes that the reader has some knowledge of Service Manager.

Figure 1. System Center 2012 capabilities and components

This guide leads the reader through a methodical process of determining the business requirements for the Service Manager infrastructure, and then using those results to design a Service Manager implementation that is consistent with and optimized for the organization. The product group provides the next-step documentation in areas such as general planning, deployment, administration, operations, and authoring.

When used in conjunction with product documentation, this guide will help organizations confidently plan a Service Manager implementation. Appendix A includes sample job aids for recording the decisions made during the design process.

What's New in System Center 2012 - Service Manager

This guide has been revised to include these new enhancements in Service Manager that may affect the infrastructure choices and design.

  • Scale improvements:
    • Up to 80 analyst consoles are supported per management server.
  • New connectors:
    • Microsoft System Center 2012 - Virtual Machine Manager
    • Microsoft System Center 2012 - Orchestrator
    • Microsoft System Center 2012 - Operations Manager
    • Microsoft System Center 2012 Configuration Manager
  • Portal:
    • The Portal includes SharePoint Web Parts, requiring one of the following versions of Microsoft SharePoint®:
      • Microsoft SharePoint Foundation 2010
      • Microsoft SharePoint Server 2010
      • Microsoft SharePoint 2010 for Internet Sites Enterprise
    • Microsoft .NET Framework 4
    • Microsoft Silverlight® 4 (required only on the client)
    • Windows® Internet Explorer® 8 and Internet Explorer 9 (required only on the client)
  • Reporting:
    • Microsoft SQL Server® 2008 Analysis Services
    • Standard edition supported
    • Enterprise edition provides better usability, scale, performance, and cube maintenance

Windows XP is no longer supported for Service Manager consoles.

Service Manager Design Process

This guide addresses the following decisions and/or activities, which need to occur in planning for Service Manager:

  • Step 1: Define the Project Scope and Requirements
  • Step 2: Design the Management Groups
  • Step 3: Design the Service Manager Management Server Infrastructure
  • Step 4: Design the Data Warehouse Management Server Infrastructure

Figure 2 provides a graphical overview of these steps.

Figure 2. The Service Manager infrastructure decision flow

Some of these items represent decisions that must be made. Where this is the case, a corresponding list of common response options is presented in the sections that follow. Other items in this list represent tasks that must be carried out. These types of items are addressed, because their presence is significant for completing the infrastructure design.

The mandatory and optional components of a Service Manager architecture are shown in Figure 3.

Figure 3. Example Service Manager architecture

The mandatory roles for a Service Manager implementation are:

  • Service Manager management server
  • Service Manager database
  • Service Manager console

The optional components of a Service Manager implementation are:

  • Additional Service Manager management servers
  • Service Manager Portal servers
  • Data warehouse databases
  • Data warehouse management server
  • Service Manager Authoring console
  • Connectors to other systems, such as Active Directory® Domain Services (AD DS), Configuration Manager, Operations Manager, Virtual Machine Manager, Orchestrator, or third-party systems.

Table 1 provides descriptions of these Service Manager components.

Table 1. Service Manager Components with Descriptions

Component

Description

Service Manager management server

The Service Manager management server consists of:

  • System Center Management service (on the management server only), which indirectly runs the workflows defined in management packs using the System Center Management Service Host processes.
  • System Center Data Access Service service, which provides programmatic access to Service Manager for clients, such as the Service Manager console and the Service Manager connectors.
  • System Center Management Configuration service, which provides configuration settings to all management servers in a management group.

Service Manager database

A Microsoft SQL Server database that contains the Service Manager configuration items (CIs) from the IT enterprise and work items such as incidents, change requests, and the configuration for the product itself. This is Service Manager's implementation of a configuration management database (CMDB).

Service Manager console

The user interface (UI) for analysts and administrators to perform Service Manager functions, such as incidents, problems, service requests, changes, and tasks. It is automatically installed on the Service Manager management server and can also be installed separately on additional client computers.

Service Manager Portal

The Service Manager Portal consists of two elements:

  • A SharePoint website, accompanied by a set of applications built with Silverlight.
  • A Web Content Server, which is a Web Application that forms the interface between the Silverlight application and the Service Manager management server.

Data warehouse databases

These databases are used as the source for all Service Manager reports. Collected management data is periodically groomed in the data warehouse database from the Service Manager database to reduce the size of the Service Manager database and to improve the response time for performing updates to the database.

Data warehouse management server

Runs the processes (jobs) for managing the collected management data in the data warehouse database, including grooming data from the Service Manager database into the data warehouse database. Also grooms the data from the data warehouse after the duration specified in a configurable retention policy.

Following the instructions in this guide will result in a design that is sized, configured, and appropriately placed to deliver the stated business benefits while also considering the performance, capacity, and fault tolerance of the system.

This guide addresses the scenarios most likely to be encountered by someone designing a Service Manager infrastructure. However, customers with complex environments should consider having their architecture reviewed by Microsoft Consulting Service prior to implementation, because that organization is best able to comment on the supportability of a particular design.

Step 1: Define the Project Scope and Requirements

Before designing a Service Manager infrastructure, an organization needs to determine the objectives for the project and which parts of its environment to include in the design. Service Manager includes Change Management, Incident Management, and Problem Management process management packs as part of the minimum product implementation, and other packs are available from Microsoft and partners.

The tasks to be performed in this step are:

  1. Determine the business requirements.
  2. Determine the technical requirements.

In this step, the systems and/or applications that will be integrated with the Service Manager infrastructure project will be identified. To understand the key performance characteristics that the Service Manager infrastructure will be subjected to and the expected response times for the service, the user load and fault-tolerance requirements for each service will be determined.

In addition, questions will be asked (for example, availability requirements) of the business decision makers in the organization to determine the scope and requirements of the Service Manager implementation. Also, the technical requirements will be determined in this step. Information will be gathered (for example, information relative to capacity, connectors, and management packs) from the technical decision makers in the organization to determine the scope and requirements of the Service Manager implementation.

The output of this step will in turn drive decisions relative to designing the management groups, the Service Manager management server infrastructure, the Service Manager data warehouse management server infrastructure, and the Service Manager connectors.

Task 1: Determine the Business Requirements

In this task, questions will be asked of the business decision makers in the organization to determine the scope and requirements of the Service Manager implementation.

Features and Scope Requirements

The following questions should be asked of the business to determine the scope and the features that will be implemented:

  • Which parts of the organization will participate? Before the architecture can be designed, the scope of the project must be determined so that the planners know the boundaries for which they are building a solution. The scope of the project could be enterprise-wide, one or many locations, or just a single department.
  • Would a business or governance policy affect the design of the system? Organizations may have administrative boundaries that will affect the Service Manager infrastructure. For instance, separate systems may currently be used for service management for each IT department or region. In later steps, the decision will be made whether to continue maintaining multiple systems or use a single Service Manager implementation, potentially with multiple management groups.
  • Does the business have a need to automate the enforcement and measurement of IT controls through the IT life cycle? The answer to this question will determine whether the IT Governance, Risk, and Compliance (GRC) process management pack should be implemented to automate the validation of control activities and report on their compliance state over time.
  • What relationship will Service Manager have with other systems or information sources? Service Manager can integrate information from other sources, such as Configuration Manager or Operations Manager, or other non-Microsoft systems such as existing ticketing systems. This will determine the connectors required to integrate information from other sources.
  • Does the business plan to implement any add-in management packs to extend the functionality of Service Manager? A listing of published management packs from Microsoft and partners is available at http://pinpoint.microsoft.com.
  • Are historical retention of and reporting on change or incident information required? The organization may be required to retain information such as change configuration approvals for a certain time period. This will determine whether the data warehouse will be implemented and drive storage capacity planning.
  • Does the business want users to be able to interact directly with Service Manager via a portal? The Service Manager Portal is an optional component of Service Manager that provides a website for users, who can access it to contact help desk personnel for help requests, search the knowledge base, perform tasks, and manage requests. The portal displays the new service catalog, the Service Request Management capabilities and the knowledge base that allow organizations to centrally manage the services and requests that can be made through the portal.

Record the answers to these questions in Table A-1 in Appendix A: "Job Aids."

Availability Requirements

Careful consideration should be given to the availability requirements for each functional area. The business should understand and rate the significance of the risk of possible data loss or interruption of business, and then the architect will use this information to select an appropriate fault-tolerance approach for the systems involved.

For each of the areas listed below, IT should assess the importance of the functionality as High or Low impact relative to interruption of service and record those answers in Table A-2 in Appendix A. Note that each High impact answer increases the cost and complexity of the design.

  • Users accessing the Service Manager Portal. Users can use the Service Manager Portal to perform such tasks as viewing global announcements, searching and viewing knowledge base articles, creating and viewing service requests, creating incidents, or any other task that can be automated using scripts or Orchestrator runbooks.
  • Analysts accessing the Service Manager console. Analysts can use the console to manage incidents, problems, changes, and activities assigned to them. Determine how their work will be impacted if they don't have access to Service Manager.
  • Management accessing historical reports. If the organization will implement historical reporting, determine and understand the impact of the historical reporting system being unavailable for the period of an outage.
  • Historical reports containing up-to-date data. Assess the impact of the reporting system being available but the data in it not being updated (stale data) for the period of an outage.

In addition, the items below represent areas that cannot be made completely fault tolerant because they rely on the Service Manager management server in charge of running workflows and are noted for informational purposes:

  • Workflows. The scheduled or event-based activities that Service Manager performs.
  • Connectors. Allow information to be synchronized or imported from other systems.

Task 2: Determine the Technical Requirements

In this task, information is gathered from the technical decision makers in the organization to determine the scope and requirements of the Service Manager implementation.

Capacity Requirements

To effectively implement Service Manager in an enterprise, it is critical to understand the key performance characteristics to which the service will be subjected. Refer to the information that the organization provided in Task 1 for the administrative boundaries that will be included, and then ask the following questions of the technical personnel in the organization:

  • What is the approximate number of end users and devices that are supported in the organization, and that will be supported in the Service Manager database? This information will determine the scale of the Service Manager implementation and the number of Service Manager management servers that will be required.

    Note   The maximum size of a Service Manager implementation that the product group currently supports is 50,000 computers.

  • What is the expected usage? Determine the number of work items such as incidents, service requests, change requests, releases, and problems that will be entered per month for capacity planning and database growth of Service Manager. This information might be obtainable from the current service management system.
  • What is the approximate number of users who may access the Service Manager Portal? Assess the user population that Service Manager will manage, and then record the approximate number of users expected to access the portal concurrently. This information will assist in determining portal server sizing and placement.
  • What is the approximate number of analysts in each location? Assess the analysts, such as help desk technicians and administrators, who will use Service Manager consoles, and record the physical locations and approximate number of consoles that are expected to be in use concurrently. The number of consoles open at each location will inform management server sizing and placement and whether technologies such as remote desktop sessions might be required to ensure adequate console performance for a remote analyst.

Record the answers to these questions in Table A-3 in Appendix A.

Connector Requirements

Service Manager connectors can import data as CIs from other systems, including data in the form of comma-separated value (CSV) files. Connectors included as part of management packs can also be used to synchronize data between other systems and CIs in the Service Manager database. See Appendix B: "Connectors" for further information about the Service Manager connectors.

The following questions should be asked to determine the import and synchronization methods in scope:

  • Will Service Manager integrate with Active Directory Domain Services (AD DS)? If so, which forests and domains are in scope? An Active Directory Connector (ADC) can be used to add users, groups, printers, and computers (and only these object types) as CIs into the Service Manager database. Complete domain, organizational unit (OU), or a selection of different objects are source configurations that can be set during creation of the connector. Data can be imported from domains other than the domain in which Service Manager resides if trust relationships are in place by using a service account and creating an additional ADC. The ADC requires an account with the rights to read in AD DS.

    Each Service Manager management group can have an unlimited number of ADCs, and each AD DS domain may have connectors to an unlimited number of Service Manager management groups. Data is imported one way from AD DS to Service Manager, with no data passed from Service Manager back to AD DS.

  • Will Service Manager integrate with Operations Manager? If so, which Operations Manager connectors will be used? If the organization uses System Center Operations Manager 2007, System Center Operations Manager 2007 R2, or System Center 2012 - Operations Manager to monitor systems, the agents that are deployed gather information about CIs that are discovered; as problems are detected, Operations Manager generates alerts. Two connectors for Operations Manager are available in Service Manager: the CI connector, which imports objects that are discoverable by Operations Manager in the Service Manager database, and an alert connector, which can create incidents based on alerts.

    Operations Manager CI connectors are one way from Operations Manager to Service Manager, while alert connectors are bi-directional connectors. One of each connector is required per Operations Manager management group to each Service Manager group. A given Operations Manager management group can have connectors to multiple Service Manager management groups, and a given Service Manager management group can be connected to multiple Operations Manager management groups.

  • Will Service Manager integrate with Configuration Manager? If so, which site databases? Configuration Manager provides a distributed infrastructure for discovery and collection of hardware and software inventory information, software deployment, software updates, and configuration management. The information that Configuration Manager collects can be imported, and then stored in the Service Manager database by using a Configuration Manager connector. Importing data by using a Configuration Manager connector can add details about a CI that has already been imported by using an ADC or adding new CIs that do not exist in AD DS domains.

    Multiple Configuration Manager connectors can be used to import data from different Configuration Manager site databases, but each Service Manager management group only needs one connector to a given Configuration Manager site; connectors to child sites are not required. If necessary, a Configuration Manager site can have connectors to multiple Service Manager management groups, because the communication flows one way from Configuration Manager to Service Manager.

Note   If the organization plans to relate computers to users, the Asset Intelligence must be enabled with at least processor data and software inventory and licensing WMI classes selected.

  • Will Service Manager integrate with Virtual Machine Manager (VMM)? If so, which VMM instances will be integrated? The VMM connector provides the ability to import objects, such as clouds, templates, and virtual machines that are created in VMM into the Service Manager database by creating a VMM connector. After these objects are imported into the Service Manager database, these objects can be used, for example, to create service offerings.

    Each VMM connector can only connect to one VMM instance. A separate connector is required for each VMM instance that will be synchronized with Service Manager.

    Note   If VMM is configured to push discovery data to an Operations Manager server, include an Operations Manager CI connector in the design.

  • Will Service Manager integrate with Orchestrator? If so, which runbook activities need to be synchronized? The Orchestrator connector provides the capability to synchronously invoke runbooks from within Service Manager through the use of workflows. This capability provides integration between Orchestrator automation capabilities with the Service Manager Portal, as well as business modeling capabilities. When this capability is combined with the Service Manager service catalog stack, it is possible to create an end-user-facing request offering with an Orchestrator runbook as part of the fulfillment process.

    Activities that make up a service request can be mapped to runbook activities, which in turn are mapped to an Orchestrator runbook. For example, the parameters that are necessary for a custom start activity to invoke a runbook in Orchestrator, such as a computer name, can go into Service Manager as objects. This process is started by importing runbook objects into the Service Manager database using an Orchestrator connector. After the runbooks are imported into Service Manager, they appear in the Library node in the Administration workspace.

    Each Orchestrator connector can only connect to one Orchestrator instance. A separate connector is required for each Orchestrator instance that will be synchronized with Service Manager.

  • Will any other custom connectors be used to integrate Service Manager with other systems? Other connectors, such as those that Microsoft partners create, can also be used to populate the Service Manager database. Determine whether these connectors have any special requirements that might affect the infrastructure.

Record the answers to these questions in Table A-4 in Appendix A. See Appendix B: "Connectors" for further information about the Service Manager connectors.

Management Pack Requirements

Service Manager is used to manage service management information through management packs. A management pack is a grouping of classes, workflows, views, forms, reports, and knowledge that extends Service Manager with the information necessary to implement all or part of a service management process. By default, Service Manager contains several preimported, sealed management packs that enable core Service Manager features, such as incident management and change management. For example, the Incident management pack provides the necessary information to enable Service Manager to implement the incident management process. A listing of published management packs from Microsoft and partners is available at http://pinpoint.microsoft.com.

Because management packs may have requirements beyond the requirements of the Service Manager infrastructure, the architect should refer to the listing of management packs in scope determined in Task 1 and ask the following questions prior to designing the infrastructure:

  • Should additional management packs that were not identified by the business decision makers be included as a part of the solution?
  • What managed devices are to be managed by which management pack?
  • Do the management packs have their own requirements beyond Service Manager's requirements?

Record the details relative to technical requirements for the Service Manager implementation in Table A-5 in Appendix A.

Step Summary

In this step, questions were asked (for example, availability requirements) of the business decision makers in the organization to determine the scope and requirements of the Service Manager implementation. In addition, the technical requirements were determined in this step. Information was gathered (for example, information relative to capacity, connectors, and management packs) from the technical decision makers in the organization to determine the scope and requirements of the Service Manager implementation. The information collected in this step was recorded in Tables A-1, A-2, A-3, A-4, and A-5 in Appendix A.

The output of this step will in turn drive decisions relative to designing the management groups, the Service Manager management server infrastructure, and the data warehouse management server infrastructure.

Additional Reading

  • Using Connectors to Import Data into System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh524326.aspx
  • Configuration Manager: http://technet.microsoft.com/en-us/library/gg682129.aspx
  • Operations Manager: http://technet.microsoft.com/en-us/library/hh205987.aspx
  • Virtual Machine Manager: http://technet.microsoft.com/en-us/library/gg610610.aspx
  • Orchestrator: http://technet.microsoft.com/en-us/library/hh237242.aspx
  • Planning Guide for System Center 2012 - Service Manager: http://technet.microsoft.com/library/hh495542.aspx
  • Deployment Guide for System Center 2012 - Service Manager: http://technet.microsoft.com/library/hh495575.aspx
  • Administrator's Guide for System Center 2012 - Service Manager: http://technet.microsoft.com/library/hh519705.aspx
  • Operations Guide for System Center 2012 - Service Manager: http://technet.microsoft.com/library/hh519673.aspx
  • Software Requirements for System Center 2012 - Service Manager: http://technet.microsoft.com/en-za/library/hh519608.aspx
  • Language Support for System Center 2012 - Service Manager: http://technet.microsoft.com/en-za/library/hh495583.aspx
  • Appendix A - List of User Role Profiles in System Center 2012 - Service Manager: http://technet.microsoft.com/en-za/library/hh495625.aspx
  • Cmdlets in System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh305229.aspx
  • Glossary for System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh750212.aspx
  • Network Load Balancing Deployment Guide: http://technet.microsoft.com/en-us/library/cc754833.aspx

Step 2: Design the Management Groups

In the previous step, questions were asked of the business decision makers in the organization to determine the scope and requirements of the Service Manager implementation. In addition, the technical requirements were determined, and the information collected in the previous step was recorded in Tables A-1, A-2, A-3, A-4, and A-5 in Appendix A.

There are two types of Service Manager management groups:

  • Service Manager management groups
  • Data warehouse management groups

The data warehousing functionality of Service Manager is optional and can be implemented to provide reporting and storage of data.

The tasks to be performed in this step are:

  1. Determine the number of Service Manager management groups.
  2. Determine the number of data warehouse management groups.
  3. Align the Service Manager management groups to the data warehouse management groups.

The output of this step will in turn drive decisions relative to the design of the Service Manager management server infrastructure and the design of the Data Warehouse management server infrastructure.

Task 1: Determine the Number of Service Manager Management Groups

In this task, the number of Service Manager management groups will be determined. Service Manager management groups are used to define an administrative boundary for managed devices. The Service Manager database stores all the configuration information and CIs for a management group. An organization can have one or more management groups to define different administrative boundaries for managed devices.

Start with a single Service Manager management group, and add others only if needed for:

  • Larger-scale deployments. Each management group should be limited to a maximum of 50,000 users or computers.
  • Security and administrative requirements. Partitioning management groups for security and administrative reasons is similar in concept to the delegation of administrative authority over AD DS organization units or domains to different administrative groups. The organization might include multiple IT groups, each with their own area of responsibility. The area might be a certain geographical area or business division. For example, in the case of a holding company, it can be one of the subsidiary companies. Where this type of full delegation of administrative authority from the centralized IT group exists, it might be useful to implement management group structures in each of the areas.
  • Separate test environments. An environment separate from the main production implementation can be used for testing changes to Service Manager.
  • Disaster recovery functionality. In Service Manager, all interactions with the system are recorded in transaction logs prior to being committed to the database. Those transaction logs can be sent to another SQL Server instance and committed to a copy of the database there. This technique is called log shipping. The destination or failover management group does not need to be a fully populated and active management group. It can consist of a single management server and database. If it is necessary to execute a failover, the remaining management servers in the source management group require a registry change and a restart to start acting as members of the failover management group, and a new workflow server will need to be designated by running a Structured Query Language (SQL) script.

There is no limit to the number of Service Manager management groups that could exist in an organization, but additional Service Manager management groups add complexity and cost, because each requires a separate server and database. Service Manager management groups exist as separate entities that cannot connect directly to each other, only to data warehouse management groups for historical reporting. A maximum of five Service Manager management groups can connect to a data warehouse management group.

Refer to the scope defined in Step 1 to determine whether multiple Service Manager management groups will be required. Record the populations that each management group serves in Table A-6 in Appendix A.

Task 2: Determine the Number of Data Warehouse Management Groups

The data warehouse components are optional and may be implemented to provide reporting and storage of data and/or to assist with performance issues. In this task, it will be determined whether the data warehouse is required; if so, the number of data warehouse management groups will be determined.

Refer to the requirements identified in Step 1 to determine whether any of these were required by the business or technical decision makers:

  • Generation of Service Manager reports, as determined in Step 1, Task 1.
  • Historical storage of configuration information, as determined in Step 1, Task 1. The data warehouse is optimized for long-term data storage.
  • Any identified management packs require access to data warehouse components, as determined in Step 1, Task 2. For example, the IT GRC process management pack requires the data warehouse component to integrate with System Center 2012 Configuration Manager automatically.

Record this information in Table A-7 in Appendix A.

If none of these elements is required, then the data warehouse functionality of Service Manager does not need to be implemented. Continue to Step 3 to design the Service Manager management server infrastructure.

If any of these requirements do apply, continue with this task to determine the number of data warehouse management groups required and map the Service Manager management groups to data warehouse management groups.

As mentioned in Task 1, Service Manager management groups cannot connect directly to each other, only to data warehouse management groups. A data warehouse can have connections with up to five Service Manager management groups, allowing a single report to incorporate data from multiple Service Manager management groups in the organization.

Data warehouse management groups are used to define an administrative boundary for reporting from the data warehouse. An organization could have multiple data warehouse management groups, but the groups will be completely separate from each other.

Security and roles can be used to control what data is visible to groups of data warehouse users or analysts, so start with one data warehouse management group and add others only if needed for:

  • Legal or local security requirements. Storing data in separate databases or administrative boundaries may be required for different groups.
  • Increased capacity. Service Manager has no built-in limits relative to the number of connections that a single management group can support. Depending on the hardware used and the monitoring load (more management packs deployed means a higher load) on the management group, multiple management groups might be needed to maintain acceptable performance.

Refer to the scope defined in Step 1 to determine whether multiple data warehouse management groups will be required. Record this information in Table A-6 in Appendix A.

Task 3: Align the Service Manager Management Groups to the Data Warehouse Management Groups

This task should be completed only if it was decided in Task 2 that data warehouse management groups were required.

Determine which Service Manager management groups will have their historical information extracted to each data warehouse management group, and record this configuration in Table A-6 in Appendix A. As indicated previously, a maximum of five Service Manager management groups can have data archived to a given data warehouse management group.

Step Summary

In this step, the number of Service Manager management groups and data warehouse management groups was determined, and the Service Manager management groups were aligned to the data warehouse management groups.

The information collected in this step was recorded in Tables A-6 and A-7 in Appendix A. The output of this step will in turn drive decisions relative to the design of the Service Manager management server infrastructure and the design of the Data Warehouse management server infrastructure.

Step 3: Design the Service Manager Management Server Infrastructure

In the previous step, the design of the management groups was completed, and the information collected in the step was recorded in Tables A-6 and A-7 in Appendix A. This step focuses on the design of the Service Manager management server infrastructure. It discusses placement of the Service Manager management servers, database, Service Manager Portal, and analyst console for optimal network connections. In addition, the constraints of the software are applied to determine the number of Service Manager Portals and Service Manager management servers required for scaling and capacity planning.

Fault-tolerance options for the Service Manager management server, the Service Manager database, and the Service Manager Portal are evaluated in this step, and a table is provided that describes the impact of a service failure on each component. The data warehouse database and service will be described in Step 4.

The tasks to be performed in this step are:

  1. Determine the placement of each component.
  2. Determine the number of servers required for scaling.
  3. Apply the fault-tolerance requirements.
  4. Determine the hardware configuration.

If it was decided in Step 2, Task 1, that there will be multiple management groups, then this step must be repeated for each management group.

Task 1: Determine the Placement of Each Component

In this task, the placement of the Service Manager management servers, database, Service Manager Portals, and analyst consoles will be decided. According to the product group, the Service Manager management servers and databases should be well connected via local area network (LAN) or very high-speed wide area network (WAN) with 50 milliseconds or less round-trip latency between them. Although the database can reside on the same computer as the management server, the most common reason for deploying the database on a separate server from the management server is performance gain from role specialization. In addition, deploying them separately isolates them for potentially easier recovery from disaster-type scenarios because they have different fault-tolerance options. (Specifically, the database can be clustered, but the management server cannot. This will be discussed further in Task 3.)

There are specific interaction concerns with Service Manager and Operations Manager:

  • The Service Manager management server role cannot coexist on the same server as an Operations Manager management server role.
  • Operations Manager 2007 R2 supports agent-based monitoring. System Center 2012 - Operations Manager supports agentless monitoring only.
  • On the Service Manager Portal server running SharePoint Server 2010, Operations Manager 2007 agents and System Center 2012 - Operations Manager agents are supported, if the 2012 agent is installed before Service Manager.

Other items to consider:

  • The Service Manager management server cannot coexist on the same computer with the data warehouse management server.
  • The Service Manager Portal servers can be in a different domain but will need to communicate with the Service Manager management servers and database.
  • The Service Manager Portal servers should be well connected via LAN or very high-speed WAN.
  • Users can access a portal across WAN connections.
  • The product group does not recommend installing the Service Manager Portal on a computer hosting a Service Manager management server in a production environment, because the Service Manager Portal cannot be uninstalled without uninstalling the Service Manager management server. If it is decided to host both roles together, the Service Manager management server must be deployed before the Service Manager Portal is deployed.
  • Installing the Service Manager Portal on a computer hosting the data warehouse management server is not supported.
  • The Service Manager Portal can be installed with the databases.
  • The SharePoint website and the Web Content Server elements of the Service Manager Portal can be located on the same computer or on separate computers, depending on scaling requirements.
  • Analyst consoles should have 150 milliseconds or less round-trip latency when communicating with the Service Manager management servers. If the latency is longer than this, a Remote Desktop Services server can be implemented on the LAN with the management servers to allow the analysts to work with adequate console performance. If it is determined that Remote Desktop Services is required, consult the Infrastructure Planning and Design Guide for Windows Server 2008 R2 Remote Desktop Services at http://go.microsoft.com/fwlink/?LinkId=177881 to design that infrastructure.

Record the placement of the Service Manager management servers, database, Service Manager Portal servers, and analyst console in Table A-8 in Appendix A.

Task 2: Determine the Number of Servers Required for Scaling

In this task, the constraints of the software are applied to determine the number of Service Manager management servers and Service Manager Portal servers required for scaling.

Service Manager Management Servers

In this section, the number of Service Manager management servers for each management group will be determined. There is only one Service Manager database in each Service Manager management group, but there can be multiple Service Manager management servers that connect to that Service Manager database. Multiple Service Manager management servers may be required for:

  • Scaling of console connections. The product group recommends adding additional management servers for each 80–100 concurrently connected analyst consoles. Refer to the data gathered in Step 1 to determine how many analysts are expected to connect simultaneously. See "Supported Configurations for System Center 2012 - Service Manager" at http://technet.microsoft.com/en-us/library/hh519636.aspx for more information.
  • Dedicating a management server to running workflows. The initial management server installed in each management group runs all workflows and hosts the connectors for the entire management group. By default, the same server also provides support for client connections, such as the management console. To remove part of the load from the management server running workflows, add one or more management servers for client connections, and redirect the consoles to connect to the other servers so the initial management server will be focused toward running workflows.
  • Warm standby for quicker recovery of a workflow management server. The management server that runs the workflows is a single point of failure (this will be described further in Task 3). An additional management server (including one added above for load balancing console connections) can act as a warm standby for the workflow management server. Manual administrator intervention will be required to transition the standby server to be the main management server, but it will be quicker than building a new server from scratch. See "How to Promote a Service Manager Management Server" at http://technet.microsoft.com/en-us/library/hh524221.aspx for more information.

Begin with one Service Manager management server, add one or more management servers if needed for the reasons listed above, and record the number of servers required in Table A-8 in Appendix A. Indicate which server will be running the workflows for the management group and whether it will be dedicated to this function or accepting client connections from analyst consoles or the Service Manager Portal, as well.

Service Manager Portal

If it was determined in Step 1, Task 1, that the Service Manager Portal will be implemented, this section determines the number of Service Manager Portal servers required. Service Manager Portal servers are tied to a specific Service Manager management group.

The Service Manager Portal consists of two elements:

  • A SharePoint website, accompanied by a set of applications built with Silverlight. Valid versions of SharePoint that can be used include:
    • Microsoft SharePoint Foundation 2010
    • Microsoft SharePoint Server 2010
    • Microsoft SharePoint 2010 for Internet Sites Enterprise

Note   Software requirements for SharePoint Web Parts for the Service Manager Portal are based on SharePoint Server 2010 specifications. For more information, see Hardware and Software Requirements (SharePoint Server 2010) at http://technet.microsoft.com/en-us/library/cc262485.aspx.

  • An Internet Information Services (IIS) Web Content Server, which is a web application that forms the interface between the Silverlight application and the Service Manager management server.

The home page for the Service Manager Portal is on the SharePoint website server.

The SharePoint website and the Web Content Server can be collocated on the same computer or on separate computers. Additional computers may be added for scaling purposes.

The product group recommends that Secure Sockets Layer (SSL) is used for the Service Manager Portal installation. Use the same HTTP protocol (HTTP or HTTPS) for both the Web Content Server and for the SharePoint website.

The Service Manager Portal is designed for easy access to incident and service request filing. It is not designed to handle thousands of users simultaneously. Refer to the data gathered in Step 1 to determine how many simultaneous connections to the portal are expected, and then determine the number of portal servers required.

Note   If multiple computers are used to run the Service Manager Portal, these connections should be included in the management server load considerations.

If it is expected that the Service Manager Portal will have significant use, scale-out options follow this progression:

  1. Specify that both the SharePoint website and Web Content Server elements are collocated on a dedicated server.
  2. Specify that the SharePoint website and Web Content Server elements are located on separate, dedicated servers.
  3. Specify that the SharePoint website and Web Content Server elements are located on multiple, dedicated servers in a load-balanced configuration, if required for scaling. This also provides for fault tolerance.

Record the number of Service Manager Portal servers required to meet scaling needs for each management group in Table A-8 in Appendix A.

Task 3: Apply the Fault-Tolerance Requirements

Careful consideration should be given to the fault-tolerance approach for each workload. The business should understand the risk involved of possible data loss or interruption of business, depending on the fault-tolerance approach chosen for the workloads involved.

Fault-tolerance requirements should be considered for all services that have an impact on user-facing or business-essential scenarios. Fault-tolerance options for the Service Manager management server, the Service Manager database, and the Service Manager Portal will be evaluated in this section. Table 2 describes the impact of a service failure for each component.

Table 2. Impact of Service Failures

Service failure

Description of interruption

Service Manager management server

Workflows and connectors not running.

Analysts and administrators unable to use the console.

Service Manager database

Workflows and connectors not running.

Analysts and users unable to access the Service Manager Portal.

Analysts and administrators unable to use the console.

Service Manager Portal

Users unable to access the Service Manager Portal or web parts.

Connectors

Information not imported from connected system.

Figure 4 illustrates a possible implementation of the Service Manager infrastructure in a fault-tolerant configuration (except for the Service Manager management server running workflows, which cannot be made fault tolerant).

Figure 4. Example Service Manager fault tolerance

Refer to the requirements for availability that were determined in Step 1, Task 1, and apply those requirements to determine the fault-tolerance configuration of each Service Manager component based on the considerations described next.

Service Manager Management Servers

The Service Manager management server is not cluster-aware. This section addresses the fault-tolerance options for two types of management servers: the server running the workflows and additional management servers.

  • Server running the workflows. The workflow management server is a single point of failure. There are no fault-tolerance options, such as clustering or load-balancing, that are workflow-aware. Thus, if this server fails, the workflows and connectors will fail to run. If this server fails, manual administrator intervention will be required to restore it to service. See "How to Promote a Service Manager Management Server" at http://technet.microsoft.com/en-us/library/ff521370.aspx for more information.
  • Additional management servers. For console connections, additional servers may be deployed in a hardware or software load-balanced configuration to provide fault tolerance. Each management server must be configured to communicate with the same Service Manager database. The Service Manager clients should communicate with the Service Manager management servers via the load-balanced IP or host name and not the actual hosts in order to automatically adjust if one of the nodes in the load-balanced management servers fails.

    In addition, refer to the decision made in Task 2 in this step about whether a separate management server will be used to run the workflows. If this was the case, ensure that this server is omitted from the load-balanced configuration.

Determine whether to load balance the additional management servers for fault tolerance of the analyst and portal connections, and record the answer in Table A-9 in Appendix A.

Service Manager Database

Clustering, log shipping, and mirroring are the supported SQL Server fault-tolerance options in Service Manager. However, the management servers must be installed on separate servers if SQL Server clustering is used, because the Service Manager management service is incompatible with clustering (not only is it not cluster-aware, but the management service will not function if installed in the SQL Server cluster).

For off-site redundancy, log shipping is the method that the product group currently supports. Refer to the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=163302 for more information on SQL Server fault-tolerance options.

Determine whether one of the SQL Server fault-tolerance options will be implemented, and record the answer in Table A-9 in Appendix A.

Service Manager Portal

Multiple Service Manager Portal servers can be deployed in a hardware or software load-balancing configuration to provide fault tolerance. Note that the Service Manager Portal should not be collocated on the same computer as the management server. The Service Manager Portal is not cluster-aware.

If it was decided in Task 2 to implement the Service Manager Portal in a load-balanced configuration for scale out, then fault tolerance is also provided by this configuration as long as an adequate number of servers are deployed to accommodate the users in case of actual failure of a node in the load-balanced farm.

Consult the Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5 at http://go.microsoft.com/fwlink/?LinkId=157703 to design the IIS Web Content Servers and the Infrastructure Planning and Design Guide for Microsoft SharePoint Server 2010 at http://go.microsoft.com/fwlink/?LinkId=211609.

Record whether load balancing will be implemented in a hardware or software load-balancing configuration in Table A-9 in Appendix A.

Task 4: Determine the Hardware Configuration

In this task, the hardware configuration for the Service Manager components are determined. Service Manager supports a variety of deployment topologies. Each of the main Service Manager components can be installed either separately or in some combination, as described below.

The section, "Supported Configurations for System Center 2012 - Service Manager," in the Planning Guide for System Center 2012 - Service Manager at http://technet.microsoft.com/en-us/library/hh519636.aspx provides example capacity planning data that can be used as an initial reference point. In addition, a Service Manager Sizing Helper tool is included in the Service Manager job aids documentation set at http://go.microsoft.com/fwlink/?LinkId=186291. However, organizations are expected to configure their own test environments to more accurately estimate capacity and performance.

The Service Manager components can be run in a virtualized environment or in a physical server environment. If a virtual machine will be used, ensure that it has access to CPU and memory resources equivalent to those specified for a physical machine. If it was determined that a server will host multiple Service Manager components, it should be sized to support the sum of the peak workloads.

Service Manager Management Servers

The minimum product group–recommended hardware requirements for the Service Manager management server are:

  • Dual quad-core 2.66 gigahertz (GHz) CPU
  • 8 gigabytes (GB) of RAM for up to 20,000 users
  • 16 GB of RAM for up to 50,000 users
  • 10 GB of available disk space

However, these specifications may need to be modified based on the organization's expected usage. Each processor core of the server hosting the Service Manager management server can support 10–12 consoles.

Although processor performance on this server is critical, it is especially sensitive to memory capacity because of the memory-intensive operations it is required to perform. Factors that influence the load on the management server include the number of console or other Data Access Service client applications connecting and the workflow operations.

Record the configuration of the Service Manager management servers in Table A-10 in Appendix A.

Service Manager Databases

The database can be co-located on a Service Manager management server for small environments if there are no conflicts between the fault-tolerance configurations selected. It can share a server or participate in a cluster with the data warehouse databases. In addition to separating the database from the management server for performance reasons, another possible driver for placing the Service Manager database on a separate server is if the organization's policies dictate that a separate team manage the database infrastructure.

The minimum product group–recommended hardware requirements for the Service Manager database server are:

  • Dual quad-core 2.66-GHz CPU
  • 8 GB of RAM for 20,000 users
  • 32 GB of RAM for 50,000 users
  • 80 GB of available disk space

However, these specifications may need to be increased based on the organization's expected usage. In addition, these requirements assume that the database will run on a remote server running SQL Server; thus, the specifications may need to be increased if the database is co-located with the management server.

Performance of the Service Manager database is directly affected by such factors as the number of concurrent Service Manager consoles reading or writing data, the group change check interval, and data inserted by connectors. To scale out, the product group recommends adding RAM while keeping the number of processors the same.

To help assess the size of the database and thus determine the disk storage capacity requirements, refer to the Service Manager Sizing Helper tool included in the Service Manager job aids documentation set at http://go.microsoft.com/fwlink/?LinkId=186291. This was designed for Service Manager 2010 but gives an approximate starting point for System Center 2012 - Service Manager as well in lieu of newer guidance. Create the database with a size close to the final size; doing so helps performance by reducing the number of times the database has to auto-grow.

The product group has performed baseline testing and found that 8 GB of RAM resulted in acceptable performance on a database server that contained records for 20,000 computers. Afterward, 8 GB of RAM should be added for each increment of 10,000 computers that will be supported. For example, for 50,000 computers, plan for 32 GB of RAM. While testing the 50,000-computer configuration with 32 GB of RAM installed on the machine running SQL Server, performance was improved to a state where there was no longer any decreased effect, compared to before additional computers were added. Refer to the number of computers expected to be supported by this management group, and determine the amount of RAM necessary.

If the server hosting the databases is virtualized, the product group provides these recommendations:

  • Do not use a dynamic virtual hard disk (VHD), because doing so can decrease performance.
  • Allocate at least two virtual CPUs for the instance of SQL Server.
  • Do not allocate more virtual CPUs than the number of available logical CPUs.
  • If a drop in Service Manager performance in a virtual environment is observed, check CPU and memory utilization on the virtual machines that are hosting the instance of SQL Server and the Service Manager management server. If CPU utilization is near 100 percent, either allocate additional virtual CPUs or reduce the number of concurrent Service Manager console sessions.
  • The amount of memory in the logical computer and the amount of memory allocated to each virtual machine are critical. If an instance of SQL Server, Service Manager management server, and Service Manager console are deployed to the same virtual machine, the memory requirements are cumulative. In this environment, 8 GB of memory is the minimum recommended amount.
  • If the Service Manager and data warehouse databases are installed on virtual machines, use one virtual machine for the Service Manager database and another virtual machine for the data warehouse databases.

Consult the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=163302 for more information relative to designing an infrastructure for SQL Server instances.

Record the configuration of the Service Manager database servers in Table A-10 in Appendix A.

Service Manager Portal Servers

Software requirements for SharePoint Web Parts for the Service Manager Portal are based on Microsoft SharePoint Server 2010 specifications. For more information, see Hardware and software requirements (SharePoint Server 2010) at http://go.microsoft.com/fwlink/p/?LinkID=219606.

Performance testing by the product group for the Service Manager Portal was focused on typical "Monday morning" scenarios. Specifically, that means ensuring that on Monday morning hundreds of users can log on within the span of 5–10 minutes and open incidents with acceptable (less than 4–5 seconds) response times. This goal was achieved with the following minimum hardware:

  • Dual quad-core 2.66-GHz CPU
  • 8 GB of RAM for 20,000 users
  • 16 GB of RAM for 50,000 users
  • 10 GB of available disk space

The product group strongly recommends deploying the Service Manager Portal on a stand-alone server, separate from other Service Manager components. For scaling purposes, the SharePoint website and Web Content Server elements of the portal can be installed on separate dedicated servers. In addition, multiple servers can be deployed in a load-balanced configuration to provide automatic failover in the event of a catastrophic server failure.

It is possible but not recommended by the product group to install the Service Manager Portal on the same server as the Service Manager management server for nonproduction environments. If the Service Manager Portal is installed on a computer hosting a Service Manager management server, the Service Manager Portal cannot be uninstalled without uninstalling the Service Manager management server, as well.

Installing the Service Manager Portal on a computer hosting the data warehouse management server is not supported. Consult the Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5 at http://go.microsoft.com/fwlink/?LinkId=157703, and the Infrastructure Planning and Guide for Microsoft SharePoint Server 2010 at http://go.microsoft.com/fwlink/?LinkId=211609, or the respective product documentation for other versions of SharePoint to design the Service Manager Portal servers.

Record the configuration of the Service Manager Portal servers in Table A-10 in Appendix A.

Step Summary

In this step, the placement of the Service Manager management servers, database, Service Manager Portals, and analyst consoles was decided. Also, the number of Service Manager management servers for each management group was determined. If it was determined in Step 1, Task 1, that the Service Manager Portal will be implemented, the number of Service Manager Portal servers required was determined. In addition, the fault-tolerance requirements were applied. Finally, the hardware configuration for the Service Manager components was determined. The data gathered in this step was recorded in Tables A-8, A-9, and A-10 in Appendix A.

Table 3 provides a summary of some of the key infrastructure details about the Service Manager management group components.

Table 3. Service Manager Management Group Component Data

Component

Description

Management server

Minimum number required: 1 per Service Manager management group.

Maximum number possible: No limits.

Fault-tolerance option: Load balancing available for console connections. (The management server running workflows cannot be made fault tolerant.)

Dependent on: Service Manager database.

Can coexist with: Service Manager Portal, Service Manager database, data warehouse databases.

Cannot be combined with the data warehouse management server.

Service Manager database

Minimum number required: 1 per Service Manager management group.

Maximum number possible: 1 per management group.

Fault-tolerance options: SQL Server clustering, log shipping, and mirroring.

Dependent on: Service Manager management server.

Can coexist with: Any other role.

Service Manager management group

Minimum number required: 1 per organization.

Maximum number possible: 5 per data warehouse management group.

Service Manager Portal

Minimum number required: None.

Maximum number possible: No limits.

Fault-tolerance option: Load balancing.

Dependent on: Service Manager management server and Service Manager database.

Can coexist with: Service Manager database, data warehouse databases.

Not recommended to install on the Service Manager management server in production environments.

Not supported to install on the data warehouse management server.

SharePoint website element can be installed on dedicated server if required for scaling.

Web Content Server element can be installed on dedicated server if required for scaling.

Additional Considerations

The items listed below are generally outside the scope of an infrastructure design. However, they are included here as additional considerations that the architect may need to take into account:

  • Network Requirements. In Service Manager, external content can be viewed within knowledge articles. To view external content, computers that host the Service Manager console must have Internet access, either directly or through a proxy server.
  • SMTP servers. Service Manager requires access to a Simple Mail Transfer Protocol (SMTP) server to use the notification feature and for incident creation through email.
  • Disaster recovery planning. After Service Manager is implemented, the architect should prepare for recovering from a disaster by backing up the encryption keys and developing a plan for recovering the management servers and database. For more information about Service Manager disaster recovery, see the Disaster Recovery Guide for System Center 2012 - Service Manager at http://technet.microsoft.com/en-us/library/hh495602.aspx.

Additional Reading

  • Infrastructure Planning and Design Guide for Windows Server 2008 R2 Remote Desktop Services: http://go.microsoft.com/fwlink/?LinkID=177881
  • Supported Configurations for System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh519636.aspx
  • How to Promote a Service Manager Management Server: http://technet.microsoft.com/en-us/library/hh524221.aspx
  • Planning for Performance and Scalability in System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh495684.aspx
  • SQL Server Requirements for System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh495585.aspx
  • Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2: http://go.microsoft.com/fwlink/?LinkId=163302
  • Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5: http://go.microsoft.com/fwlink/?LinkId=157703
  • Disaster Recovery Guide for System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh495602.aspx
  • Service Manager Sizing Helper tool: http://go.microsoft.com/fwlink/?LinkId=186291

Step 4: Design the Data Warehouse Management Server Infrastructure

In the previous step, the Service Manager management server infrastructure was designed. In this step, the placement of the data warehouse management servers, databases, and reporting services will be decided. In addition, the fault-tolerance requirements will be applied and the hardware configuration will be determined.

The decisions made in the previous step were recorded in Tables A-8, A-9, and A-10 in Appendix A.

This step presents an overview of the data warehouse planning. Consult the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=163302 for more information on designing an infrastructure for SQL Server. The fault tolerance and scaling for databases, SQL Server Reporting Services (SSRS), and SQL Server Analysis Services (SSAS) is provided by the underlying fault tolerance available in SQL Server and IIS.

The tasks to be performed in this step are:

  1. Determine the placement of each component.
  2. Apply the fault-tolerance requirements for the SQL Server databases.
  3. Determine the hardware configuration.

The data warehouse infrastructure provides long-term data storage for reporting purposes. The data is stored in a way that is optimized for reporting performance. The reporting infrastructure leverages Microsoft SQL Server Reporting Services, but the reports are accessible directly from within the Service Manager console. In addition, Service Manager requires SSAS to work with Microsoft online analytical processing (OLAP) cubes. The Service Manager data warehouse infrastructure consists of three data warehouse databases, the data warehouse management server, and SQL Server Reporting Services. The data warehouse databases are:

  • DWStagingAndConfig. This database:
    • Stores all of the management packs and other configuration information.
    • Stores the configuration for the Extract, Transform, and Load workflow process.
    • Initially stores the source data coming from the Service Manager database, which is later transformed into the other databases.
  • DWRepository. This database stores the source data from the Service Manager database after the data has been transformed into an optimized structure for reporting.
  • DWDataMart. This database stores the published data that is consumed by the reports.
  • DWASDataBase. This database is used by SSAS and stores OLAP cubes.
  • OMDWDataMart. This database collects data from Operations Manager.
  • CMDWDataMart. This database collects data from Configuration Manager.

The first two databases, DWStagingAndConfig and DWRepository, must reside on the same instance of SQL Server. The DWDataMart database can reside on a separate instance of SQL Server.

Like the Service Manager management server, the data warehouse management server is used to connect to the console, manage configuration data, and run workflow processes. Workflow processes run on the data warehouse management server to synchronize the management packs, including the reports, to the data warehouse. These processes also copy information from the Service Manager database on a customer-defined schedule and transform that data for storage in the data warehouse database. Finally, these processes groom expired information from the data warehouse database, where the expiration is defined by the customer or at the default of one year for the Service Manager database and three years for the data warehouse database.

Task 1: Determine the Placement of Each Component

In this task, the placement of the data warehouse management servers, databases, and reporting services will be decided. Because the Extract, Transform, and Load workflow processes are moving potentially large amounts of data across the network, the product group recommends placing the data warehouse management server and database in a location with LAN or high-speed WAN connectivity with 50 milliseconds or less round-trip latency to the Service Manager management server and database. Locating them separately from each other with higher latency may affect performance, so if the organization chooses to do this, testing will need to be completed to ensure that performance is adequate for the organization's expectations.

The data warehouse management server cannot coexist on the same computer with the Service Manager management server. In addition, installing the Service Manager Portal on a computer hosting the data warehouse management server is not supported.

The data warehouse databases can reside on the same computer as the data warehouse management server or with the Service Manager management server. However, given that they have different fault-tolerance options, deploying them separately isolates them for potentially easier recovery from disaster-type scenarios. (Specifically, the database can be clustered, but the management server cannot. This will be discussed further in Task 3.)

The data warehouse databases could share a server or cluster with the Service Manager database. Doing so would reduce the number of SQL Server licenses required, but if the data warehouse is large, the product group advises separate servers. If the databases are hosted on the same server or cluster, ensure that adequate resources are allocated for the combined load.

SSRS and SSAS can be installed on the computer that hosts the data warehouse databases or on separate servers, and any valid configuration of SSRS and SSAS will support Service Manager reporting. For optimum performance, especially in a large environment where the number of CIs increases, the product group recommends that the data warehouse databases be installed on a server other than the Service Manager reporting server.

Record the placement of the data warehouse management servers, databases, reporting services, and analysis services in Table A-11 in Appendix A.

Task 2: Apply the Fault-Tolerance Requirements for the SQL Server Databases

Fault-tolerance options for the data warehouse management servers, databases, and reporting services are evaluated in this section. Table 4 describes the impact of a service failure of each component.

Table 4. Areas Affected by Service Failure

Service failure

Description of affected area/user

Data warehouse database

Users are unable to run reports.

Data will not be updated in the data warehouse.

Data warehouse management server

Users are unable to run reports from the data warehouse databases through the console.

Data will not be updated in the data warehouse.

Refer to the requirements for availability and performance that were determined in Step 1, Task 1. Use those requirements to determine the fault-tolerance configuration of the data warehouse management components, and record it in Table A-12 in Appendix A.

The data warehouse databases' fault-tolerance options are virtually identical to the Service Manager database. Clustering, log shipping, and mirroring are the only supported SQL Server fault-tolerance options for the data warehouse databases and reporting services; however, the management server must be installed on separate servers if SQL Server clustering is used, because the data warehouse management service is not cluster-aware.

For off-site redundancy, log shipping is the method that the product group currently supports. Refer to the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=163302 for more information on SQL Server fault-tolerance options.

Task 3: Determine the Hardware Configuration

In this task, the hardware configuration for the data warehouse management server infrastructure is determined.

The Service Manager components can be run in a virtualized environment or in a physical server environment. If a virtual machine will be used, ensure that it has access to CPU and memory resources equivalent to those specified for a physical machine. If it was determined that a server will host multiple Service Manager components, it should be sized to support the sum of the peak workloads.

Data Warehouse Management Servers

The data warehouse management server has no fault-tolerance options, such as clustering or load balancing. With that in mind, the organization may want to design the server hardware with extra redundancy at the component level to help protect against those types of failures creating an outage.

The minimum product group–recommended hardware requirements for the data warehouse management server are:

  • Dual quad-core 2.66-GHz CPU
  • 8 GB of RAM for 20,000 users
  • 16 GB of RAM for 50,000 users
  • 10 GB of available disk space

However, these specifications may need to be modified based on the organization's expected usage. Performance of the data warehouse management server is directly affected by various factors, including the:

  • Number of Service Manager management servers registered to the data warehouse management server.
  • The amount of information extracted from the Service Manager databases.
  • The length of time that data is retained in the data warehouse database.

If it was determined in Step 2 that more than one Service Manager management group will be connected to this data warehouse management group, configure the data warehouse management server with at least 8 GB of RAM. If the cost of hardware is a tradeoff, the highest priority should be memory for the computer running SQL Server. The data warehouse management server is mostly stateless, and it is unlikely to have high input/output (I/O) requirements, so it should not present a performance problem.

Record the configuration of the data warehouse management servers in Table A-10 in Appendix A.

Data Warehouse Databases

The minimum product group–recommended hardware requirements for the data warehouse database server are:

  • Dual quad-core 2.66-GHz CPU. Provide at least eight CPU cores in the computer on which the data warehouse database is installed. Additional cores will help the Extract, Transform, and Load workflow process and report performance. The minimum recommended processor configuration is to have dual quad-core CPUs running at 2.66 GHz.
  • 8 GB of RAM for 20,000 users or 32 GB of RAM for 50,000 users. Provide a minimum of 8 GB of RAM for the computer on which the data warehouse databases are installed for up to 20,000 users. Provide 32 GB of RAM for up to 50,000 users. Additional memory on the SQL Server computer that hosts the data warehouse will help performance—even more so if the DWDataMart and DWRepository databases are on the same server.
  • 400 GB of available disk space.

However, these specifications may need to be modified based on the organization's expected usage. The performance of the data warehouse databases is directly affected by various factors, including the:

  • Number of concurrent Service Manager management servers sending data.
  • Volume of data stored.
  • Data-retention period.
  • Rate of data change.
  • Frequency that the Extract, Transform, and Load workflow process runs.
  • Cube process for the analysis databases.
  • System resources of the data warehouse database server.

The amount of data stored in the data warehouse increases over time, so it is important to archive and groom unnecessary data.

Record the configuration of the data warehouse database servers in Table A-10 in Appendix A.

Step Summary

In this step, the placement of the data warehouse management servers, databases, and reporting services was decided. In addition, the fault-tolerance requirements were applied and the hardware configuration was determined. The data gathered in this step was recorded in Tables A-10, A-11, and A-12 in Appendix A.

Consult the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2 at http://go.microsoft.com/fwlink/?LinkId=163302 for more information on designing an infrastructure for SQL Server.

Table 5 provides a quick glance at the parts that make up a data warehouse management server infrastructure.

Table 5. Data Warehouse Management Server Infrastructure Components

Component

Description

Data warehouse management server

Minimum number required: 1 per data warehouse management group.

Maximum number possible: 1 per data warehouse management group.

Fault-tolerance option: Not applicable.

Dependent on: Data warehouse database.

Connections to the Service Manager management groups will require the Service Manager management server and Service Manager database.

Can coexist with: Service Manager database, data warehouse database.

Cannot be combined with a Service Manager management server or Service Manager Portal.

Data warehouse database

Minimum number required: 1 per data warehouse management group.

Maximum number possible: 1 per data warehouse management group.

Fault-tolerance option: SQL Server clustering, log shipping, and mirroring.

Dependent on: Data warehouse management server.

Can coexist with: Any other role.

Data warehouse management group

Minimum number required: 0 if not implementing data warehousing, 1 per organization if implementing data warehousing.

Maximum number possible: Unlimited, but no communication or links between management groups.

Additional Reading

  • SQL Server Reporting Services (SSRS): http://msdn.microsoft.com/en-us/sqlserver/cc511478
  • SQL Server Analysis Services (SSAS): http://technet.microsoft.com/en-us/sqlserver/cc510300
  • SQL Server Requirements for System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh495585.aspx
  • Service Manager Sizing Helper tool: http://go.microsoft.com/fwlink/?LinkId=186291
  • Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and SQL Server 2008 R2: http://go.microsoft.com/fwlink/?LinkId=163302
  • Databases Created by System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh519598.aspx

Conclusion

This guide has focused on summarizing the critical design decisions, activities, and tasks required to enable a successful design of Service Manager. It has addressed the business requirements, technical aspects, and service characteristics to complete a comprehensive review of the decision-making process. When used in conjunction with product documentation, this guide can help organizations confidently plan a Service Manager implementation.

Appendix A: Job Aids

This section provides job aid examples to record data while planning the Service Manager infrastructure.

Step 1. Use Table A-1 to record the answers asked of the business to determine the features and scope of the project.

Table A-1. Features and Scope Requirements

Requirement description

Requirement results

Which parts of the organization will participate?

 

Would a business or governance policy affect the design of the system?

 

Does the business have a need to automate the enforcement and measurement of IT controls through the IT life cycle?

 

What relationship will Service Manager have with other systems or information sources?

 

Does the business plan to implement any add-in management packs to extend the functionality of Service Manager?

 

Is historical retention of change or incident information required?

 

Does the business want to provide IT staff access to key information in a graphical format without using a console?

 

Does the business want users to be able to interact directly with Service Manager via a portal?

 

Does the business want to provide the ability for users to request software that is deployed as a software package by System Center Configuration Manager?

 

Step 1. Use Table A-2 to record the answers asked of the business to determine the impact of a service interruption.

Table A-2. Rate the Impact of a Service Interruption

Task

High or Low impact

Users accessing the Service Manager Portal

 

Analysts accessing the Service Manager console

 

Management accessing historical reports

 

Historical reports containing up-to-date data

 

Step 1. Use Table A-3 to record the answers asked of the technical decision makers to determine the scope and requirements of the project.

Table A-3. Technical Requirements—Capacity

Requirement description

Requirement results

What is the approximate number of computers that will be included?

 

What is the expected usage? Estimate the number of work items such as incidents and change requests per month for capacity planning purposes.

 

What is the approximate number of end users in each location who may access the portal?

 

What is the approximate number of analysts in each location?

 

What is the approximate number of consoles that are expected to be used concurrently?

 

Step 1. Use Table A-4 to record the answers asked of the technical decision makers to determine the import and synchronization methods in scope.

Table A-4. Technical Requirements—Connectors

Requirement description

Requirement results

Number of connectors

Will Service Manager integrate with AD DS? If so, which forests and corresponding domains are in scope?

   

Will Service Manager integrate with Operations Manager? If so, which Operations Manager connectors will be used?

   

Will Service Manager integrate with Configuration Manager? If so, which site databases?

   

Will Service Manager integrate with Virtual Machine Manager? If so, which Virtual Machine Manager instances will be integrated?

   

Will Service Manager integrate with Orchestrator? If so, which runbook activities need to be synchronized?

   

Will any other custom connectors be used to integrate Service Manager with other systems? If so, do they have any special requirements that might affect the infrastructure?

   

Step 1. Use Table A-5 to record information relative to management packs for the Service Manager implementation.

Table A-5. Technical Requirements—Management Packs

Requirement description

Requirement results

Should any additional management packs that were not identified by the business decision makers be included as a part of the solution?

 

What managed devices are to be managed by which management pack?

 

Do the management packs have their own set of requirements beyond Service Manager's requirements?

 

Step 2. Use Table A-6 to record information relative to Service Manager management group requirements.

Table A-6. Service Manager Management Group Requirements

Requirement description

Requirement results

Will multiple Service Manager management groups be required?

 

What are the populations served by each management group?

 

Which Service Manager management groups will have their historical information extracted to each data warehouse management group?

 

Step 2. Use Table A-7 to record optional components desired for the Service Manager implementation.

Table A-7. Optional Components Requirements

Optional component

Select

Generation of Service Manager reports

 

Historical storage of configuration information required

 

Any identified management packs require access to data warehouse components

 

Step 3. Use Table A-8 to record the optional component locations for the Service Manager implementation.

Table A-8. Optional Component Locations

Component

Location #1

Location #2

Service Manager management servers

   

Service Manager databases

   

Service Manager Portals

(Includes SharePoint website and Web Content Server elements)

   

Service Manager analyst consoles

   

Step 3. Use Table A-9 to record information relative to fault tolerance for the Service Manager implementation.

Table A-9. Service Manager Management Server Fault-Tolerance Requirements

Requirement description

Fault-tolerance requirement results

Load balance Service Manager management servers?

 

Load balance Service Manager databases?

Load balancing not available. Use clustering for this component.

Load balance Service Manager Portals? (Indicate whether hardware or software load balancing will be used.)

 

Step 3. Use Table A-10 to record the hardware configuration requirements for the Service Manager implementation.

Table A-10. Hardware Configuration Requirements

Component

Location #1 configuration

Location #2 configuration

Service Manager management servers

<Dual quad-core 2.66-GHz CPU

8 GB of RAM

10 GB of available disk space>

 

Service Manager databases

<Dual quad-core 2.66-GHz CPU

8 GB of RAM

80 GB of available disk space>

 

Service Manager Portals (Include designation if the SharePoint website element, the Web Content Server element or both elements are installed.)

<Dual quad-core 2.66-GHz CPU

8 GB of RAM

10 GB of available disk space>

 

Data warehouse management servers

<Dual quad-core 2.66-GHz CPU

8 GB of RAM

10 GB of available disk space>

 

Data warehouse databases

<Dual quad-core 2.66-GHz CPU

8 GB of RAM (if less than 4,000 computers, 4 GB is sufficient)

400 GB of available disk space>

 

Step 4. Use Table A-11 to record the locations of the data warehouse management components for the Service Manager implementation.

Table A-11. Data Warehouse Management Component Locations

Component

Location #1

Location #2

Data warehouse management servers

   

Data warehouse management databases

   

Service Manager reporting services

   

Step 4. Use Table A-12 to record information relative to data warehouse management component fault tolerance for the Service Manager implementation.

Table A-12. Data Warehouse Management Component Fault-Tolerance Requirements

Component

Fault-tolerance requirement results

Data warehouse management databases

 

Data warehouse management server

 

Data warehouse reporting services

 

Appendix B: Connectors

The Service Manager connectors allow integration with products from Microsoft such as Active Directory, Operations Manager, or Configuration Manager, and other vendors. Service Manager connectors allow Service Manager to collect information from the other products or to send information to the products.

For example, the Service Manager connector for Active Directory allows Service Manager to populate the Service Manager database with information from Active Directory. However, the Service Manager connector for Orchestrator allows Service Manager to populate the Service Manager tasks with runbooks from Orchestrator and then allows users to initiate the runbooks as tasks from the Service Manager console or from the Service Manager Portal.

The number and placement of connectors can affect the overall performance of the infrastructure because connectors can place some of the highest demands on the infrastructure during synchronization.

Service Manager Connector for Active Directory

The Service Manager connector for Active Directory will require that the AD DS domains that will be synchronized with Service Manager and the accounts used to perform the synchronization be specified. Each Active Directory connector connects to only one AD DS domain. A separate Active Directory connector is required for each domain that will be synchronized with Service Manager.

Service Manager Connector for Operations Manager

Each Operations Manager connector can only connect to one Operations Manager management group. A separate connector for each type of connector is required for each Operations Manager management group that will be synchronized with Service Manager.

The Operations Manager management server will need to be specified for each Operations Manager management group that will be integrated with Service Manager. If an Operations Manager CI connector is to be used, and an Operations Manager alert connector is to be used, a service account should be specified that will be used to access each Operations Manager management group. Management packs will need to be specified for each Operations Manager CI connector to scope the CIs to be synchronized. Alert routing rules need to be specified for each Operations Manager alert connector, as well as the schedule for each one.

Service Manager Connector for Configuration Manager

Each Configuration Manager connector can only connect to one Configuration Manager site database. A separate connector is required for each Configuration Manager site database that will be synchronized with Service Manager.

The Configuration Manager site database server name and corresponding database name will need to be determined for each Configuration Manager site database that will be integrated with Service Manager. A service account will need to be specified that will be used to access each Configuration Manager site database. The Configuration Manager collections will need to be specified that should be used to scope synchronization, as well as the synchronization schedule.

Service Manager Connector for Virtual Machine Manager

Each VMM connector can only connect to one VMM instance. A separate connector is required for each VMM instance that will be synchronized with Service Manager.

The VMM management server name will need be to be determined for each VMM instance that will be integrated with Service Manager. A service account will need to be specified that will be used to access the VMM management server for each VMM instance.

Service Manager Connector for Orchestrator

Each Orchestrator connector can only connect to one Orchestrator instance. A separate connector is required for each Orchestrator instance that will be synchronized with Service Manager.

The URL of the Orchestrator web service will need to be determined for each Orchestrator instance that will be integrated with Service Manager. A service account will need to be specified for each Orchestrator instance that will be used to access the VMM management server, and a folder will need to be specified that will be used for synchronization. The URL of the web console will need to be specified for each Orchestrator instance.

Connectors at a Glance

Table B-1 provides a quick glance at the Service Manager connectors.

Table B-1. Service Manager Connectors

Connector

Description

Active Directory

Minimum number required: 1 per AD DS domain to be synchronized.

Maximum number possible: 1 per AD DS domain to be synchronized.

Dependent on: Existing AD DS domain and service account for each domain.

Can coexist with: All other connectors.

Operations Manager

Minimum number required: 1 per Operations Manager management group to be synchronized.

Maximum number possible: 1 per Operations Manager management group to be synchronized.

Dependent on: Existing Operations Manager management group and service account for each management group.

Can coexist with: All other connectors.

Configuration Manager

Minimum number required: 1 per Configuration Manager site database to be synchronized.

Maximum number possible: 1 per Configuration Manager site database to be synchronized.

Dependent on: Existing Configuration Manager site database and service account for each site database.

Can coexist with: All other connectors.

Virtual Machine Manager

Minimum number required: 1 per Virtual Machine Manager instance to be synchronized.

Maximum number possible: 1 per Virtual Machine Manager instance to be synchronized.

Dependent on: Existing Virtual Machine Manager instance and service account for each instance.

Can coexist with: All other connectors.

Orchestrator

Minimum number required: 1 per Orchestration instance to be synchronized.

Maximum number possible: 1 per Orchestration instance to be synchronized.

Dependent on: Existing Orchestration instance and service account for each instance.

Can coexist with: All other connectors.

Additional Reading

  • Using Connectors to Import Data into System Center 2012 - Service Manager: http://technet.microsoft.com/en-us/library/hh524326.aspx
  • Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 Active Directory Domain Services: http://go.microsoft.com/fwlink/?LinkId=157704
  • Infrastructure Planning and Design Guide for Microsoft System Center Operations Manager 2007: http://go.microsoft.com/fwlink/?LinkId=160985
  • Infrastructure Planning and Design Guide for Microsoft System Center Configuration Manager 2007 R3 and Forefront Endpoint Protection: http://go.microsoft.com/fwlink/?LinkId=160983
  • Infrastructure Planning and Design Guide for Microsoft System Center Virtual Machine Manager 2008 R2: http://go.microsoft.com/fwlink/?LinkId=160986

Appendix C: IPD in Microsoft Operations Framework 4.0

Microsoft Operations Framework (MOF) offers integrated best practices, principles, and activities to assist an organization in achieving reliable solutions and services. MOF provides guidance to help individuals and organizations create, operate, and support technology services, while helping to ensure the investment in technology delivers expected business value at an acceptable level of risk. MOF's question-based guidance helps to determine what is needed for an organization now, as well as providing activities that will keep the organization running efficiently and effectively in the future.

Use MOF with IPD guides to ensure that people and process considerations are addressed when changes to an organization's technology services are being planned.

  • Use the Plan Phase to maintain focus on meeting business needs, consider business requirements and constraints, and align business strategy with the technology strategy. IPD helps to define an architecture that delivers the right solution as determined in the Plan Phase.
  • Use the Deliver Phase to build solutions and deploy updated technology. In this phase, IPD helps IT pros design their technology infrastructures.
  • Use the Operate Phase to plan for operations, service monitoring and control, as well as troubleshooting. The appropriate infrastructure, built with the help of IPD guides, can increase the efficiency and effectiveness of operating activities.
  • Use the Manage Layer to work effectively and efficiently to make decisions that are in compliance with management objectives. The full value of sound architectural practices embodied in IPD will help deliver value to the top levels of a business.

Figure C-1. The architecture of Microsoft Operations Framework (MOF) 4.0

Appendix D: System Center 2012 - Service Manager in Microsoft Infrastructure Optimization

The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a continuum of organizational maturity. (For more information, see http://go.microsoft.com/fwlink/?LinkId=229236.) The model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in creating the Infrastructure Optimization Model was to develop a simple way to use a maturity framework that is flexible and can easily be applied as the benchmark for technical capability and business value.

IO is structured around three information technology models: Core Infrastructure Optimization, Application Platform Optimization, and Business Productivity Infrastructure Optimization. According to the Core Infrastructure Optimization Model, having near real-time policy enforcement based on company and industry-standard polices that allow for immediate quarantine of non-compliant systems, and consistent compliance reporting and standards exist across all data center services, and a configuration management database such as that provided by Microsoft System Center 2012 - Service Manager, will help move an organization to the Rationalized level. To move to the Dynamic level, organizations can use Service Manager to enable real-time policy enforcement with automated non-compliance resolution for all data center services and remediation.

Figure D-1. Mapping of System Center 2012 - Service Manager technology into the Core Infrastructure Optimization Model