Orchestrator Runbook Design, Planning and Validation

Anders Bengtsson has done it again and written another stunning blog post about validating your runbook designs.

This ties in nicely with a discussion that I was having with a customer yesterday where I was stealing a comment made at the Best of MMS 2011 UK event where Adam Hall (I'm sure it was Adam, if not I apologise to whoever it was) coined a phrase about a day of design roughly equates to an hour in the runbook designer.

The point I was trying to get across to the customer is that while setting up SCORCH (or to some extent Opalis) is relatively simple and you can dive into the console and knock up runbooks very quickly too, it's very important to take that step back, map out your process first fully, exploring all angles, then create the runbook from this plan, and then like Anders says, build it out with resilience, checking and logging.

Back to the initial point...

Anders now has a trilogy of posts that I would really recommend reading, even if you feel really confident creating runbooks, I'd bet you don't use half the methods fully like Anders recommends.

Post 1: Fault Tolerance in Runbooks
Post 2: Building a log for Runbooks
Post 3: Validate your Runbook Design (He also includes a runbook which automates some checking!)

Simple Orchestrator Runbook to move software to a Definitive Media Library (DML)

While trying to think of an example that I could use to create a runbook in SCORCH using only the standard activities I remembered a situation in my previous role where the Service Desk were responsible for gathering the software and documentation required for calls from users to upgrade systems/install new software.

Because we used the Microsoft Deployment Toolkit 2010 and specifically the Applications part of the deployment share as our Definitive Media Library (DML) it was a multi stepped approach to gathering the software from the users, assessing it and then moving it into a structured area via the MDT console.

So I started to knock together an example runbook to help with this process.

Originally I wanted to utilise the PowerShell functionality in MDT, but ran into an issue as Orchestrator uses the 32-bit powershell but being a 64-bit only OS (2008 R2) meant I couldn't install the MDT PowerShell snap-ins to work with the 32-bit PS.

So I went for a more basic runbook that monitors for a definition file (text file with a specific name and specific content) which would then kick off the process of moving and structuring the files in a DML.

Watch the video for the runbook in action:

While this is a very simplistic runbook, it shows the processes of reusing the data on the databus.

I'm limited in my testlab with what I can do for demonstration purposes, but as an example of how this could be enhanced, you could add a SQL query rather than monitoring for a file to query a service desk application for a new Service Request or Change Control being raised of a certain category and take the information from that call using the SQL query and use that in the runbook instead of a text file.

Exported runbook:

How to find activities in your runbooks that have changed in the new Orchestrator

Adam Hall has just posted a really useful SQL query that can be run against your existing Opalis database to help you understand what objects you currently use that are no longer available in Orchestrator.

This is a brilliant piece of information as it could save you a boat load of time before you upgrade by identifying which run books you need to tweak in advance rather than having to import each one with fingers crossed hoping it doesn't break.

The original post is here, but I've replicated the SQL code below for my own benefit so I know where it is without having to search ;)

Please bear in mind that Orchestrator is still in Beta, so by RTM there could be more objects to add to this SQL query.

Select
policies.[Name] as [Policy Name],
objects.[Name] as [Object Name]
From
[Objects] objects join
[Policies] policies
on objects.[ParentID]=policies.[UniqueID]
Where
objects.objecttype = '2081B459-88D2-464A-9F3D-27D2B7A64C5E' or
objects.objecttype = '6F0FA888-1969-4010-95BC-C0468FA6E8A0' or
objects.objecttype = '8740DB49-5EE2-4398-9AD1-21315B8D2536' or
objects.objecttype = '19253CC6-2A14-432A-B4D8-5C3F778B69B0' or
objects.objecttype = '9AB62470-8541-44BD-BC2A-5C3409C56CAA' or
objects.objecttype = '292941F8-6BA7-4EC2-9BC0-3B5F96AB9790' or
objects.objecttype = '98AF4CBD-E30E-4890-9D26-404FE24727D7' or
objects.objecttype = '2409285A-9F7E-4E04-BFB9-A617C2E5FA61' or
objects.objecttype = 'B40FDFBD-6E5F-44F0-9AA6-6469B0A35710' or
objects.objecttype = '9DAF8E78-25EB-425F-A5EF-338C2940B409' or
objects.objecttype = 'B5381CDD-8498-4603-884D-1800699462AC' or
objects.objecttype = 'FCA29108-14F3-429A-ADD4-BE24EA5E4A3E' or
objects.objecttype = '7FB85E1D-D3C5-41DA-ACF4-E1A8396A9DA7' or
objects.objecttype = '3CCE9C71-51F0-4595-927F-61D84F2F1B5D' or
objects.objecttype = '96769C11-11F5-4645-B213-9EC7A3F244DB' or
objects.objecttype = '6FED5A55-A652-455B-88E2-9992E7C97E9A' or
objects.objecttype = '9C1DF967-5A50-4C4E-9906-C331208A3801' or
objects.objecttype = 'B40FDFBD-6E5F-44F0-9AA6-6469B0A35710' or
objects.objecttype = '829A951B-AAE9-4FBF-A6FD-92FA697EEA91' or
objects.objecttype = '1728D617-ACA9-4C96-ADD1-0E0B61104A9E' or
objects.objecttype = 'F3D1E70B-D389-49AD-A002-D332604BE87A' or
objects.objecttype = '2D907D60-9C25-4A1C-B950-A31EB9C9DB5F' or
objects.objecttype = '6A083024-C7B3-474F-A53F-075CD2F2AC0F' or
objects.objecttype = '4E6481A1-6233-4C82-879F-D0A0EDCF2802' or
objects.objecttype = 'BC49578F-171B-4776-86E2-664A5377B178'