orchestrator: overwriting existing global configurations

if you're familiar with importing and exporting runbooks, you have most likely seen the unintrusive little checkbox under the export settings labeled "export global configurations" and under the import settings labeled "import global configurations". how about "overwrite existing global configurations"? any idea what that does?

resorting to the help file, it explains the overwrite option as:

Select Overwrite existing global configurations to replace any current settings with the settings in the imported runbook or runbooks.

Overwriting replaces the entire set of configurations for a particular group. For example, if an imported runbook contains an SNMP activity, any current SNMP settings will be overwritten and any currently configured SNMP activities will be deleted.

all this did was provide more confusion for me so i tested a few things to see exactly what i was dealing with. when you export the ois_export file, it's actually exported as xml. cool. let's see what's inside it… but first, some basic information.

 

reviewing the sample runbook

here is my simple runbook i tested. as you can see, it has three activities and only one that points to an actual configuration – scale tier in. this will keep things simple. it doesn’t provide any useful functionality, if you were wondering.

i created a configuration under virtual machine manager for the scale tier in activity to use called “imextest” (import-export-test… yeah, original).

 

stepping through the test

okay, now that our little lab test is configured, let’s run a couple of scenarios. here are the steps i used when importing the global configuration with and without the runbook:

1. export the test runbook folder with all options disabled other than “export global configurations”. cleverly, i called mine myGlobalConfig.
2. go to options / sc 2012 virtual machine manager in runbook designer.
3. edit “imextest” changing the following:
• name from “imextest” to “imextest-modified”
• vmm administrator console from “idk” to “iono”
4. modify the scale tier in activity:
• point configuration from “imextest” to “imextest-modified”
• change service name from “x” to “x-modified”
5. check in the modified runbook.
6. import the exported runbook with all options disabled other than “import global configurations” and “overwrite existing global configurations”.
7. examine the results.

for the second test, i wanted to see what happens if i import the runbook as well as the global configurations.

1. import the exported runbook with the same steps as step 6 but choose “import runbooks” as well.
2. examine the results.

and lastly, i wanted to see the outcome of modifying a configuration outside of those used by any activities in the runbook.

1. modify another configuration, such as sc 2012 configuration manager.
2. i added a new configuration entry to mine.
3. import the exported runbook with the same settings as step 6.
4. examine the results.

note: make sure you do not import a runbook at the same level you exported it. otherwise, you’ll create a new one under the same folder. instead, import the runbook from the root or the level above where you exported it. make sense?

 

looking at the results

for the first test, i imported just the global configurations. as expected, the sc 2012 virtual machine manager settings i had for imextest-modified reverted back to imextest. the activity, scale tier in, remained untouched. it still pointed to the imextest-modified configuration.

after the second test where i imported the runbook, the activity, scale tier in, is modified to point to the previous configuration. the third test, showed that even global configurations outside of what would appear to be the scope of the runbook are modified.

 

examining the xml to back up the results

the nice thing about these exported runbooks are that they’re actually xml files. in other words, you can open it up and see exactly what you just exported. there are two ways of going about doing this. you can either open it up in your text or xml editor of choice (horrible idea), or you can try using ryan andorfer’s utility parseorchestratorexport.exe.

if you insist on searching the xml, look under the exportdata / policies / globalconfigurations section. i found a faster way to identify areas with content is to search for the <configurations> node.

sorry for the side track. as you can see, the global configurations contain more than just what is related or relevant to the runbook exported – thus global. the only configuration tied to the activities in the runbook should have been “sc 2012 virtual machine manager”. instead, it picked up sc 2012 configuration manager and microsoft active directory domain configuration.

 

okay, so now what?

the bottom line is be careful. if you import global configurations with your runbook, you run the very high probability that you will overwrite something you hadn’t intended to.

when exporting global configurations, you get them all. it doesn’t matter what node you’re at. it doesn’t matter which runbook you export. if you choose this option, there isn’t a choice in which ones you get. now, that said, you can edit the exported xml  to remove the entry node that you do not want to import.

importing global configurations without overwriting does nothing for the existing configurations. if the configuration objects exist on the management server, they will not be modified. don’t exactly know what would happen if you imported a global configuration for a configuration that doesn’t yet exist. if you know the answer or try this, let me know what you find out in the comments.

importing global configurations with overwrite replaces everything you had with values from the exported runbook. let’s say you export global configurations. at some point in time after, global configurations are modified. you go to import what you exported with overwrite turned on. all of your changes are wiped out.

the context of the help file is not accurate and at best misleading/confusing. let’s break down why:

• Select Overwrite existing global configurations to replace any current settings with the settings in the imported runbook or runbooks – it doesn’t matter if you import one runbook or the whole tree. you get all of the global configurations.
• Overwriting replaces the entire set of configurations for a particular group – what exactly is a group? i don’t know. I find importing global configurations replaces everything for that orchestrator management server.
• For example, if an imported runbook contains an SNMP activity, any current SNMP settings will be overwritten and any currently configured SNMP activities will be deleted – yes, this is true if you import a runbook. however, you can import a runbook without global configurations. you can also import global configurations without the runbook itself. in either case, if the activity or configuration is out of sync, then you will potentially have an activity point to an incorrect configuration.

 

drop a comment, and let me know what you think. :)