I received a questions a couple of days ago how to delay a runbook? The scenario was that someone submit a service request in Service Manager which includes a couple of runbook activities, but these runbook activities should not run until two days later. As we don’t want runbooks to be hanging, looping or paused for two days we can’t simple add a “wait two days activity” in a runbook. We also want to see in the service request in Service Manager that we are waiting for Orchestrator, and the service request should not be marked as completed until the runbook activities have run.

There are a number of ways to solve this. In this blog post I will show one where we use multiple runbooks and an external database to store data temporary. The scenario in this example is that you order a server reboot from the self-service portal in Service Manager. In the portal you pick a date and also set a checkbox if the server is an IIS server. Server reboot is only allowed after office hours, in this example around 23:00 every evening. The process is

1. You submit a service request from the self-service portal in Service Manager, saying that a server need to be rebooted at a specific day. You also set if this service is a IIS  or not
2. A runbook is triggered and write the service request data into a external database
3. The service request moves to next activity which is a manual activity
4. Another runbook is running every day at 2300 and checks the external database for reboot jobs that should be executed at that day. If there is a job the runbook reads all the service request details from the external database, restarts the machine and updates the manual activity. If the server is a IIS server some extra steps is executed during the restart

• Monitor Date/Time, trigger the runbook every day at 2300
• Query Database, ask the external database if there are any reboot jobs to execute (SELECT * FROM Reboot WHERE DATE <= GETUTCDATE())
• If there are any rows returned the runbook moves to Restart System. Restart System reboots the target machine, it also sends the service request id to the target machine shutdown tracker.
• Run .Net Script, waits five minutes (Start-Sleep -s 300)
• Get Computer/IP Status, tries to ping the machine. If percentage of packets received is 100 the runbook moves to Query Database (2) else it generates an alert in Operations Manager
• Query Database (2) query the external database if the target machine is a IIS or not. As we use that on the link as condition we need to do the query again. A link can only have a condition based on the previous activity.
• If the target machine is a IIS we check the web server service, if the service is not equals “Service Running” we generate an alert in Operations Manager
• Of the machine is not a IIS or if the web server service is running, we move to Get SR
• Get SR picks up the service request
• Get Relationship gets all related manual activities, in this example we only have one, named “Waiting for Orchestrator to reboot”
• Update Activity, set the “Waiting for Orchestrator to reboot” activity to completed
• The last Query Database activity deletes the reboot job from the external database

The image below show the event written to the System log on the target machine when it is about to be restarted.

Don´t forget to add a couple of activities to handle Operations Manager maintenance mode in your reboot runbooks too 🙂

As a alternative solution you could also create a new custom activity instead of using the default manual activity (example of how to build custom activity can be found here), then have only one runbook that checks every day at 2300 for activities of that class in “ongoing state”. The runbook can read all the settings from the custom activity, for example which server to reboot and when. If “when” is today the runbook reboots the server and marks the activity as completed.

Note that this is provided “AS-IS” with no warranties at all. This is not a production ready management pack or solution for your production environment, just a idea and an example.