In the previous two parts of this overview of Orchestrator 2012 we looked at what Runbook automation is and why it’s so important as well as the components of Orchestrator. In this third part we’ll look at how runbooks are created in the Runbook Designer.

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

Once you’ve worked through with the business which processes to automate the actual steps in Orchestrator are easy and the user experience is almost identical to Opalis. You drag Activities from panes on the right into your workspace. These activities are either Standard Activities (known as Foundation Objects in Opalis) that are available out of the box or they come from Integration Packs (IPs) that you’ve installed.

You then configure each activity to accomplish what you want and link the activities together, taking into account branching for different outcomes. Activities can also take into account variables and counters that you’ve configured as well as perform manipulation of data; this is then passed onto the next activity on the shared data bus as Published Data.

Once you have created a runbook you’ll want to test it and the Runbook Tester provides the ability to debug, including setting breakpoints. Be aware that the Tester isn’t a simulated environment, the activities are actually executing on your live data. Another gotcha is that runbooks run under your account in the Runbook Designer but in the Tester they run under the Runbook Server service account.

System Center Orchestrator 2012 - Runbook Tester

The Runbook Tester lets you step through your runbooks activities and make sure it’s all working as expected. Remember, it’s a live environment, not a simulated test!

Standard Activities are available for system process and SNMP, scheduling, monitoring, file management, email and other notification options along with utilities for invoking web services or querying databases. For Linux integration Orchestrator comes with standard activities for Telnet and SSH workflows. The .Net script activity can run scripts in VB.Net, Jscript, C# and PowerShell.

The links between activities can be formatted with colors and widths as well as letting you control the data that flows between activities with Include and Exclude options (with the latter taking precedence over the former) to filter out data for the next activity. For branching logic you can control what happens for success, warning and failed conditions in activities. You can also use regular expressions to filter the output data as well as perform functions and calculations on numerical values. Activities can be looped with precise control over the exit condition.

Runbooks can be scheduled with control over when they’re allowed to execute (perhaps some should never execute during business hours), and each Runbook can be associated with a particular schedule. Within a runbook, you can use the Check Schedule activity to retrieve time data for individual activities. Monitors are a type of activity that waits for a particular event to happen to start the processing of a runbook and these runbooks “run” continuously, waiting for the event to happen.

In this part three of five we looked at the steps involved in creating runbooks, in part four we’ll cover permissions for runbooks as well as best practices for creating them.

Win the monthly 4sysops member prize for IT pros

Share
0

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account