- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Considerations for creating a good runbook include knowing when and how often it’s going to run, which steps to include, how it’s going to start, what data is passed along from activity to activity and what’s the end result as well as how you are going to report on the results? Good design includes handling failures and warnings of activities, clear naming conventions, using link colors wisely and splitting long and complex runbooks into parent and child tasks that pass data to each other. Establishing a good naming convention and an agreed upon folder structure will minimize confusion and exporting your runbooks regularly for backup purposes is prudent.
Permissions can be set at the individual runbook level or you can group runbooks together and control security at the folder level. Read permissions let a user run and view runbooks, write makes changing possible and with full control users can alter the permissions. Security can also be controlled at the IP level, for instance you could have three different configurations for connecting to a ticketing system to match permissions for level 1, 2 and 3 help desk staff. Orchestrator provides simple version control; once a particular user has checked out a runbook for editing, no one else can alter it until it’s checked in again.
To control what systems are targeted by a runbook you can use Computer Groups in Orchestrator and these in turn can be based on AD queries, ensuring that new Exchange servers end up in the right group for example.
An example Runbook that’s part of a set of SC 2012 runbooks recently published on Codeplex.
There are several types of logging to see how Runbooks and Orchestrator is doing, I find that turning on object level logging for a Runbook gives enough insight when I’m creating and testing Runbooks. There’s both a Real time log for currently executing runbooks as well as a historic log. For each runbook you can set logging to include the values of the Published Data; either Activity specific data and / or Common Published data. There are also the Audit Trail text log files that detail the interaction of Orchestrator with external systems; this is not enabled by default. Logging can add substantial amounts of information in your database, a scheduled job can either purge this data regularly or you can manually purge runbook logs.
You can set up a runbook to notify you when it takes longer to execute than a threshold you’ve specified as well as control how many instances of a specific runbook is allowed to run simultaneously. Be careful if your runbook has a modify counter activity not to run several instances at the same time. For robustness it’s also a good idea to have an activity early in a runbook that detects if there was an earlier instance of the runbook that was terminated (server crash or other mishap) so this can be handled smoothly.
A key consideration in automation is that when things “just happen by themselves” it’s crucial to keep an eye on the environment through monitoring and reporting; there’s an Orchestrator management pack for Operations Manager that’ll help in this regard.
In this part four of five we looked at best practices for runbook creation, in the next and final part we’ll look at extending Orchestrator with Integration Packs as well as how Orchestrator fits into the System Center 2012 suite.
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
