Understanding System Center Orchestrator 2012

Automate day-to-day tasks

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
 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

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

 Run Program
 Query Database
 Run SSH Command
 Query WMI
 Invoke Web Services
 Run .NET Script
 Get/Monitor/Create SNMP Trap

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.

 
 Figure 2: Using the Orchestration console

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 [Link]. 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:

1. Create a blank text file, named [Link], in the c:\temp directory of the server on which you've
installed Orchestrator.
2. Open the Orchestrator Runbook Designer. In the Menu pane, right-click Runbooks, click New, and
then click Runbook.
3. In the Activities pane, open the System area and drag the Run Program item onto the Runbook
Designer workspace. When prompted whether you want to check out the runbook, click Yes.
4. Click the Text File Management area. Drag the Append Line task onto the Runbook Designer
workspace, next to the Run Program item.
5.  Hover the mouse over the first Run Program item. Click the arrow that appears on the right-hand
side of the item and drag it on top of the Append Line item.
6. Double-click the Run Program item. In the Program Path text box, enter c:\windows\system32\
[Link]. Click Finish.
7. Double-click the Append Line item. In the File text box, enter c:\temp\[Link].
8. Click the dots, and then select the ASCII file encoding option.
9. Right-click the Append text box, click Subscribe, and then click Returned Data.
10. In the Returned Data text box, click Pure Output, and then click OK. Verify that the Append Line
Properties dialog box looks like the one in Figure 3, and then click Finish.

To execute the task, click Runbook Tester, and then click Run. Open the [Link] 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.

Figure 4: Using a runbook to automate SCSM alert resolution

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.

System Center 2012 Configuration

Manager and Orchestrator – Using Status
Message as a Runbook Trigger
Mechanism.
I love the integration of System Center 2012 Configuration Manage and System Center
Orchestrator . Any day in which I get to work in a mutual space between these two
technologies is a good day. As seen in some of my previous blog postings I have written an
application that allows for the manual execution of Orchestrator Runbooks via. Console
Extensions (Right Click Tools). This is neat and adds value in somewhat of a service driven or
manual capacity. What I will be showing in this posting is another method by which to use
System Center 2012 Configuration Manager in order to execute Orchestrator Runbooks
however this time in more of automated/reactive fashion. As the title states, in this blog
posting I will be exploring the use of Configuration Manager Status Messages as an
Orchestrator Runbook trigger mechanism. The sample scenario used in this blog will detail the
following process

 Automate the consumption of a very specific type of ConfigMgr Status Message

(Software Update Scan Failure on client).
 Trigger an Orchestrator Runbook that will gather information about the effected client.
 The Runbook will then create a System Center Service Manager incident containing all
gathered client information.

Please keep in mind that this is just a simple example meant to demonstrate System Center
2012 integration and is by no means a guide targeted at how to identify software update scan
failures. While I attempt to use examples that represent common real world scenarios, and
while this specific example may be very helpful, there are potentially an unlimited amount of
applications for this type of System Center Integration and configuration – Be Creative.
Scenario Overview –
Here is the scenario. You are a service engineer tasked with using System Center 2012
Configuration Manager for the deployment of software updates to all client computers in your
portion of an organization. It has been recognized that many machines in your organization
experience issues in which an incorrectly applied Group Policy Object causes a software update
scan cycle conflict which is causing the failure of all software update deployments to these
machines. The issue may be that they have been placed in an incorrect OU or are experiencing
some other Group Policy related issue. You would like to automate not only the identification of
the offending machines but once identified would also like to automate the creation of a
Service Manager Incident which will provide details relevant to the issue.
Technical Overview –
In order to meet the goals as described in this scenario the following will take place (each of
these will be detailed later in this posting).

 An Orchestrator Runbook will be created which

o Consumes a Computer Name.
o Discovers the Computers distinguished name which will include the OU Location.
o Opens a Service Manager Incident using this information.
 A Status Filter Rule will be created in ConfigMgr which will trigger when any message
with an ID 11424 is detected.
 This Status Filter Rule will execute an application which will in turn start the previously
mentioned Runbook, passing to it a computer name consumed from the status
message.
 Once the Service Manager Incident has been created an email will be sent from Service
Manager informing of the Incident.
 At this point the assigned technician can engage the incident.

Client –
Before starting in on the solution let’s take a quick look at my sample client experiencing the
software update scan failure. What I have done is simply created a new OU named and applied
to this OU a GPO containing an invalid WSUS Intranet update service address. When applied to
my client which is also being managed by configuration manager, the GPO creates a conflict
with the Configuration Manager Software Update Point and botches the Software Update Scan
Cycle.
[Link] from effected client (click image for a better view).
As a result of this failure a Status Message with an ID of 11424 is generated.
Status Message (click image for a better view).
 

Runbook –
The Runbook used in this example consist of three activities.
Click image for a better view.

 Initialize Data – Consumes a computer name.

 Get Computer Information – uses the Active Directory IP to discover the DN of a the
identified computer.
 Create WUA Conflict Incident – uses a Service Manager template to create a new
incident for the effected computer.

Note – This is a very simple Runbook void of all error handling and flow control. This sample is
meant only to demonstrate the execution of Runbooks .via Configuration Manager Status
Messages. If done with intent and in a production capacity I would personally add more
activities to the Rubnook (or series of Runbooks) which would better handle the start to end
execution.
If you would like more information on Runbook Design best practices Charles Joy’s blog is a
great place to start with – Charles Joy’s Blog
Service Manager Components –
There is not much configuration if any that needs to take palace in Service Manager to support
this example solution. For my demonstration (See Video) I have created a Template from which
to create the incident however there is no fancy configuration here. I also have my Service
Manager environment configured to create and deliver a notification when an Incident is
created.  So while there is not much to write about on the Service Manager end I will take the
opportunity to highlight that in this solution Service Manager itself handles the email
notification workflow (as opposed to Orchestrator).
Configuration Manager –
Finally the Configuration Manager portion of the solution. To start this solution we will be
creating a Status Filter Rule – this rule will take action when a specific status message has been
processed by the Configuration Manager application. As previously discussed when a client fails
to scan for software updates due to a GPO conflict a status message of 11424 is generated. So
for each client that experiencing the issue, this status message will be generated at each scan
cycle.
To create the status filter rule right click your site and select status filter rules.
Click image for a better view.
Click on Create to open up the Status Message Filter Rule property window.
Click image for a better view.
Select Message ID and enter the ID 11424.
Click image for a better view.
Click on the Actions tab in order to configure the action that will execute once a status message
of 11424 has been received.
So up until this point I have only indicated that this status filter rule will trigger the execution of
an Orchestrator Runbook. I have not detailed how this will be achieved. Thanks to the
Orchestrator Web Service there are multiple different approaches that could be used –
ultimately each one will be interfacing with the Orchestrator Web Service, passing to it all
needed parameters and starting the Runbook.  Rather than use a script or cooking up a solution
I will be using SCOJobRunner. SCOJobRunner was written by Robert Hearn and supports the
remote execution of Orchestrator Runbooks. More information can be found at the following
blog.
[Link]
[Link]
In order for this to work grab a copy of [Link] and place this on an accessible share.
The command line I have used to support this solution is similar to the following.
\\share\c$\[Link] -ID:”ECA14605-EDCE-4F16-9E1C-23C2FD3D9819″ -
Webserver:”<SCO WebService Computer>” -User:<user name> -Domain:<domain> -
Password:<password> -Parameters:Computer=%msgsys
Take note of the parameter value – Computer = %msgsys. This piece will pull the effected
computer name from the status message and pass this to the Computer (or other specified)
parameter in the Orchestrator Runbook.
Execution –
With all of the pieces in place, once an effected machined has attempted and failed at a
software update scan cycle, a status message will be generated, the Orchestrator Runbook will
execute consuming the computer name from the status message filter rule, collecting data
about this computer from active directory, and finally open up a System Center Service
Manager Incident including relevant computer details.
Generated Email (click image for a better view).
Created Service Manager Incident (click image for a better view).
Closing and Video Demonstration –
I hope that you have enjoyed this blog and have found this information helpful. I have created a
short video demonstration of this process in action. Enjoy!
Video – click here to view the video.
Tags Configuration Manager Orchestrator Private Cloud SCCM SCORCH SCSM Service
Manager System Center Orchestrator