Understanding System Center Orchestrator 2012

Most systems administrators have the same enthusiasm for scripting that my nine-year-old son has for a tetanus injection. Sure, IT pros love the idea of automating as many processes as possible. But when they're actually sitting in front of the Windows PowerShell ISE and must write something that takes more than a few lines of code, the excitement wanes and they quickly find something that they're more passionate about -- like reading every entry in the event logs.

This is unfortunate, because if there's one inevitable progression in the systems administration profession, it's that as time goes by, smaller numbers of IT pros are required to manage and monitor larger numbers of systems. IT pros who aren't good at automating complex systems administration tasks are going to be less competitive in the job market than IT pros who embrace automation technologies. The ability to rapidly automate common tasks is becoming crucial.

Microsoft System Center 2012 Orchestrator simplifies the process of automating systems administration tasks. Originally a third-party product named Opalis, which Microsoft acquired in 2009, Orchestrator provides a simplified way of building complex automation. Rather than writing several lines of PowerShell code to determine whether a specific alert has popped up in the Windows event log, you use Orchestrator's canvas, on which you can drop an item that relates to event monitoring, configure that item to flag a specific alert, and then connect the item to another item that takes a specific action in relation to that work. Instead of several lines of what sometimes seems to be arcane PowerShell code, you can accomplish the same tasks by using a drag-and-drop process that might take you all of 30 seconds.

Orchestrator is a complete solution that goes beyond basic automation. You can configure Orchestrator runbooks to be triggered according to event logs or, more usefully, Microsoft Systems Center Operations Manager alerts. Rather than waiting for an end user to notice that a service has become unavailable or having a member of the support team raise a job according to an Ops Manager alert, you can automate the process entirely through the use of an Orchestrator runbook that is triggered by an alert, raises a job in the job-tracking system, runs a complex operation to resolve the issue that triggered the alert, adds information to the job in the job-tracking system, and then closes that job. The alert is resolved, the job is logged and closed, and everything is completed without direct human intervention.

Although not all the alerts that Ops Manager raises can be resolved through automation, many items have a specific process that, when followed, resolves the issue. It you can come up with a procedure to resolve a specific known problem, then you can come up with a way to automate that resolution.

To better understand Orchestrator, you need to understand these concepts:

Activities

Orchestrator uses a GUI-based approach to creating automations. The items that you work with when you create these automations are known as activities. You use the runbook designer to drag and arrange activities, linking them together in a logical order, letting them branch by using decision logic. The two basic types of activities are monitoring activities and action activities:

A runbook is a collection of activities that are joined together in a logical manner. The runbook that Figure 1 shows uses System Center Data Protection Manager (DPM) to add all protectable data sources on a specified server, including volumes, system state data, and databases, to a DPM protection group. After these data sources have been added to the group, the runbook triggers the creation of a recovery point.

In the sample runbook, the only inputs that you need to specify are the target server and the target protection group. Runbooks can be executed from the Orchestration console, a Microsoft Silverlight-based web application that runs on the Orchestrator Runbook server. Although this task is relatively simple, manually configuring this type of DPM protection would involve using Remote Desktop Connection to connect to a specific DPM server, running the DPM console (which cannot be run remotely in DPM 2010), and then stepping through a wizard to configure protection. But after you have the runbook configured, you can accomplish the same task simply by entering the server name and the data protection group name into a single web dialog box. A task that would take an IT pro 5 minutes or more to complete manually can now be completed automatically, in the time it takes to load the Orchestration console.

Data Bus

The data bus holds all the execution data from all the objects within the runbook and allows you to pass information from one activity to another. For example, your first activity might be to monitor an Ops Manager alert that is based on the failure of a particular service. The information about which service has failed is put on the bus so that later tasks, such as checking the service status and then triggering a service restart, can use that information. Later in this article, you'll learn how to use the data bus to take output from a command-line utility and append it to the end of a text file.

Integration Packs

Integration packs are collections of activities that relate to a specific product. For example, in Orchestrator 2012, the integration packs for all of the other System Center 2012 products will be released. Because Orchestrator was originally a third-party product, a substantial number of integration packs are available for non-Microsoft products, such as CA Technologies Service Desk; HP Operations for UNIX, Windows, and Solaris; HP Service Desk; IBM Tivoli Enterprise Console; and VMware Infrastructure and vSphere.

