Microsoft System Center Orchestrator 2012: Lead the System Center Band

Automating IT processes saves time and effort, and you can do it fairly easily with System Center 2012 Orchestrator.

Paul Schnackenburg

The biggest challenge with IT process automation isn’t the technology­—it’s the interface with the business and business processes. That challenge is also fundamental to other business and IT initiatives. There’s no doubt that automating tasks is one of the key elements to realizing the benefits of both private and public clouds. This is the primary challenge facing IT professionals in the shift to cloud computing.

System Center 2012 Orchestrator is a Runbook Automation (RBA) tool, also known as an IT Process Automation (ITPA) tool. It’s arguably the most important part of the System Center 2012 suite. While the larger products in the suite such as System Center Operations Manager and System Center Configuration Manager handle the day-to-day IT management tasks, Orchestrator is the glue that transforms the separate applications of the suite to a unified toolset.

Orchestrator is a powerful tool for automating repetitive processes and tasks, as well as communicating with disparate systems and platforms. Orchestrator is the new version of Opalis Integration Server that Microsoft acquired in December 2009.

Learning to use and understand the concepts of Orchestrator could mean the difference between being invaluable or replaceable to the business. Fortunately, becoming comfortable with Orchestrator and creating basic workflows is relatively easy, and Microsoft provides good training materials.

To reap the full range of benefits of Orchestrator, you have to sit down with the full IT department, as well as with other parts of the business. In order to automate, you must first determine which processes to automate. Time-consuming current practices, common IT problems and issues that affect service levels significantly are good contenders for automation.

As a practical example, a user could initiate an Orchestrator runbook by requesting a service in a self-service portal. The runbook would then await approval by IT. Once approved, it would then automatically provision the necessary virtual machines through System Center Virtual Machine Manager, deploy the required software via Configuration Manager, arrange backup through System Center Data Protection Manager and integrate monitoring with a third-party system.

Orchestrator Components

There are several components to Orchestrator. The Runbook Server executes the runbooks, or workflows. This will generally sit in your datacenter. The Orchestration Console is a Web-based interface you can use to start and track runbook execution. The Runbook Designer is where you create runbooks by linking activities. Finally, the Deployment Manager is where you register Integration Packs and deploy them to Runbook Servers.

Throughout your organization, different types of users interact with Orchestrator in different ways. IT professionals use the Runbook Designer to create workflows. IT managers use the Orchestration Console to check statistics and reports. Developers can use the Orchestrator Integration Toolkit to create custom Integration Packs with activities for the business. Your business users might interact with Orchestrator through the Web console, with a one-click runbook to perform a database cleanup job, for example.

As is always the case when Microsoft acquires a product, the company has changed the terminology. If you’re familiar with Opalis, the Operator Client is now the Runbook Designer. The Operator Console is now the Orchestration Console. Runbooks used to be known as Policies, and the Quick Integration Kit is now the Orchestrator Integration Toolkit.

Depending on the size of your environment and your reliance on Orchestrator, you might need several Runbook Servers. If a runbook fails to complete on one server due to an outage, it will restart on another available server. It’s a good idea to include logic in runbooks to check if they were previously running but didn’t complete. A Runbook Server will not execute more than 50 runbooks concurrently by default, although you can change this (see the TechNet Library article, “How to Configure Runbook Throttling”). They will queue up, but overall scalability is dependent on your particular runbooks and their performance profile.

The minimum requirements for System Center 2012 Orchestrator are 1GB of memory (but 2GB or more is recommended), a dual-core CPU and 200MB of free disk space. All components except the Runbook Designer require Windows Server 2008 R2. The Designer can also run on Windows 7. The server needs to have the Microsoft .NET Framework 3.5 SP1 installed, along with .NET Framework 4. The Orchestration Console requires that you enable IIS on the server. The client browser needs Silverlight 4 or later installed. Finally, you’ll also need a SQL Server 2008 R2 database, either local or remote.

