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.