Share via

System Center 2012 Integration Guide - Orchestrator

  • 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

System Center 2012 Orchestrator provides a workflow management solution for the data center. It lets you automate the creation, monitoring, and deployment of resources in your environment.

The following diagram shows the different technologies for integrating with System Center 2012 – Orchestrator 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 Programmability

3.1 Orchestrator Web Service

The Orchestrator web service is a REST based service that exposes Orchestrator 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# or scripting languages such as Windows PowerShell to automate Orchestrator functionality.

Using the Orchestrator web service is the only supported method of automating Orchestrator functionality or accessing its data.  The Orchestration Console is an example of an application based on the Orchestrator web service.

3.2 Windows PowerShell

Orchestrator has no Windows PowerShell cmdlets for automating administrative tasks.  Instead, you can use Windows PowerShell to access the Orchestrator web service through HTTP calls.  A library of Orchestrator functions using the Orchestrator web service is available on CodePlex at System Center Orchestrator Web Service PowerShell.  While the functions in this library are not officially supported by Microsoft, they can be used in the same manner as a cmdlets.  The only additional requirement is to load the library into your script.

3.3 References

4 Runbooks and Integration Packs

4.1 Runbooks

Runbooks contain the instructions for an automated task or process.  The primary function of Orchestrator is to load and run runbooks. The individual steps that make up a runbook are called activities. Within the runbook, additional controls provide information and instructions to control the sequence of activities in the runbook. Runbooks, activities, and each runbook control have configurable properties. You modify these properties to configure the behavior that your runbook requires.

Runbooks are created with the Runbook Designer which is a completely graphical tool.  Most users can begin creating runbooks with relatively little training.  The true value in the runbook comes from knowing which activities to use and how to configure them to perform the required functionality.  For the standard activities that install with Orchestrator, you can consult the Runbook Activity Reference for System Center 2012 - Orchestrator.  For other activities, you need to consult the documentation for the particular Integration Pack.

4.2 Integration Packs

Orchestrator runbooks are made up of activities that perform different functions.  The standard install of Orchestrator includes a set of activities for performing a variety of basic functions.  For a runbook to perform additional functionality and access other systems and applications, you need an Integration Pack.  An Integration Pack is a collection of activities that interact with a specific application or system.  Since a runbook can include activities from multiple Integration Packs, it provides integration between any system with an Integration Pack, without those systems having any knowledge of each other.

If an application has no Integration Pack available then you can use the Run .NET Script activity to run custom code that accesses the system.  This could be a script in Windows PowerShell or Jscript, or it could be managed code in C# or VB.NET. 

4.3 Orchestrator Integration Toolkit

If you have an application or system that you want to be controlled with a runbook, then you should create an Integration Pack to provide users with activities to work with your system.  You can create an Integration Pack using one or more tools in the Orchestrator Integration Toolkit.  Each of these tools and their function is summarized below.

4.3.1 Orchestrator SDK

The Orchestrator SDK is used to create activities using a language such as C#.  You will typically use the SDK of the system that you are accessing in order to provide required functionality for the activity.  The Orchestrator SDK allows you to put this code in the context of an activity for use in a runbook.

4.3.2 Command Line Activity Wizard

The Command Line Activity Wizard enables you to quickly create activities without writing code.  You can provide command line actions, PowerShell scripts, or SSH commands, and the wizard will automatically create the appropriate C# source code.  This tool is useful for users who do not want to take on the complexity of writing their own code, but it is more limited in its ability to create a complex activity.

4.3.3 Integration Pack Wizard

The Integration Pack Wizard allows you to create a new integration pack from assemblies that you created either with the Orchestrator SDK or the Command Line Activity Wizard. This is the tool that actually creates the .OIP file that you distribute to the user to install in their Orchestrator environment.

4.3.4 References

5 System Center Integration

5.1 Virtual Machine Manager

The System Center Integration Pack for System Center 2012 Virtual Machine Manager includes activities that allow you to create a workflow in Orchestrator that interacts with VMM.  You can perform many of the functions that you can perform with PowerShell cmdlets only within the context of an Orchestrator runbook.

The activities in the VMM Integration Pack connect from the runbook server to a computer with the VMM console installed using PowerShell Remoting.  The VMM console and cmdlets do not need to be installed on the runbook server since the activities are able to use the cmdlets installed on the VMM console computer.

The VMM Integration Pack allows you to create one or more connections to VMM servers that can be used by its activities.  Each connection holds the security configuration required to access a particular VMM server.  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 VMM action from a runbook that doesn’t have an activity, then you write a script can using one or more of the VMM PowerShell cmdlets and then run this script from a Run .NET Script activity.  In this case, the VMM cmdlets would need to be installed on the runbook server.  The script would also need to include a connection to the VMM server using the Get-VMMServer cmdlets.  If the account used for the Orchestrator Runbook Service does not have authority to the VMM environment, then alternate credentials would need to be provided to 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.

5.1.1 References

5.2 Service Manager

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 Operations Manager Integration Pack address the following scenarios:

  • Create, retrieve, and update changes and incidents.
  • Create, retrieve, and update objects and relationships.
  • Retrieve and update an activity.
  • Monitor for the creation or update of an object.

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 Operations Manager management group using the New-SCSMManagementGroupConnection cmdlet.  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.

5.2.1 References

5.3  Operations Manager

5.3.1 Integration Pack

The System Center Integration Pack for System Center 2012 Operations Manager includes activities that allow you to create a runbook in Orchestrator that interacts with Operations 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 Operations Manager Integration Pack address the following scenarios:

  • Retrieve and modify alerts.  This includes the ability to monitor for an alert to be created or changed, a feature which directly supports the connector scenario with other management systems.
  • Get the current health state of one or more monitored objects.
  • Start and stop maintenance mode.

The Operations Manager Integration Pack allows you to create one or more connections to Operations 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 an Operations Manager action from a runbook that doesn’t have an activity, then you can write a script using one or more of the Operations Manager cmdlets and then run this script from a Run .NET Script activity.  In this case, the Operations Manager cmdlets would need to be installed on the runbook server.  The script would also need to include a connection to the Operations Manager management group using the New-SCOMManagementGroupConnection cmdlet.  If the account used for the Orchestrator Runbook Service does not have authority to the Operations 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 Operations Manager Integration Pack connect to Operations Manager using the Operations Manager SDK which means that they connect to the Data Access service on a management server.

5.3.2 Management Pack

In System Center 2012, the management pack for Orchestrator discovers and measures the health of Orchestrator components such as management servers and runbook 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 runbook server fails, but it will not alert if a runbook fails. 

The recommended strategy to raise an alert in Operations Manager if a runbook fails is to include one or more Create Alert activities that raise an alert if a previous activity does not succeed.  You can also use a third party management pack that provides additional functionality such as the System Center Orchestrator MP from Infront Consulting Group.

5.3.3 References

6 Other Resources