System Center Orchestrator 2012 uses runbooks to automate activities and tasks—all without requiring a single line of code or script.
Microsoft calls it “the glue.” You can call it “automation for everything else.” In a world where Windows PowerShell scripts seem to get all the attention, System Center Orchestrator 2012 offers dead-simple and virtually script-free automation for the overworked Geek of all trades.
Incredulous? That’s understandable. This is a big product and yours might be a small environment, or a small piece of a larger one. How can an enterprise solution like Orchestrator make your job easier on one level, without making it harder on another?
You’ll find your answers in the collection of activities Orchestrator brings together to build its automation runbooks. Out of the box, Orchestrator activities help you create, edit and relocate files on disk; monitor system behaviors; and kick off a wide variety of customizable activities on remote systems. You can do all this without resorting to a single line of code. Even if you’re in a small environment, you’ll find this useful. If you can click-and-drag, you can automate just about anything.
Spend time with Windows PowerShell and you’ll quickly discover the power of its pipeline. The Windows PowerShell pipeline gives you object-oriented flexibility with your data. String together a list of cmdlets and you can easily gather and filter information, organize it, and subsequently act on the resulting data. The hard part with Windows PowerShell, however, can be finding the right cmdlets to achieve your goal. Sometimes the steps to assemble those cmdlets require extra effort that diminishes the experience.
Orchestrator activities and runbooks remove the commands from the Windows PowerShell command line (see Figure 1). In the example in Figure 1, there are six activities connected by links. Each activity defines an action to be accomplished on a targeted machine. Each link, represented by the connecting arrow, defines the order of operation for the activities. This runbook will verify that a computer is on the network, map a network drive, copy a file, append a line to a log file, and send an e-mail to report on the success or failure of the runbook.
Figure 1 An Orchestrator runbook defines actions and the order of those actions.
You can drag-and-drop activities directly from an Activities toolbar into the Orchestrator Runbook Designer. Then you customize properties for each activity to define what that step should accomplish (see Figure 2). The links themselves also contain properties, which are typically the set of conditions for continuing or stopping the runbook after each activity. The Append Line activity is linked to two subsequent Send Mail activities. The first has been configured to send a success e-mail, while the second is set to report that the last activity has failed.
Figure 2 Your runbook can map network path properties.
Orchestrator automations are said to be “the glue” because its activities allow for nearly unlimited runbook action customization. You can construct actions that aren’t exposed in the activities toolbar out of any command line—including Windows PowerShell itself.
Don’t fear the Windows PowerShell burden for many activities. You can extend the Orchestrator activities library with Integration Packs. Like the Management Packs used to extend the System Center Operation Manager field of monitoring vision, Orchestrator Integration Packs add new activities for accomplishing specific goals. Figure 3 presents a partial list of some of the activities added by the System Center Virtual Machine Manager (VMM) 2012 Integration Pack. As you can see, its actions focus specifically on the tasks you’ll need for managing virtual machines (VMs) in VMM.
Figure 3 This Integration Pack focuses on managing virtual machines within System Center Virtual Machine Manager 2012.
The Integration Packs aren’t merely new verbs. They’re also the point of integration between Orchestrator and the external solution with which you’re working. In the configuration editor for the VMM 2012 Integration Pack (see Figure 4), you’ll supply connection information to an available VMM server as part of registering and deploying the pack throughout your Orchestrator infrastructure.
Centralizing the integration into the pack itself greatly simplifies the steps required to construct a runbook out of activity objects. The registered pack’s objects are already configured to execute on the remote server. All you have to do is connect the activities.
Figure 4 You can edit the configuration of the System Center Virtual Machine Manager 2012 Integration Pack.
The greatest benefit of Orchestrator to even the smallest environment is arguably its centralization of all automations that keep a Windows environment running. Anyone with any scripting experience knows how scripts can be a double-edged sword for an IT environment. They’re great for automating the manual and painful tasks in Windows administration, but their activities too often get lost in the day-to-day grind of keeping servers running.
Sometimes those scripts even outlive the person responsible for creating them. When a script-friendly administrator changes jobs, there will be an automation script without an owner. That’s a problem that can wreak havoc the day that forgotten script stops working.
Orchestrator eliminates the scattered scripts problem by centralizing execution onto a single server. Scripts run on the Orchestrator server. You can manage their activities through a single, Web-based Orchestrator Console (see Figure 5). That custom automation consolidation helps ensure you won’t receive calls years later to track down a long-forgotten lost automation.
Figure 5 The Web-based Orchestrator Console helps you manage your automations.
While Orchestrator itself delivers great power, this automation toolkit gets even more useful when you integrate it with System Center Service Manager. Take another look at the new VM runbook in Figure 2. This ostensibly simple runbook includes two activities. The latter of those actions creates a new VM in VMM from a template.
This simple automation might seem unnecessary until you pair the second activity of the runbook with the first. Its first activity, Initialize Data, is a placeholder for adding incoming data at the time of execution. The properties windows for Initialize Data (see Figure 6a) and the Create VM from Template activity (see Figure 6b) creates two parameters on the left—Cloud and VMName. These are both typed as String. Those parameters will contain the values used on the right for the Destination and VM Name when the second activity creates the VM.
Figure 6a Properties for Initialize Data.
Figure 6b Properties for Create VM from Template activity.
Creating a runbook this way lets you document specifics when creating a Service Request in Service Manager. That process requires a series of extra steps that involve integrating Service Manager with Orchestrator. Then you have to create the necessary template, service request and service offering objects in Service Manager. You can read about those steps in next month’s column.
What you can get excited about is the final result from the Orchestrator-to-Service Manager connection. You’ll have complete automation for service requests. With a few additional steps, you can even automate whatever approval routing your business requires before taking action.
You might think of System Center as a comprehensive and far-reaching enterprise platform, but its tools are no less effective for smaller environments. There are always manual activities whose automation can free overworked personnel for more value-added tasks. Even better, you can quickly deliver that automation without needing long and cumbersome Windows PowerShell scripts.
You might say Orchestrator is a path to the post-Windows PowerShell era. The graphical and object-oriented interface of Orchestrator offers complete automation for everything else.