This document is part of a collection of documents that make up the
System Center 2012 Integration Guide. The purpose of the Integration Guide is to provide an overview of each System Center component in its role as a programmable platform to be leveraged for the Microsoft Private Cloud. It is intended to provide an abstraction
layer that guides partners and customers on their decision process for methods to build automated solutions across System Center components.
This guide is a community project to analyze the different options for integration with the components of System Center 2012. Please feel free to edit this document to improve its quality.
System Center 2012 Service Manager provides an integrated platform for automating and adapting your organization’s IT service management best practices, such as those found in Microsoft Operations Framework (MOF) and Information Technology Infrastructure
Library (ITIL). It provides built-in processes for incident and problem resolution, change control, and asset lifecycle management.
The following diagram shows the different technologies for integrating with System Center 2012 – Service Manager from other software, hardware, and System Center components. Each of these technologies is discussed in the following sections.
The following table briefly introduces the capabilities that SCSM provides as part of the
Microsoft Private Cloud Reference Model. Further details are provided in
Mapping Private Cloud Capabilities to the Microsoft Private Cloud Platform.
The System Center 2012 - Service Manager SDK can be used to access all data and functionality of Service Manager.
This is the preferred integration technology to use if you have an application, such as an alternate console, that requires access to Service Manager.
The Service Manager SDK is currently labeled in TechNet as the System Center SDK.
This SDK is actually specific to Service Manager and does not work with other components of System Center.
While you can use the Service Manager SDK to create and edit elements in management packs such as classes, workflows, and views, it is typically easier to create and edit management packs using the Service Manager Authoring Console.
The SDK should only be used under scenarios where a programmatic method of working with the management packs is required.
Examples of scenarios where the Service Manager SDK might be used include the following:
Examples on creating management packs and management elements using the SDK are available in
System Center Management Pack.
Service Manager has
Windows PowerShell cmdlets available for performing most administrative functions from a command line.
The cmdlets can be separated into the distinct categories of
Administrator Cmdlets and
Data Warehouse Cmdlets.
In System Center 2012, some of the Service Manager cmdlets are shared with Operations Manager because the two components share an underlying architecture.
These shared cmdlets use a noun prefix of SC.
An alias is created using SCSM as the noun prefix in order to better align these cmdlets with those cmdlets that are specific to Service Manager.
Management Packs in Service Manager contain all of the logic and presentation elements in a management group.
This includes such elements as classes, workflows, views, forms, reports, and knowledge articles.
Data that is created in the management group such as incidents, changes requests, and instances of classes are stored in the Service Manager database and are not defined in a management pack.
Several management packs are installed by default with Service Manager while additional management packs are available in the
Management Pack Catalog.
Management packs are implemented in XML files that adhere to a particular schema.
Service Manager 2010 uses version 1.0 of the management pack schema, while Service Manager in System Center 2012 uses version 2.0.
Since the schema is backward compatible, any management pack written using the version 1.0 schema will work in both Service Manager 2010 and System Center 2012.
Management packs written with version 2.0 schema will only work in System Center 2012.
There are very few advantages to using the version 2.0 schema for most monitoring scenarios, so it is recommended that you use the version 1.0 schema for all management packs in order to ensure that users can use them in both versions of Service Manager.
The only reason to use the version 2.0 schema is if you are creating a management pack using features specific to System Center 2012.
There are two options for creating and editing Service Manager management packs in System Center 2012 as outlined in the following sections.
The Administration pane and the Library pane in the Service Manager provide access to limited customization of Service Manager features. When you customize Service Manager features in the Service Manager console, the customizations are stored in new or existing
unsealed management packs and in the Service Manager database. For more information about sealed and unsealed management packs, see
Using Management Packs in System Center 2012 – Service Manager.
When you modify a management pack with the Service Manager Console, the change is committed to the management group immediately.
The Service Manager Authoring Tool is part of the
System Center 2012 – Service Manager Component Add-ons and Extensions.
Using this tool, you can create and modify all elements of a management pack, including those that cannot be created or modified in the Service Manager console.
The Authoring Tool works with management pack files offline meaning that you do not require a connection to a management group.
You must install the management pack into the management group after it has been modified.
Service Manager integrates with VMM through a
System Center Virtual Machine Manager Connector that is created and configured in the Service Manager console.
Most of the virtualization related data is discovered by Operations Manager through the
System Center Monitoring Pack for System Center 2012 - Virtual Machine Manager and then imported into SCSM by an
Operations Manager Connector.
The function of the VMM Connector is to import library content that is not discovered by SCOM.
Further information on the specific objects that are imported by the VMM Connector are discussed in the blog entry
FAQ: What Classes of Objects Does the SCVMM–SCSM Connector Bring In?.
Operations Manager integrates with Service Manager through two types of connectors that are both created and configured in the Service Manager console.
The Configuration Items connector imports objects from Operations Manager as Configuration Items in Service Manager.
Discoveries in Operations Manager locate resources and their properties on managed computers, and the connector allows these objects to be automatically imported into Service Manager.
The Alerts connector imports alerts as they are created from Operations Manager into Service Manager.
They are created in Service manager as incidents where they can be managed.
The incident then remains in synchronization with the alert allowing it to be closed when the incident is resolved.
The System Center Monitoring Pack for System Center 2012 - Service Manager allows Operations Manager 2012 to monitor the health of a Service Manager environment.
It discovers Service Manager management servers and data warehouse and measures the health of its services.
The Operations Manager agent cannot be installed on a Service Manager management server because Service Manager uses the System Center Management service to process its own management packs. To monitor a Service Manager management server, you must
configure it to use agentless monitoring which allows Operations Manager to process its management packs on an Operations Manager management server. Once the
computer is added to the Operations Manager management group in this manner, it is monitored like any other computer. The only exception is that it will not run any rules or monitors that do not support an agentless scenario.
The System Center Integration Pack for System Center 2012 Service Manager includes activities that allow you to create a runbook in Orchestrator that interacts with Service Manager.
You can perform many of the functions that you can perform with Windows PowerShell cmdlets only within the context of an Orchestrator runbook.
The activities included in the Service Manager Integration Pack address the following scenarios:
The Service Manager Integration Pack allows you to create one or more connections to Service Manager management servers that can be used by its activities.
Each connection holds the security configuration required to access a management group.
You can create a runbook with multiple activities that share a single configuration so that you don’t have to maintain separate credentials and connections for each activity.
If you need to perform a Service Manager action from a runbook that doesn’t have an activity, then you can write a script using one or more of the
Service Manager cmdlets and then run this script from a
Run .NET Script activity.
In this case, the Service Manager cmdlets would need to be installed on the runbook server.
The script would also need to include a connection to the Service Manager management group using the
If the account used for the Orchestrator Runbook Service does not have authority to the Service Manager management group, then alternate credentials would need to be provided for this connection.
In this case, the name and password could be stored as encrypted variables in Orchestrator so that they would not have to be hardcoded into the script.
The activities in the Service Manager Integration Pack connect to Service Manager using the
Service Manager SDK which means that they connect to the Data Access service on a management server.
In System Center 2012, an Orchestrator connector allows you to automatically import Orchestrator runbooks as configuration items in Service Manager.
You can then create a
Runbook Automation Activity Template that allows you to map runbook parameters with corresponding parameters in Service Manager.
This allows the runbook to be started automatically from a service request without interacting directly with Orchestrator itself.
The primary value provided to Service Manager by Data Protection Manager is protecting its database.
All Service Manager configuration and data is stored in the Service Manager database which is hosted by SQL Server, and a core feature of DPM is protecting SQL Server databases.