.png?width=100&auto=webp&quality=80&disable=upscale "Picture of John Savill")
.png?width=400&auto=webp&quality=80&disable=upscale "John Savill")
Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Getting Started with System Center 2012 Orchestrator
Automate complex tasks via runbooks
John Savill
April 29, 2013
13 Min Read
No conversation about Microsoft System Center 2012 would be complete without mention of the Orchestrator component, which ties other components together or integrates them with some external system. System Center 2012 Orchestrator is the new name for the product formally known as Opalis, which Microsoft acquired in late 2009.
In short, Orchestrator is an IT process-automation toolbox. It allows connectivity to practically any IT system in an organization and then performs actions (known as activities) on those systems. Various activities are linked together to define a complete process, which is known as a runbook.
Related Articles:
"What’s New with System Center 2012 Service Manager SP1"
"Understanding Microsoft System Center 2012 Licensing"
"Understanding System Center 2012 Configuration Manager"
Consider a manually intensive task that you currently perform—one that involves the use of multiple consoles to manage multiple systems. With Orchestrator, you can create a single runbook with activities that perform actions on all those systems; by doing so, you can automate the entire task. It gets even better when you consider that the runbooks can be called from an Orchestrator web portal; from components such as System Center 2012 Service Manager, as part of its central Service Catalog; and even from other products or command-line interfaces (CLIs), via Windows PowerShell and API mechanisms. This flexibility makes Orchestrator's capabilities readily available from other environments.
Orchestrator Architecture
Orchestrator has a simple architecture. In addition to several tools to manage the environment, Orchestrator consists of three primary components:
Management server—The management server component provides a communication link between the Orchestrator database and runbook servers. The management server also deploys runbooks and integration packs to runbook servers. Only one management server can be deployed per Orchestrator deployment. If the management server is unavailable, then the tools to deploy and control runbooks (e.g., Runbook Designer) will not function. Use virtualization to make the management server resilient to server failure.
Runbook server—The runbook server runs the runbooks that are deployed to it. Runbook servers communicate directly with the Orchestrator data store to determine whether a runbook needs to be run. The management server does not need to be available for runbooks to be actioned. Having multiple runbook servers is common in a highly available deployment. Each runbook server can run 50 runbooks concurrently. If more than 50 runbooks are required, then multiple runbook servers will definitely be needed.
Data store—Orchestrator uses Microsoft SQL Server for its data store, which contains all deployed runbooks, configuration, log files, and system status. In a highly available configuration, the data store should be part of a clustered SQL Server deployment.
In a lab environment, the management and runbook servers can be installed on the same OS instance, such as a single virtual machine (VM). In production environments, these servers are typically split over multiple OS instances. In terms of requirements, Orchestrator has the same requirements as the rest of the System Center 2012 SP1 components:
Unlike the other System Center 2012 components, Orchestrator is still a 32-bit application. This isn't a problem because 64-bit OSs can run 32-bit applications. However, in some instances when calling 64-bit components, you need to do a bit of "magic" to make everything work. The good news is that because Orchestrator is 32-bit, its tools can be run on both 32-bit and 64-bit client OSs.
The core Orchestrator installation is only about 100MB. Compared with the rest of System Center, Orchestrator is tiny and has low memory and processor requirements. However, those requirements depend on the complexity of the runbooks that are executed on the runbook servers.
Orchestrator Tools
Several tools are used with Orchestrator to create runbooks, configure servers, and monitor the environment. These tools can be deployed to Windows 7, Windows 8, Windows Server 2008 R2, or Windows Server 2012. I'm going to introduce the tools as we use them to actually create and use our first runbook. I'm assuming that all the Orchestrator components and tools have been installed on a single server and that you're logged on to that server so that they are readily available.
Creating a Runbook
I previously discussed activities, which perform actions on the systems for which Orchestrator is automating processes. Out of the box, Orchestrator has several built-in activities, which fall into these categories:
System
Scheduling
Monitoring
File Management
Email
Notification
Utilities
Text File Management
Runbook Control
Using only the built-in activities in these categories, you can create powerful runbooks. For example, within the System category is a Run .Net Script activity that enables PowerShell to be called, and almost anything can be accomplished with PowerShell. But the goal of Orchestrator is to make creating runbooks—and therefore automating processes—as simple and intuitive as possible. So instead of constantly creating PowerShell scripts, you'll want to take advantage of Orchestrator integration packs.
An integration pack is a collection of activities that have some commonality: They all relate to a certain product or enable a certain capability. For example, integration packs are available for each System Center 2012 component, Windows Azure, VMware, Microsoft Exchange, Active Directory (AD), HP Service Manager, and so on. Several free integration packs are available from Microsoft. Others have been created by the Orchestrator community, and certain vendors supply integration packs for their solutions so that those solutions can be used in runbooks. Some companies, such as Kelverion, sell these integration packs as well as having free ones available.
After you download an integration pack, the next step is to register it with Orchestrator. You then deploy the integration pack to Runbook Designer instances (so that the integration pack can be used as part of runbooks) and to runbook servers. The Deployment Manager tool is used to perform this function.
Launch Deployment Manager. The tool splits into three sections, showing the integration packs that are available to the Orchestrator deployment, the deployed Runbook Designer instances, and the deployed runbook servers, as Figure 1 shows.
Figure 1: Deployment Manager
This makes Deployment Manager not just a useful tool for deploying integration packs but also for deploying Runbook Designer instances and new Runbook servers. The tool is also a single point via which the entire Orchestrator deployment status can be viewed.
For now, we already have Runbook Designer and a runbook server on the local server. We'll use Deployment Manager to load a new integration pack and deploy it to Runbook Designer and a runbook server instance. In this example, we've downloaded and will deploy the Activities for Active Directory integration pack.
Right-click the Integration Packs navigation node and select Register IP with the Orchestrator Management Server.
Click Next on the Welcome page.
Click Add in the integration pack selection wizard, select the OIP file, and click Open. (If you were loading more than one pack, you'd repeat these actions for each one.) Click Next.
Click Finish.
The integration pack is now imported into the Orchestrator deployment and registered with the management server. The next step is to deploy the integration pack to Runbook Designer and the runbook server.
Select the integration pack from the list displayed in the Integration Packs node, and choose the Deploy IP to Runbook Server or Runbook Designer action, as Figure 2 shows.
Figure 2: Deploying Integration Packs
Click Next on the integration pack deployment wizard introduction page.
Choose the integration pack that you want to deploy, then click Next. (You can choose more than one pack when you're deploying more than one.)
Select the machines to which to deploy the integration pack (or packs); these can be Runbook Designer systems or runbook servers. Click Next.
Choose whether to perform the deployment immediately, or schedule the deployment for a set time. Click Next.
Review the list of actions that will be performed, then click Finish.
The integration pack is now available for inclusion in runbooks and for use on runbook servers. As you navigate through Deployment Manager, note that if you right-click the Runbook Designers or Runbook Servers navigation node, the option to deploy a new instance is available. This option makes it easy to expand your Orchestrator deployment. The whole process can be seen in the accompanying video.
Now it's time to use Runbook Designer to create and test runbooks. Launch Runbook Designer. Note the navigation on the left side, which shows the runbooks that exist, as well as the options to create computer groups and deploy runbooks to runbook servers. The right side of the tool shows all the integration packs and built-in activities that are available. The majority of the tool comprises the canvas on which you drag activities to create runbooks.
The first step is to create a new folder for your runbooks. We'll then create a new runbook within that folder.
Right-click the Runbooks navigation node and choose New, Folder.
Enter a name (e.g., ITPRO), then press Enter.
Right-click the new folder and choose New, Runbook.
A New Runbook tab is created. Right-click this tab, choose Rename, and give the tab a meaningful name (e.g., NewUser). To complete the renaming process, the runbook needs to be checked out. This checkout is automatically performed for you.
In this example, we're creating a runbook that we'll use to create user accounts. To do this, we'll use the Active Directory integration pack.
Some integration packs use configurations that need to be created before the activities can be used. For the Active Directory pack, you must create a configuration for the AD instance with which you want to interact. This requires the name of a domain controller (DC), a credential, and the default container in which objects will be created.
Under the Options menu in Runbook Designer, you'll see all the integration packs that require created configurations. Choose Active Directory.
Click the Add button.
Fill in the available fields. The parent container needs to be in distinguished name (DN) format. For example, the default Users container for my savilltech.net domain would be CN=Users,DC=Savilltech,DC=Net. When all the fields are completed, click OK.
You can now create the runbook.
The runbook should already be checked out from the renaming process. If it isn't, choose the Check Out action on the main menu bar.
In the Activities area, select Runbook Control, then drag the Initialize Data activity onto the canvas, on the far left. We'll use this activity to define the variables that will be used throughout the runbook.
Double-click the Initialize Data activity on your canvas; Details is selected.
Click Add to create new parameters, then click the placeholder name of each created parameter and give it a unique name. In our example, we want to add three parameters; name them CommonName, FirstName, and Surname, then click OK. These values are required when running the runbook and will be placed on the Orchestrator data bus, which is available to all the activities in the runbook and is a great way to pass data.
The next step is to add an activity to create a new user.
In the Activities list, select Active Directory, then drag the Create User activity onto the canvas, to the right of the Initialize Data activity.
Hover over the canvas, just to the right of the Initialize Data activity. A small arrow will appear. Click and hold the arrow, then drag it over the Create User activity. Doing so creates a link between the two activities.
Double-click the Create User activity, then click the button to the right of the configuration name and select the configuration that you created for the Active Directory integration pack.
Under Properties, the CommonName parameter is shown. Right-click the blank space next to the CommonName value. We will use the value from the Initialize Data activity by subscribing to its data on the Orchestrator data bus.
From the context menu, choose Subscribe, Published Data. The Initialize Data activity is selected by default. Choose the CommonName value that's shown and click OK.
In this example, we also want to set the first name and surname of the new user. Click the Optional Properties button, choose Last Name and First Name, and click the right-arrow button to add to the properties to be used.
Use the Subscribe action again for each value, to select the corresponding value from the Initialize Data activity in the same way you did for CommonName in step 5. Click Finish.
These actions create a disabled user. To enable the user, we need to add the Enable User activity. Drag the Enable User activity from the Active Directory integration pack onto the canvas, to the right of the Create User activity. Create a link from the Create User activity to the Enable User activity, as described in step 2. If you right-click the link, you'll see the default Include option, which means that the link is used if the Create User activity returns success. You could link other activities that can be used if Create User fails.
Double-click the Enable User activity and choose the AD configuration. Right-click anywhere in the value space and select Subscribe, Published Data. For Activity, choose Create User, then choose the Distinguished Name value (which is populated automatically as part of user creation).
Click Finish. The finished runbook should look like the one that Figure 3 shows.
Figure 3: Creating a User Runbook
The created runbook can now be used. To test the new runbook, click the Runbook Tester button, which opens the Runbook Tester utility. Click the Run button. You'll be prompted for the values that are required as part of the Initialize Data activity. After you complete these values, the runbook will run and you can see the status of each activity in it.
In this example, I used only activities from the Runbook Control and Active Directory integration packs. The real power comes from using activities from many integration packs, allowing the automation of processes that require the use of many systems. Various levels of logging can be enabled to help track runbook usage and troubleshoot possible problems. This entire process is shown in the accompanying video.
Now that the runbook has been created, it's available by default for runbook servers to utilize. The new runbook is also available in the Properties of each runbook server. You can specify runbook servers that will be used to execute the runbook. Although runbooks can be executed through many different means, Orchestrator includes various web options, such as a complete Microsoft Silverlight web-based console, which by default is available on port 82 of your management server. (The console can also be launched from Runbook Designer, via the Orchestration Console button.) The console allows full tracking or initiation of runbooks, as shown in Figure 4.
Figure 4: Silverlight Web-Based Console
Start Small, Gain Big
The best way to get started with Orchestrator is to start small. Think of a process that involves some manual effort, and create a runbook to automate that task. You might even want to convert a PowerShell script into an Orchestrator runbook. When you start to use Orchestrator, you'll quickly learn how easy it is to automate what could otherwise be a very complex process. When you have runbooks, integrate them into other components, such as Service Manager, to make them easily available. (I touched on this topic in the article "What's New with System Center 2012 Service Manager SP1.")
One final tidbit: Download the Best Practices Analyzer and use it in your environment. This tool can quickly point out any possible problems and help your environment run as efficiently as possible.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
