Share via

System Center 2012 Integration Guide - Service Management Automation

  • Article

 

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.
 

1 Product Overview

Service Management Automation is an IT process automation solution for Windows Azure Pack for Windows Server 2012 R2. It enables you to automate the creation, monitoring, and deployment of resources in your Windows Azure Pack environment.

The following diagram shows the different technologies for integrating with System Center 2012 R2 – Service Management Automation from other software, hardware, and System Center components.  Each of these technologies is discussed in the following sections.

1.1 Product Documentation

2 Role in the Microsoft Private Cloud

The following table briefly introduces the capabilities that Orchestrator 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.

 Layer  Description
Service Delivery Layer The primary function of Orchestrator within the Services Delivery Layer is to encode the individual tasks to compose the end-to end management of common service level activities.  Runbooks call capabilities in Virtual Machine Manager to automate the provisioning of virtualized resources.
Infrastructure Layer Orchestrator is used to automate processes in VMM to compose resources that build out the infrastructure layer components.
Service Operations Layer The Service Operations Layer includes all the routine administrative tasks performed on the private cloud infrastructure.  Orchestrator supports this layer by automating these tasks through runbooks.
Management Layer Orchestrator provides the engine for orchestrating end-to-end operations that are required for management of the cloud components.

3 SMA and Orchestrator

System Center 2012 Orchestrator and Service Management Automation perform the same function and have a similar architecture.  There are distinct differences between the two though that you should consider when determining which to use for a particular solution.

  • SMA is only available with Windows Azure Pack for Windows Server 2012 R2.  Orchestrator is available with System Center 2012, System Center 2012 SP1, and System Center 2012 R2.  
  • SMA runbooks are based on Windows PowerShell workflows and can leverage existing Windows PowerShell cmdlets that interact with other applications and services.  Orchestrator runbooks rely on Integration Packs created specifically for Orchestrator to interact with other applications and services.
  • SMA runbooks can be authored and managed in the Windows Azure Pack management portal.  Orchestrator runbooks are authored using Runbook Designer and managed using the Orchestration Console.  
  • Orchestrator includes a graphical user interface with Runbook Designer that allows you to create a sophisticated runbook with minimal specialized knowledge.  SMA does not have such an interface at this time, and relies on Windows PowerShell scripting knowledge to create a runbook.

There is currently no automated process for converting Orchestrator runbooks to SMA runbooks.  If you have a legacy Orchestrator installation, you can control Orchestrator runbooks from SMA runbooks during a migration period as described in Orchestrator below.  

4 Programmability

4.1 SMA Web Service

The SMA web service is a REST based service that exposes SMA resources and relationships through Open Data Protocol (OData).  OData is a web protocol for querying and updating data using standard syntax.  You can access the web service using programming languages such as C# to automate SMA functionality.  The Service Management Portal and the SMA Windows PowerShell cmdlets access the SMA web service in order to interact with SMA.

There is currently no documentation available for the SMA Web Service.  Because it adheres to the OData standard though, you can retrieve information from it through standard web requests.  An introduction to using OData queries is available at OData Queries Using the Orchestrator Web Service.  This includes information and samples accessing  the Orchestrator Web Service which is not identical to the SMA web service but close enough to provide useful guidance.

4.1.1 References

4.2 Windows PowerShell

SMA has a set of Windows PowerShell cmdlets for automating administrative tasks including starting runbooks and stopping jobs, importing runbook changes, and managing SMA servers.  These cmdlets connect to SMA through the SMA web service and require it to be installed and running.  They are installed with the SMA web service or as a separate install.

4.2.1 References

4.3 SDK

SMA does not have an SDK that is used for external applications that require access to its data and functionality. If you have an application that requires access to SMA, then you should use the SMA cmdlets or directly access the SMA web service.  Both of these methods expose all functionality and data held by SMA. In addition to the cmdlets being available for command line and script operations, they can also be called from applications written in languages such as C# and C++. In order to use PowerShell cmdlets from managed code, you use the PowerShell class which is part of the System.Management.Automation Namespace.

5 Runbooks and Integration Modules

5.1 Runbooks

Runbooks in SMA are based on Windows PowerShell Workflows and contain the commands for an automated task or process.  The primary function of SMA is to load and run runbooks. Runbooks can either be created with the editor in the Windows Azure Pack management portal or with any Windows PowerShell editor and then imported into SMA. 

5.1.1 References

5.2 Integration Modules

SMA runbooks rely on cmdlets to access different services and devices.  An Integration Module is a package that contains a Windows PowerShell Module and can be imported into SMA.  Imported modules are distributed to all SMA worker servers so that they are available to runbooks.  All existing Windows PowerShell modules can be used with runbooks, although some may need to be manually installed on worker servers.