Note that you don't need an integration pack to use Orchestrator with a particular product. If no integration pack is available from the vendor, you can use an Orchestrator foundation object to perform activities, including

All these items can be used to connect generically to a system. What you can accomplish from that point depends on what's available in the product that you're attempting to automate. Orchestrator ships with a tool known as the Quick Integration Kit (QIK). The QIK is an SDK that allows you to create your own activities and integration packs, using a product's own command-line utilities or PowerShell cmdlets. The QIK is increasingly being used to generate community-based integration packs.

Orchestration Console

The Orchestration console allows you to view the real-time status of runbooks, as well as to start or stop runbooks. You can use the Orchestration console as a way of allowing other IT pros to execute runbooks. For example, you can create a runbook that uses the DPM integration pack to create a backup snapshot of a particular data source. You can then make this runbook available through the Orchestration console, as Figure 2 shows. Users, such as developers who are working on a database, can use the console to trigger a backup snapshot before they make a change to the database.

The Orchestration console component is also used by SCSM 2012 as a way of triggering runbooks. SCSM allows you to create a more feature-complete self-service portal in which users can submit requests that trigger Orchestrator runbooks either directly or after the runbooks have been approved through an appropriate approval process.

System Requirements

All Orchestrator components can run on Windows Server 2008 R2. Orchestrator requires 1GB of RAM (although 2GB is recommended), 200MB of disk space, and a dual-core CPU or better. Like the other System Center 2012 products, Orchestrator can be run within a VM. The Runbook Designer and Runbook Tester can also be run on Windows 7 Enterprise or Ultimate Edition.

Orchestrator requires access to a SQL Server 2008 R2 database to store configuration data. You'll also need to install Microsoft .NET Framework 4 and Silverlight 4 for the Orchestration console.

Creating a Basic Runbook

Throughout this article, you've learned about how you can use Orchestrator to automate even the simplest tasks. To further elaborate, let's look at how you'd use Orchestrator to do something simple, such as outputting a list of tasks that are running on a computer to a text file named tasks.txt. The idea behind this basic runbook is to give you an idea of the actual process and simplicity that are involved in automating this task. Follow these steps:

To execute the task, click Runbook Tester, and then click Run. Open the tasks.txt file to verify that the task list information has been appended to that file.

Orchestrator: The Glue in the System Center Suite

In your day-to-day role as a systems administrator, you are most likely to find Orchestrator immediately useful for integrating all the components of the System Center suite. Although you can resolve basic alerts by using Ops Manager's existing functionality, you can configure Orchestrator runbooks as a more sophisticated way of resolving Ops Manager alerts.

You've learned that you can use Orchestrator to build a runbook that is triggered by an Ops Manager alert. But you can go further. For example, you can have the runbook use SCSM to log a job on the job-tracking system; automatically resolve the issue that triggered the alert by running a job in DPM, VMM, or SCCM; have the runbook perform a test to verify that the issue that triggered the original alert has been resolved; and then have the runbook update and close the job in SCSM. Figure 4 shows a runbook that automatically remediates service-related problems, logging steps as necessary within SCSM.

You can go much further with Orchestrator and use it to improve your organization's internal processes. For example, by leveraging the DPM integration pack, you can have SCSM trigger an automatic backup snapshot when an IT pro begins to implement a change request. Similarly, you can use integration between SCSM, SCCM, and Orchestrator to simplify the provisioning of new user desktops. Just set things up so that the requirements for the new desktops are placed into the system through an SCSM web form, with Orchestrator operationalizing those requirements into the appropriate OS and application deployment tasks in SCCM. Orchestrator excels at taking information from one part of the System Center suite and allowing you to act on that information in another part.

A Simpler Automation Method

Now that Orchestrator is a fully fledged Microsoft product, expect to see increasing numbers of Orchestrator integration kits that let you simply automate common tasks in products such as Microsoft Exchange Server and SQL Server. Orchestrator is important to IT pros because it provides a simpler way of automating common systems administration tasks that need to be performed against Microsoft and third-party products. The key to your future as a systems administration is ensuring that you can manage and maintain an increasing number of systems. Products that let you automate simply and efficiently can help you achieve that goal. The more straightforward the tasks that you can automate, the more time that you can spend on problem-solving and troubleshooting complex issues that don't easily lend themselves to automation.