I have updated the “runbook validator” again. Added a couple of new checks and also added a table of contents in the beginning of the report. You can download the new version here, 20130419_SCO_CHECK.

Since I started to work with Opalis I have been surprised to see how fast people build their first runbook (policy back in Opalis). When showing Orchestrator for a group of engineers it doesn’t take many minutes before they have a running workflow. A disadvantage when it is too easy, drag-drop-done, is that Orchestrator is some times not used as it should be used. In Orchestrator the challenge is that many engineers quickly drag and drop a couple of activities to the runbook, click Start and then lean backward. Most likely they have a working runbook, but are they really working? Is it built as it should be? Is it tested? I have written a couple of blog posts around best practices and the areas that the “runbook validator” checks

• Fault tolerance in Opalis polices,
• Building a log for your runbooks
• Check in history
• Should this runbook be running
• Job concurrency in Orchestrator
• Consider Invoke Runbook activities when doing a update and dependencies between runbooks
• Activities not using default account and run a runbook with a specific account
• Link delays

The “runbook validator” is a set of runbooks that will check all other runbooks according to a number of best practices. A report file will be generated with the result. All runbooks use a number of variables, like Orchestrator database server name and database name. Don’t forget to update them before you run the check.

If you have any ideas what I should add, please post them as comment to this post or send me an e-mail. Please note that this is provided “as is” with no warranties at all. Also note this is all based on my ideas and is not a “Health check” or Microsoft official guidelines.