5.2.1 References

6 System Center Integration

6.1 Virtual Machine Manager

Virtual Machine Manager includes a Portable module that is installed on SMA worker servers.  For runbooks to properly use VMM cmdlets though, they must be manually installed on each worker server.  If you do have the cmdlets installed, then your runbook can use the Get-SCVMMServer cmdlet to retrieve a VMM server connection for use with other cmdlets.  Those cmdlets will run on the worker server and connect to the specified VMM server.  You should create a connection of type VirtualMachineManager to hold the server and credentials to use with Get-SCVMMServer.

If you don’t have the VMM cmdlets installed on each worker server, then you should use an InlineScript in your runbook to run the VMM cmdlets on the VMM server where they will be installed.  You should create a connection of type VirtualMachineManager to hold the server and credentials to use with the script block.

See Virtual Machine Manager Windows PowerShell Cmdlets  for more information on what functions you can perform in runbooks using Operations Manager cmdlets.

6.1.1 References

6.2 Service Manager

There is no Service Manager module installed on SMA worker servers.  For runbooks to properly use Service Manager cmdlets, they must be manually installed on each worker server.  If you do have the cmdlets installed, then your runbook can use the New-SCSMManagementGroupConnection cmdlet to connect to the management group.  There is no connection type for Service Manager, but you can use the OperationsManager type to hold the server and credentials to use with this cmdlet.

If you don’t have the Service Manager cmdlets installed on each worker server, then you should use an InlineScript in your runbook to run the cmdlets on the Service Manager server where they will be installed.  You can use a connection of type OperationsManager to hold the server and credentials to use with the script block.

6.2.1 References

6.3 Operations Manager

6.3.1 Integration Module

Operations Manager includes a Portable module that is installed on SMA worker servers.  For runbooks to properly use Operations Manager cmdlets though, they must be manually installed on each worker server.  If you do have the cmdlets installed, then your runbook can use the New-SCOMManagementGroupConnection cmdlet to connect to the management group.  You should create a connection of type OperationsManager to hold the server and credentials to use with this cmdlet.

If you don’t have the Operations Manager cmdlets installed on each worker server, then you should use an InlineScript in your runbook to run the Operations Manager cmdlets on the management server where they will be installed.  You should create a connection of type OperationsManager to hold the server and credentials to use with the script block.

See Operations Manager Windows PowerShell Cmdlets for more information on what functions you can perform in runbooks using Operations Manager cmdlets.

6.3.2 Management Pack

In System Center 2012, the management pack for SMA discovers and measures the health of SMA components such as worker servers and web servers.  It does not discover runbooks, nor does it monitor at the runbook level.  For example, the management pack will send an alert if the runbook service on a worker server fails, but it will not alert if a runbook fails. 

6.3.3 References

6.4 Data Protection Manager

Data Protection Manager includes a Portable module that is installed on SMA worker servers.  For runbooks to properly use DPM cmdlets though, they must be manually installed on each worker server.  If you do have the cmdlets installed, then your runbook can use the Connect-DPMServer cmdlet to connect to a DPM server for use with other cmdlets.  Those cmdlets will run on the worker server and connect to the specified DPM server.  You should create a connection of type DataProtectionManager to hold the server and credentials to use with Connect-DPMServer.

If you don’t have the DPM cmdlets installed on each worker server, then you should use an InlineScript in your runbook to run the DPM cmdlets on the DPM server where they will be installed.  You should create a connection of type DataProtectionManager to hold the server and credentials to use with the script block.

6.4.1 References

6.5 Orchestrator

While Orchestrator and SMA perform similar functions, you may have both installed in a single environment. In this case, you may need an SMA runbook to manage Orchestrator and its runbooks.

SMA has an Integration Module called OrchestratorService that has a set of activities for working with Orchestrator. This includes the ability start a runbook, get a job, or inspect any of the collections exposed by the Orchestrator Web Service. This is not a Portable module so it can be run on all worker servers without any additional installation requirements. Your runbook should include a call to Get-OrchestratorServiceUrl to retrieve the URL of the Orchestrator web service. You should create a connectionof type OrchestratorService to hold the server and credentials to use with this activity. Subsequent commands can then use this address.

The OrchestratorService module is an implementation of System Center Orchestrator Web Service PowerShell Module. You can get information on this module at Accessing System Center 2012 Orchestrator Using the Web Service and Starting Runbooks and Stopping Jobs Using the System Center 2012 Orchestrator Web Service. General information and samples on using the Orchestrator web service from a Windows PowerShell script is available at System Center 2012 - Orchestrator Web Service.

6.5.1 References

7 Other Resources