Runbook Sanitation Utility


The tool (Binary and Source code) is available on the Orchestrator Community codeplex site,

Direct Download Link:

Direct Source Code Link:

Any additions / suggestions are appreciated


This utility is used to manipulate ois_export files.  At their base ois_export files are xml files.  When you do an export of your Runbooks you are given a few options around how to handle global settings and configurations, either export them, or not.


If any of your Runbooks references any of these, they need to be exported with your Runbooks.  Great, so what is the problem?  When you do the export, it will export all global settings and global configurations even if they are not referenced by the exported Runbooks.  This means that all of the extraneous global settings and configurations you have in your development environments for testing, demos, etc. will be included in your export and eventually imported into whatever environment you do the import in.  As a best practice it is suggested that before importing your policies from development into production you first import them into an environment for sanitation.  This means a manual import into an empty environment then a manual deletion of all non-referenced global settings and configurations, then another export and import into your production environment.  This process is described by Charles Joy  This means that if you have an automated process for export and imports using the COM interface you are still forced to have a manual process for sanitizing the Runbooks.

Beyond normal sanitation this utility also allows for automated setting of logging parameters (either On or Off).  This means that with a simple flag you can turn off all logging for policies before they are imported into your production environment and, conversely, turning on logging for all Runbooks when they are destined for a QA or Development environment.

This tool is non-destructive.  This means that it is pointed at an export file but does not modify it directly, rather it will create a new export file.

Input Parameters

-ExportFilePath <String> :  Path to the ois_export file to sanitize

-SanitizedExportFilePath <String> : Path to save the sanitized export file to

-ObjectSpecificLogging (On|Off) : Turns On or Off object specific logging for all runbooks in export file

-GenericObjectLogging (On|Off) : Turns On or generic object logging for all runbooks in export file

-DoNotSanitizeGlobals : If specified no manipulations of Globals (configurations, variables, counters etc) will be done

-Force : If set any file at SanitizedExportFilePath will be overwritten


When run without any parameters it will drop a description of how to use it


For normal utilization all you need to supply is the path to the exported file and a path where you want to store the sanitized version of the export file (use the –Force flag to overwrite any files at the destination location)

.\SanitizeExport.exe -ExportFilePath C:\temp\sanitizeTest3.ois_export –SanitizedExportFilePath C:\temp\sanitizeTest3_sanitized.ois_export -Force



The export file was shrunken from 676KB to 25KB so there was about 650 KB worth of useless configuration information in the file (and that was an export from a very clean environment).SNAGHTML48c7dd42



The sanitized import looks like it worked flawlessly, all of the objects maintained their references and all of the referenced global settings and configurations were imported






If you would like to turn logging on or off you can specify either the –ObjectSpecificLogging (On|Off) or the –GenericObjectLogging (On|Off) flag or both.  For Example, if we had wanted to turn off all logging in addition to sanitizing the export file we could specify

.\SanitizeExport.exe -ExportFilePath C:\temp\sanitizeTest3.ois_export –SanitizedExportFilePath C:\temp\sanitizeTest3_sanitized.ois_export –ObjectSpecificLogging Off –GenericObjectLogging Off –Force

Or, to turn both on we could do

.\SanitizeExport.exe -ExportFilePath C:\temp\sanitizeTest3.ois_export –SanitizedExportFilePath C:\temp\sanitizeTest3_sanitized.ois_export –ObjectSpecificLogging On –GenericObjectLogging On –Force


Enjoy and all feedback is appreciated.

Tagged with: , ,
Posted in General Information
4 comments on “Runbook Sanitation Utility
  1. […] Author of the tool is Ryan Andorfer you can find more information about the tool on his blog. […]

  2. Manuel says:

    Hi Ryan,
    another very useful tool from you (yes, I’m the same one who’s currently commenting on your “Parse Orchestrator Export Tool” as well :); found it while I was basically trying to do the same.
    Well, you said “all feedback is appreciated”, so here I go: there are issues with at least two IPs (SCCM 2007, SCOM 2007R2), where global configurations are removed from the export file even when they’re referenced in an activity.

    You probably know most of the following already from your “Parse Orchestrator Export” tool, but just in case, here’s what I have found so far.
    These issues are probably related to the multiple (if not to say “inconsistent”, but I don’t know enough about the inner workings of Orchestrator to justify that) ways configurations can be referenced in the export file.
    For most IPs, it just seems to be a node “Configuration” in the “Object” node.
    Not so for …
    – SCCM 2007 IP, which refers to the activities’ configuration with a “ConnectionName” node.
    – SCOM 2007R2 IP, which refers to the activities’ configuration with a “Connection” node.

    And while most IPs do store their configurations’ settings inside a “Configurations” node for each entry, these two do not (“List” for SCOM, “ServerList” for SCCM).

    As if that wasn’t enough, the SCOM Configuration doesn’t even have a configurable “Name” property, the “Connection” name is generated dynamically by using some of the configuration’s configurable properties (domain name, user name, SCOM server name), concatenating them to “[DOMAIN]:[SERVER]:[ACCOUNT]”. In other words: for SCOM, there won’t be a proper “[Name]Some SCOM Configuration Name[/Name]” node in GlobalConfigurations, but the configuration object based on its GUID would have to examined whether the properties of one of its entries will form a connection name referenced in an exported Activity object (which leaves the problem on how to determine the SCOM configuration(s) without hardcoding GUIDs in the program and limiting it to certain IP releases…).


    • randorfer says:

      Hey Manuel,

      This project is based on an older codebase, I will move it over to reference the orchestrator.administration.dll project (same project that is used to sanitizing using the parse orchestrator export tool). I will also update that project to handle SCOM 2007 and 2012 configuration schemas as you have described above.

      The inconsistences you are pointing out in how configurations are referenced has to do with a difference between ‘native’ and ‘oit’ developed integration packs. Native IPs are kind of the wild west of integration packs, the author gets their own table(s) inside of the database and can pretty much do / configure their IP however they want. OIT (the publically available development toolkit) makes you implement a standardized interface when creating IPs. This causes all of their exports to have a consistent schema. Internally we don’t use any Microsoft Developed integration packs (we develop our own and release them out to This means that we have been buffered from these problems since the Opalis days :-).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: