System Center 2012 Orchestrator–RunBook Basics

System Center Orchestrator 2012 which is a new member of System Center 2012 family and next version of Opalis, takes place at the center of Private Cloud scenarios. During automation of your dynamic datacenters, Orchestrator can move your operations one more step forward and can integrate with Microsoft and non-Microsoft solutions with just a few clicks.

Let me give you a few examples;

You can trigger Orchestrator workflows through an incident management system such as Service Manager 2012.
Periodic installation processes can be automated. For example during installation you can take actions on active directory, stop load balancer pools, check service status etc.
Active directory operational tasks such as user create, user delete, group create, change memberships etc. can be moved to the orchestrator RunBooks.
You can monitor SCOM alerts and trigger custom RunBooks. For example when a virtual machine run out of disk, SCOM generates an alert and orchestrator can assign additional disk through triggered RunBook.

In this blog post series we’ll cover of how to design RunBooks from basic to complex. And at end of the series you will understand what Orchestrator 2012 can do and how can you integrate it into your current environment.

For the first part “RunBook Basics” I’ll mention basic RunBooks concept and activities that resides within RunBooks.

A RunBook consists of automated tasks and process steps. Also each automated step within RunBooks is called activities.

Here is the very basic RunBook design;

That RunBook reads a static text file and maps each line to the server names then restarts a service for each remote server automatically.

Before going into the RunBook creation details, let’s look at the RunBook properties.

Right click a previously created RunBook and click Properties.

GENERAL:

On the General tab, you can customize name and description fields. Name is an important field because if you decide to import your RunBooks into the Service Manager as activities, you will recognize each RunBook with its name. (Yes you can import your RunBooks into the Service Manager!)

Also on general tab, you can set a schedule to allow RunBook runs only on dates and times you specify.

RUNBOOK SERVERS:

Each RunBook needs a RunBook server to run. In case of requirement High Availability , you must add additional RunBook Servers. For each RunBook, primary and standby RunBook Servers can be set.

Failure of primary RunBook server will trigger standby RunBook server to act as primary.

To set Primary and Standby RunBook Server for RunBooks, click Add and specify your RunBook servers.

LOGGING:

In this section you can choose more logging options to store in Orchestrator Database and show up within Orchestrator Console.

I’ll talk about in more details in future posts.

EVENT NOTIFICATION

On event notification tab, additional log file can be generated when a RunBook fails to run or run for more than specified seconds. Related log files can be viewed with Designer Console or Web Console.

JOB CONCURRENCY

One of the most critical option is Job Concurrency. Even you configure this setting for one single RunBook, in fact it has impact on overall Orchestrator RunBook Servers. Main purpose is specifying concurrent jobs for this RunBook. A RunBook server can have maximum 50 concurrent jobs. So that if you need more than this limit you must deploy additional RunBook servers.

RETURNED DATA

If you finalize your activities with “Return Data” activity, this RunBook can carry out defined data to the other RunBooks.

In this blog post we cover basic RunBook concept. For the next parts we’ll drive in more detail about designing and deploying RunBooks over multiple RunBook servers.

SecureInfra Team

Author