Skip to main content

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.

image

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

image

image

 

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.

much better

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.

woah, help me!

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. :)

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m