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 Orchestrator 2012 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
-
Runbooks
-
Data Bus
-
Integration Packs
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 monitoring activity is invoked from an external source and used to start runbooks. For example, a monitoring activity might be triggered by a
specific Ops Manager alert.
-
Action activities are invoked by other activities and carry out specified procedures -- anything from ending a process, running a Microsoft .NET
script, or restarting a service to using System Center Configuration Manager (SCCM) to deploy a software update, using System Center Virtual Machine
Manager (VMM) to create a virtual machine (VM), or updating a System Center Service Manager (SCSM) job.
-
Runbooks
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.
Figure 1: Example of a runbook