The installation experience is easy (see Figure 1). A prerequisite checker ensures everything needed is in place before proceeding. If you’ve ever installed Opalis, you’ll be pleasantly surprised because the whole mess of downloading and installing Java and JBoss components is gone. If you’re currently using Opalis 6.3, the upgrade is simply a matter of installing a parallel environment, exporting existing runbooks and then importing them into Orchestrator. You should note that the reverse isn’t possible—you can’t bring Orchestrator runbooks into Opalis.

Figure 1 Installing Orchestrator is a straightforward affair.

Run with Runbooks

Building a runbook involves dragging activities from the right-hand panes into the workspace and linking them (see Figure 2). The activities are either Standard Activities installed with Orchestrator or part of one or more IPs you have installed.

Figure 2 The Runbook Designer is simple to use.

The links between each activity can branch out based on whether the activity outcome is listed as a success, warning or failure. Each activity can use variables and counters you’ve configured, as well as environment variables in Windows. Data from each activity is put onto a shared data bus as published data, and other activities can use this further into the workflow.

You can use regular expressions to filter output data with include and exclude options. You can also use functions and mathematical calculations with numerical values. You can loop activities with exact control over the exit condition. Check the TechNet Library for a full description of all the data manipulation functions.

The built-in activities include system process and service manipulation, Simple Network Management Protocol (SNMP), monitoring, file management, scheduling, notification through e-mail and other options, database queries, and Web service invocation. You can include Linux and other platforms in runbooks through Telnet and SSH activities. The .NET script activity can call Visual Basic .NET, C#, JScript and Windows PowerShell.

Beyond the Standard

While the standard activities are comprehensive and help you automate many common scenarios, the Integration Packs really show the power of Orchestrator. Check the TechNet Library for a full list of the Integration Packs.

There are now Integration Packs (see Figure 3) for both current and previous versions of all products in the System Center suite. The Integration Packs also cover HP Operations and Service Manager and iLO hardware, VMware vSphere and IBM Tivoli. There are also community-created Integration Packs with specific functionality on CodePlex and the Technet Gallery, including one for the VMware stack.

Figure 3 Installing Integration Packs is a three-step process: register, deploy and configure.

The Microsoft Integration Packs for the System Center 2012 products don’t contain activities for every possible action in Data Protection Manager and Virtual Machine Manager. They do cover the most-common day-to-day tasks, with a Run PowerShell activity for less-common actions. This activity is easier to use than the standard Run .NET script, as it reuses the connection configuration so you don’t have to embed authentication in your script. It’s also easier to output data to the data bus. There’s more on this on the Orchestrator team blog.

If you’re running Operations Manager 2012, you might have noticed the integration (event forwarding, incident ticket creation, monitoring ticket resolution and so on) with third-party service desks from BMC Software Inc., HP and service-now.com is no longer in the box. Nor is integration with enterprise management tools from BMC, HP and IBM Corp. That’s because it’s now offered through Orchestrator. Kelverion is a good place to start looking at Integration Packs and runbooks for this.

Executing Runbooks

Scheduling runbooks is quite flexible to suit different purposes. You can, for example, exclude some from running during business hours. You can use the Check Schedule activity within a runbook to retrieve time data. Other runbooks can wait for certain conditions or triggers, and will have a Monitor activity as the first object. These runbooks “run” continuously.

If you’re a scripting guru, but unfamiliar with Orchestrator or Opalis, you might feel you can do most of this with scripts. The strength of Orchestrator over scripting languages such as Windows PowerShell is the reach. Orchestrator “talks” to many different platforms using Integration Packs.

There’s also ease of creation. Orchestrator uses a Visio-like interface, where you visually link tasks. It provides security and delegation, controlling who can run what runbooks and who can alter them. You can also include scripts as part of Orchestrator runbooks when necessary, so it’s not an either/or situation.

Pick Your Process

Creating good runbooks and automating your IT processes starts long before you sit down in front of the Runbook Designer. You have to agree on the best way to do something and what steps are involved. It’s much easier to create efficient runbooks when you have all the pertinent information handy, such as how often a runbook is going to run, when it will run, which steps are included, what triggers the runbook to start, what data should be passed from activity to activity, the desired end result and what do to if something fails along the way.

