I was working on a SCORCH 2012 R2 Runbook to automate new joiner processes, and had the Runbook checked out. The machine where I had the Runbook checked out from was rebooted.
The folder containing the Runbook was visible (“New Users”), but the Runbook itself wasn’t!
I undid the check out by modifying the relevant entry in the SCORCH database.
SQL Server, Instance, and Database Name
You can determine the name of the SQL Server, Instance, and Database Name in the System Center 2012 R2 Orchestrator Deployment Manager.
Right click on ‘Orchestrator Management Server’.
Click the ‘Orchestrator Management Server’ tab.
Database Server gives you the name of the SQL Server & Instance, e.g. X500SQL01\SYSINSTANCE.
Data Store Name gives you the name of the Database, e.g. SCORCH.
In SQL Server Management Studio, connect to the SQL Server & Instance (e.g. X500SQL01\SYSINSTANCE).
Execute the following query to find the relevant Run Book.
USE SCORCH SELECT UniqueID, CheckOutUser, CheckOutTime, CheckOutLocation FROM SCORCH.dbo.Policies WHERE Name = "New Runbook".
Unfortunately, I hadn’t renamed my Runbook from the default “New Runbook”, so I got hundreds of results returned.
To track down the correct entry, I ran my query against the SID of my user account.
USE SCORCH SELECT UniqueID, CheckOutUser, CheckOutTime, CheckOutLocation FROM SCORCH.dbo.Policies WHERE CheckOutUser = 'S-1-5-21-767302812-2108017146-293201227-2618'
Now I had the correct entry, I ran an update statement against it.
UPDATE SCORCH.dbo.Policies SET CheckOutUser = NULL, CheckOutTime = NULL, CheckOutLocation = NULL WHERE CheckOutUser = 'S-1-5-21-767302812-2108017146-293201227-2618'
If I’d had a unique name against my Runbook, I could have ran the update statement against WHERE Name = “Unique Runbook Name”.
Top tips I’ve learned from this:
- Always call a Runbook something meaningful.
- Always check-in a Runbook to prevent scheduled reboots etc. causing this to happen again.