Microsoft System Center 2012 Orchestrator is the primary IT process automation component of the System Center suite. With Orchestrator, IT pros and/or infrastructure developers can create repeatable automation of repetitive or error prone IT processes in the form of Orchestrator runbooks. Orchestrator runbooks are conceptually similar to scripts in that they perform some set of operations in a repeatable manner. Where they differ is that Orchestrator runbooks can be created by IT pros without as deep of a background in scripting or programming initially, but can also include script components in more advanced scenarios. This chapter provides a brief overview of the features and capabilities offered by Orchestrator from a runbook author’s perspective.
The Runbook Designer is the heart of the runbook authoring experience in Orchestrator and along with integration packs (described shortly) the two differentiating factors from traditional scripting. The Orchestrator Runbook Designer shown in Figure 2-1 is a graphical interface for authoring runbooks. This Microsoft Visio-like interface presents a much more approachable authoring experience for both basic and advanced automation than traditional scripting does.
The Runbook Designer provides five major areas of functionality for the runbook author to utilize when designing Orchestrator solutions.
This pane presents a hierarchy of folders and runbooks enabling you to organize and apply permissions to manage access and the ability to edit. Right-clicking a runbook or folder provides a number of different options such as editing permissions or importing/exporting the runbook or folder. The import and export functionality is critical to systematic runbook design as it enables you (manually) to establish backups and version control of runbooks (described in subsequent chapters) and to move runbooks between environments (such as dev/test/production). This pane also includes the Runbook Servers tab listing all of the runbook servers in the deployed Orchestrator solution and Global Settings where variables and counters are implemented. Best practices for utilizing this hierarchy, permissions, and variables will be detailed in later chapters.
The Menu and Command bar contains a number of important elements. One is the Connections menu where you configure connections required by any imported management packs to other management systems. These connections require credentials with appropriate permissions on the target management systems. The Command bar includes buttons for checking in and checking out runbooks for edit. The check in / check out process is simply a lock on the selected runbook so that it can only be edited by the person who checked it out. This functionality does not include any version control, so once a runbook has been changed and checked in, you cannot revert to a previous version (unless you manually exported the previous version and re-import).
The runbook design surface is where the actual visual editing of runbooks is performed. The runbook folder structure is where you select a runbook to edit. Once selected, the runbook will be presented in the design surface.
The activity list contains all of the built-in activities and the activities from any deployed integration pack. You can drag activities from the list and drop them onto the design surface for use in runbooks. Double-clicking an activity on the design surface opens the activity for editing its parameters.
The logging pane includes information about the status of the selected runbook. Logging includes currently running instances of the runbook as well as a history of completed executions of the runbook. The amount of logging data retained and automatic periodic purging of the logging data (recommended for good console performance) is configured by right-clicking the Orchestrator server at the top of the runbook folder hierarchy and selecting Log Purge.
The process of designing, testing, and deploying runbooks will be covered in significant depth in subsequent chapters. In general, it consists of mapping out the process to be automated, streamlining it logically to be as efficient as possible (that is, the fewest steps possible, most loosely coupled approach, and so on) then determining what systems must be orchestrated, determining if integration packs for all systems are available, and then finally laying out the activities and process flow in the Runbook Designer.
While initially appearing simple, the Runbook Designer is quite powerful. The designer enables branching, looping, and parallelism all with conditional logic.
As mentioned, integration packs (IPs) are the primary method of extending Orchestrator. Orchestrator ships with a set of foundation objects and activities for basic tasks such as file management, email integration, and other basic activities that are non-system specific. Microsoft then provides a number of additional IPs for the System Center suite and select third-party systems such as VMware. Beyond that, there is a large and growing ecosystem of integration packs from other hardware and software makers which further extend Orchestrator.
Integration packs typically consist of a set of activities specific to the target management system. As an example, the System Center Virtual Machine Manager (VMM) integration pack includes activities such as starting and stopping virtual machines, creating a virtual machine, and so on. To use an integration pack it must be imported and deployed to all of your Orchestrator runbook servers and a connection established between Orchestrator and the target management system (VMM in this example) using a service account with adequate (typically administrator) permissions on the target management system.
The Orchestrator Runbook Tester is another key feature that assists in the runbook design process by providing the ability to test runbook functionality prior to implementation of your runbooks in a production environment. The Runbook Tester is effectively a debugger for Orchestrator runbooks. From the Runbook Designer you can navigate to the runbook you want to test and then select the Runbook Tester button. This will launch the Runbook Tester and open the current runbook in the tester. The Runbook Tester, like a script debugger, lets you set breakpoints in your runbook execution which pause the runbook at that point, enabling you to verify any expected results to that point, check the value of any variables or logs created so far, and so on. You can then resume the runbook or execute it step by step to continue to evaluate the results. This capability is important in the runbook authoring process, particularly for large or complex runbooks.
There are some limitations to the Runbook Tester such as only being able to test an individual runbook and not larger or more complex scenarios where multiple runbooks are nested or sequentially executed. It is also important to note, and we will review this later, that the Runbook Tester executes runbooks under the context of the logged-on user, not under the context of the Orchestrator service account which is used for executing runbooks in production scenarios. In many cases, a runbook may work in the tester but not in production due to differences in permissions between the service account and the runbook author in the tester.
Figure 2-2 illustrates a runbook in the tester with a breakpoint set at the second step. In the left pane, details of the selected activity are displayed. In the lower middle pane, the completed steps of the runbook are displayed.
The right pane shows the value of variables on the data bus. Each completed step in the lower middle pane can be selected and the log history details of the step can be viewed. This enables analysis of the results of those steps to verify results. Once verification is completed, the remainder of the runbook can be executed by manually stepping through each step or by letting it run to the end.
The Orchestration console is a web-based user interface for initiating and monitoring runbook execution. From this console you can see all running runbooks and their status. Figure 2-3 illustrates the console and the list of available runbooks.
The console can also be used to initiate runbooks. If the selected runbook is configured to require input parameters, the Orchestration Console prompts you to enter values for those parameters. In Figure 2-4, a runbook has been started and is prompting for a single parameter. Once the parameter is entered, the runbook will be executed.
Having discussed the concept of integration packs which extend Orchestrator to connect to other management systems and the large ecosystem of third parties creating integration packs, the question often remains: “What do I do if there is no management pack for the system I want to orchestrate?” This question may arise if neither the foundation objects included with Orchestrator nor any third-party integration packs enable the connectivity and activities you need to orchestrate another system. Examples may include a large line of business applications you’d like to orchestrate as part of some process automation. Fortunately, Orchestrator has an answer in the Orchestrator Integration Toolkit (OIT). The OIT enables you to write your own integration packs for systems or applications that don’t have an integration pack but support some form of automation such as web services application programming interfaces (APIs). Table 2-1 lists the components included in the OIT.
Table 2-1. The Components Included in the Orchestrator Integration Toolkit
Component | Description |
|---|---|
Command-Line Activity Wizard | A utility that allows users to define activities that contain commands that run via Windows command shell, PowerShell, or SSH, and package them into an assembly (.DLL) that can be used with the .NET IP or packaged into a new integration pack. |
Integration Pack Wizard | A utility designed to package Orchestrator-compatible activity assemblies and dependent files into a deployable Integration Pack file. |
Integration Toolkit .NET IP | An integration pack for running .NET-based Orchestrator-compatible activity assemblies directly. Contains the Invoke .NET and Monitor .NET activities. |
Integration Toolkit SDK Library | A set of files that are used by developers utilizing the System Center 2012 - Orchestrator SDK to write custom activities. |
This book does not cover creating custom integration packs as it is beyond the scope of the typical IT Pro usage of Orchestrator but it is important to be aware that this capability exists and as usage of Orchestrator grows in your organization, there will likely be instances where creating an integration pack for your mission-critical applications or services may be warranted and the OIT is easily utilized by developers to create them. For more information about integration pack development and for other options for building custom solutions with Orchestrator, refer to the “System Center 2012 Integration Guide,” which you can find on Microsoft TechNet at http://social.technet.microsoft.com/wiki/contents/articles/13188.system-center-2012-integration-guide.aspx.