Agree on clear naming conventions and use link colors to communicate branching logic. The most important tip is to split complex runbooks into smaller parts in a parent/child relationship. You can configure these to pass data to each other. Having smaller runbooks strung together into longer runbooks simplifies reuse, troubleshooting and maintenance.

You can use folders to control permissions for executing runbooks. You can also set rights for individual runbooks, but it’s not very manageable. Full Control lets a user execute and alter a runbook, as well as change the permissions. Write is required to change runbooks, whereas Read just lets a user execute. 

There’s also security at the Integration Pack level. You could have two different configurations for level 1 and 2 help desk staff. When a runbook is checked out, no one else can change it until it’s checked in again. You can control targeting runbooks to the right systems by computer groups in Orchestrator and base these on Active Directory queries.

When you’re ready to test your runbook, use the Runbook Tester for debugging and setting breakpoints. Don’t be misled by the “Tester” moniker, though. This isn’t a simulated environment. Your runbooks will be executing live data. You can, however, control the account in which a runbook runs in the Tester.

Monitor Runbooks

When you’re testing a runbook, you can turn on object-level logging for insight into how each activity performs. You can also see a real-time log of which runbooks are executing, as well as a historic log for recent runbooks. You can configure logging to include the Published Data values on the data bus.

Finally, you can enable (it’s disabled by default) the Audit trail text logging. This comes into play when Orchestrator interacts with external systems. Be careful if you have too many logging options enabled. This can add a lot of information to your SQL database. You can use a scheduled job to purge older log data or do it manually.

You can control how many instances of a particular runbook execute simultaneously. You can also configure a notification if a runbook takes longer than usual to finish. Keeping an eye on any automated environment is vital. There’s an Operations Manager management pack for Orchestrator that should be considered mandatory.

The Center of System Center 2012

The System Center  2012 suite is still composed of separate programs with disparate infrastructures and databases, and different agents on monitored, configured and protected nodes. Including Orchestrator and Integration Packs for the different applications helps you truly leverage the strengths of each solution to work together in a way that’s never been possible before. There’s even a pack of sample System Center 2012 runbooks available on CodePlex to get you started on your integration journey (see Figure 4).

Figure 4 This set of sample System Center 2012 runbooks is a great starting point.

There’s strong integration between the different System Center programs and Orchestrator, particularly with System Center Service Manager, which can notify and execute runbooks. To clarify any confusion about the difference between the two, understand that Orchestrator is all about IT processes, whereas Service Manager handles business processes.

Another sign that Orchestrator truly is the director of the System Center orchestra is the recently released System Center Cloud Services Process Pack. This provides add-ons for Service Manager and runbooks for Orchestrator that enable customizable private cloud provisioning.

The only brand-new feature is the Orchestrator Web service. This exposes the functionality of Orchestrator through an OData/Representational State Transfer interface. It lets you see folders; runbooks and their parameters; activities; jobs; Runbook Servers and statistics; and runbook and activity instance information.

Some great ways to start learning Orchestrator include the Jumpstart blog series by Pete Zerger. The Orchestrator team blog has also been busy since the launch with articles covering load balancing the Orchestration Console and the Web Service, communicating with Orchestrator through COM, and creating and using local variables in a runbook.

There’s no doubt that learning Orchestrator should be high on your priority list. Automation will play a huge role in datacenters of the future, and it plays a huge role in unifying the System Center suite. Mostly, though, this should be high on your list because Orchestrator gives you the power to integrate and automate processes in so many separate systems.

Paul Schnackenburg has been working in IT since the days of 286 computers. He works part time as an IT teacher as well as running his own business, Expert IT Solutions, on the Sunshine Coast of Australia. He has MCSE, MCT, MCTS and MCITP certifications and specializes in Windows Server, Hyper-V and Exchange solutions for businesses. Reach him at paul@expertitsolutions.com.au and follow his blog at TellITasITis.com.au.

Related Content

• System Center 2012: Keep an Eye on System Center 2012
• TechNet Virtual Lab: Opalis: Incorporating Advanced Logic into Your Policies
• TechNet Virtual Lab: Opalis: Building Advanced Policies