I spend a lot of my time assisting clients with Service Manager and helping deliver self-service automation capabilities to organizations. Two things often involved in that task are employing automation via Orchestrator Runbooks synced to Service Manager, and migrating Runbooks and management packs between Development and Production environments. If you’re like me and have combined those tasks in your work, you’ve probably run into headaches with the migration of management packs containing the templates and request offerings leveraging those Runbooks.
THE PROBLEM
The process of migrating management packs containing references to synced Runbooks is complicated by the format of those references. Runbook references are stored not by a property synced from Orchestrator but by the GUID generated by Service Manager upon initial sync. Since the GUID is unique to a given Service Manager environment, importing a management pack without updating the Runbook GUID leaves the reference incorrect, the template and request offering broken, and the automation not working.
The issue isn’t a secret, and there have been blogs discussing it, as well as third party tools designed to help ease the process. Unfortunately, those instructions and tools have been limited to manual copy/paste solutions or those that only update a single management pack at a time and necessitate re-inputting configuration information each time. In my experience, the faster and more automated a solution can be, the more valuable it is, both to me and to my clients. I decided I should find a better solution to update Runbook GUIDs.
THE SOLUTION
The work involved to collect and update Runbook GUIDs in the management packs is incredibly repetitive and time consuming, making it perfect for scripted automation.
I created a PowerShell script to automatically process a collection of unsealed management packs to update Runbook GUIDs. Not only does it automate the entire process, but it completes the work fast. The full script is described in detail below, as well as provided as a download at the end of this post for your use.
The script is designed to connect to both a Source and a Target Service Manager environment, generating lists of the synced Runbook Items in each. For each Runbook Item it finds that exists in both environments, the script searches through the content of all unsealed management pack files (.xml) in a specified folder to find any instances of Source environment Runbook GUIDs. If it finds them, it replaces them with the GUID of the appropriate Runbook Item from the Target environment. Once each of the matching Runbooks have been processed, the resulting management packs can be imported into the Target environment while preserving all automation configuration.
HOW TO USE THE SCRIPT
The script is designed to be run with parameters, so to use it, you simply need to run the script from a PowerShell prompt with the appropriate values for your environment. Alternatively, you can edit the parameters’ default values to hard-code them for whatever is appropriate in your environment and launch it from File Explorer. The only mandatory parameters are the Source and Target Service Manager servers. Unless otherwise specified, the script assumes that the Service Manager native PowerShell module can be imported from its default install path on the C drive and that all unsealed management packs to be processed can be found in a folder titled “Unsealed MPs” located in the same folder as the script. If your unsealed management pack files are in a different location, you will need to specify the alternative location. The intended usage from the command line is this:
UpdateRunbookGUIDs.ps1 -SourceSMserver “” -TargetSMserver “” -SMInstallPath “” -UnsealedMPFolder “”
BREAKING DOWN THE SCRIPT
The script is heavily commented and should be easy to read. In addition to the script’s comments, the following paragraphs will break each section down in more detail.