Home » Orchestrator » Consider Invoke Runbook activities when doing a runbook update


Welcome to contoso.se! My name is Anders Bengtsson and this is my blog about Azure infrastructure and system management. I am a senior engineer in the FastTrack for Azure team, part of Azure Engineering, at Microsoft.  Contoso.se has two main purposes, first as a platform to share information with the community and the second as a notebook for myself.

Everything you read here is my own personal opinion and any code is provided "AS-IS" with no warranties.

Anders Bengtsson

MVP awarded 2007,2008,2009,2010

My Books
Service Manager Unleashed
Service Manager Unleashed
Orchestrator Unleashed
Orchestrator 2012 Unleashed
Inside the Microsoft Operations Management Suite

Consider Invoke Runbook activities when doing a runbook update

The recommended way to build runbooks is to build them in a isolated environment, then move them to a test environment and after that move them into production. In the production environment no modifications should be done, only import new or updated runbooks. When working with the Invoke Runbook activity there is a setting named “Invoke by path”. By default you invoke a runbook by GUID, meaning that you can move around a runbook between folders but it will still be triggered as it has the same GUID.

When the “Invoke by Path” setting is enable you will always invoke the runbook with the same folder path and name as configured, in this example /Prod/C. Even if update or re-create runbook C in the Prod folder it will be invoked. The challenge is when you invoke, with the invoke by name enabled, another runbook that requires parameters. In the image above we invoke a runbook named C with parameter named msg, the value is “Hello World!”. Looking at this from the database it looks like this

As you can see it will pass “Hello World!” to a parameter with GUID “87BFA0D3-741E-4E9A-9F84-7AD0AEC0FB75”. If we now import a new runbook named C and replace/overwrite the current version of runbook C, the first runbook will still try to trigger runbook C (the path is the same) and still a parameter with GUID “87BFA0D3-741E-4E9A-9F84-7AD0AEC0FB75”. But if we look in the Runbook Designer console, in runbook A we see that the value field is empty on the Invoke Runbook activity

This happened when we imported a new version of the C runbook. Why? It is because when we imported the new version of runbook C it has a new parameter. Even if the parameter has the same name and the runbook looks the same, same activities, the parameter GUID is not the same. The GUID is generated when the activity is created and it follows the activity. If you for example build a runbook in a test environment and then export it to production, it is the same GUID in both, the one from the test environment where you created it the first time.

With the following SQL query you can see all Invoke Runbook activities that have a NULL/blank  the value fields


To handle this, avoiding to manual update all Invoke Runbook activities when you implement a new version of the runbook they invoke, you need to work with updates. Always update the runbook, don’t create a brand new runbook. You can import your archive file, or even export from production, edit the runbook in another environment and then re-import it again. That will keep the same GUID for everything you don’t re-create. If you re-create any of the initialize start parameters you need to update runbooks that pass parameters to it.



  1. Hi, it is a bit trickey if you call a runbook by GUID and then change the GUID. What you need to do is to Always update the existing runbook, as you will then keep the GUID. If you create a new runbook and import it, even if it has the same name, it will have Another GUID and links will not Work from external systems.

  2. Great suggestion for call runbooks from other runbooks. What are the best practices for handling runbook GUID changes during, runbooks upgrades, which are called from external systems?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.