a. Invoke a “Wait Runbook” on the current runbook server to patch. This runbook should do nothing, but run forever. For example, it might infinitely loop a PowerShell sleep command.
b . Set the maximum jobs to 1 on this runbook server by invoking "C:Program Files (x86)Microsoft System Center 2012OrchestratorManagement Serveraspt.exe" from the command line on the Orchestrator Management Server. Your path to aspt.exe may be different if you chose a non-default installation location for the Management Server. The syntax for this command is: astp.exe RunbookServerName MaxNumberofJobs
c. Wait X seconds for all non-monitor running jobs on this runbook server to complete, where X is some amount of time that makes sense for the type of runbooks your organization typically runs. X should be large enough that a normal runbook should finish in that amount of time.
d. Move any jobs that are still running other than the “Wait Runbook” (probably monitors) to another runbook server by manually stopping them and then starting them again. These jobs will restart on a different runbook server than the one you are trying to patch since the max jobs for this runbook server is set to 1 and the “Wait Runbook” is holding that slot.
e. Confirm all jobs except the “Wait Runbook” have successfully switched runbook servers.
f. Do whatever work is required to fully patch this runbook server, including machine restarts.
g. Set the maximum jobs back to 50 on this runbook server by invoking aspt.exe again as in step 2.b
h. Stop the “Wait Runbook” on the runbook server you just patched.
Great! Now we have a guide to put a runbook server into a “pseudo-maintenance mode“ to keep automation up and running and not interrupt running jobs. But wait a sec…Orchestrator is so good at automating the patching of other services, wouldn’t it be great if Orchestrator could automate the patching of
itself
? It turns out this kind of patching “inception” is actually possible via a set of Orchestrator runbooks. An IT Pro can even automate the repetitive, time-consuming, and error-prone task of patching the service that lets them automate the patching of others services!
The runbook export for automating the patching of Orchestrator in a highly-available manner is available here . Remember, this is just an example and does not contain all of the error logic that you would want to apply in production usage. Some notes about using this set of runbooks:
Now just sit back, relax, and drink some coffee while your Orchestrator service patches itself!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.