Runbooks should be administered using version control. For each version deployed into production, create a package including the runbook and documentation. The documentation should include an explanation of the runbook, including all parameters, global settings and variables. As Orchestrator don’t include version handling it is a good idea to keep earlier runbook versions as export files, making sure you can rollback to earlier versions easy. You should also have a change management process around releasing new runbooks to production to make sure they are tested and signed off correct by the different teams.
As an additional layer of your change process, or maybe in lack of a change process, you can use check in comments in Orchestrator. In the Runbook Designer console you can enable “Prompt for comment on check in”. This is not enabled by default but it is something you should enable at least in your production environment. The result is that each time you click check in in the Runbook Designer console you need to input a comment. It is very easy way to keep track of changes.
You enable check in comments from the Options menu > Configure, in the Runbook Designer console.
All check in comments are written to the Orchestrator database, in the CHECK_IN_HISTORY table. Together with the POLICIES table and the OBJECTS_AUDIT table we can list all comments with account name, runbook name and date. We can also use SQL Server Report Builder to build a report to show this data. The following SQL query will show all check in information.
SELECT CHECK_IN_HISTORY.DateTime AS [Check In Time], POLICIES.Name AS [Runbook Name], CHECK_IN_HISTORY.Comment AS [Check In Comment], SIDS.Account, POLICIES.Version AS [Current Version in database]FROM CHECK_IN_HISTORY INNER JOIN POLICIES ON CHECK_IN_HISTORY.ObjectID = POLICIES.UniqueID INNER JOIN SIDS ON CHECK_IN_HISTORY.CheckInUser = SIDS.SIDWHERE (POLICIES.Deleted = 0) ORDER BY [Check In Time] DESC
“Current Version in database” is a value we get from the POLICIES table. Each time we click check in Orchestrator will add one to that value, so if we check out and check in a runbook 20 times it will show version 20. As we get this value from the current checked in runbook it will show the same “Current Version in database” for all check in for the same runbook, so it is not the version that was checked in at that time.
You can download my example report here, CheckInHistory. Note that this is provided “AS-IS” with no warranties at all