I am happy to report that the Parse Orchestrator Export tool is now available for public consumption! This has been a back burner project for me for quite a while now and is actually one of a suite of projects I inherited from Robert Hearn when he left Microsoft. I blogged earlier about its default functionality (https://opalis.wordpress.com/2013/04/11/parse-orchestrator-export-tool/) and will use this post to expand a bit on the new functionality. The project is available at http://scorch.codeplex.com/releases/view/104915
What is it?
It is a GUI application that looks at exports from your Orchestrator environment and allows you to perform multiple actions on them before re-importing them into the same environment or another Orchestrator Environment
Display a Graphical Representation of an Export
- We use this internally while doing change control to ensure that all Global Configurations are properly configured in the destination Orchestrator Environment
- This will remove all un-referenced global Settings and Configurations
Apply Link Best Practices
- Modifies the links of an export to give them appropriate names and colors
Set Max Parallel
- Allows for Bulk setting of Runbook Job Concurrency
Turn On / Off Generic Logging
- Turns Off or On Generic Logging for All Runbooks
Turn On / Off Object Specific Logging
- Turns Off or On Object Specific Logging for All Runbooks
Iterates through the Export File and checks for common misconfigurations
- Multiple Link objects between the same source and destination objects
- Trigger Policies that do not have all of the input parameters for the target policy defined
- Changes the name of any Runbook / Folder / Object / Global Configuration
This is one of the most exciting functions of this tool in my opinion. This, coupled with “Set Max Parallel” makes it very simple to set Job Concurrency in bulk. It also makes it very easy to ‘duplicate’ runbooks and have them maintain their own unique sets of global settings / configurations for connecting to resources
Max Parallel Example
Say I wanted I had a Runbook that is called from SCCM task sequences through our Web Service. I probably want each one of my Runbooks to be able to be called by different machines being re-imaged. By default though, each Runbook has it concurrency set to 1. This means that all of my requests will ‘stack up’ behind one another (ie if I have 5 machines that make a call to my workflow for shutting off Port Authentication they would be handled one at a time in the order they were received even though they could all run at the same time). To change this behavior we can go in with the Runbook designer to each Runbook and set ‘Job Concurrency’ to something other than one
Or, if we want to do it in bulk we can use the Export to to change a folder name then click ‘Set Max Parallel’ and it will change the setting for all of our Runbooks!
And now all the Runbooks under that folder have their concurrency set to 5! More information about ‘Set Max Parallel’ can be found at https://opalis.wordpress.com/2013/04/17/bulk-set-orchestrator-max-policy-requests/
The most interesting use of ‘Modify Name’ I think though is the ability duplicate a Runbook in such a way that it can live in the same environment as its base Runbook without sharing any references. Imagine if you will a scenario where we have a Runbook that will be called by a task sequence. The first version of these Runbooks *should* be pointed at ‘development’ infrastructure – a test Active Directory domain, a test SCCM instances etc etc – the though becomes how do we make a ‘production’ version of this without much effort and while keeping our development version? Modify Name to the rescue!
Step 1: Export your Runbook
Step 2: Sanitize your Runbook with the tool
Step 3: Modify Global Names to Ensure Uniqueness
If there is anything in your export folder that you need to have a ‘separate’ instance of for the ‘new’ version then simply change its name using Modify Name (it will update both the element name and all references to that name). We usually will re-name the Root Runbook Folder, the Root Variable Folder and all Global Configurations
Renaming Root Runbook Folder
Supply the New Name and Click Ok
Renaming Root Variable Folder
We also rename the root Variable folder, this means that we will have two totally separate versions of all variables and we can update them independently
Renaming Global Configurations
We can also rename Global Configurations (those things under ‘Options -> Integration Pack’) meaning we don’t have to go in and ‘re-point / reconfigure’ all of our objects to change a global configuration
Now we have unique versions in our export file of everything that we want to be independent of the other version. We can no re-import and go about our day!
Hopefully everyone finds this useful!