Migrating application settings with USMT 4.0: Sample #2
So maybe migrating Angry Birds high scores and settings isn’t terribly useful to you. Let’s try something a little more practical and self-serving. Many of you are using Configuration Manager 2007 or testing Configuration Manager 2012. As part of that, you have installed the ConfigMgr console and connected to one or more ConfigMgr sites. When you refresh your own machine, you want those connections to be retained, because it’s too much trouble to have to type in a server name again.
So it’s the same basic exercise as before: Figure out where the ConfigMgr console stores that information (using ProcMon or even Bing searches), then build an XML manifest that says to migrate the data. Fortunately, I already know where ConfigMgr stores that (we use that information in MDT): it’s in the user’s registry. The exact path is different for ConfigMgr 2007 vs. 2012:
ConfigMgr 2012: HKCU\Software\Microsoft\ConfigMgr10\Admin UI\MRU
ConfigMgr 2007: HKCU\Software\Microsoft\ConfigMgr\AdminUI\MRU
So the manifest needs to specify that these registry keys (and all values and subkeys) get backed up and restored if they exist. Simple enough:
A few things to point out with this one:
- There are two components defined in the same XML manifest. You can put as many components in the file as you want, so whether you want 20 small XML files or one larger one (as you define more application settings to capture) is entirely up to you.
- Since these are user registry entries, the rules will be processed for each user that exists on the machine.
So what happens if the ConfigMgr 2007 console is installed in the old OS but not in the new OS? Will the settings be restored? Yes they will, as the detection rules are only used to determine on the source computer whether the component is present. (When it is detected, it will be put into a generated config.xml file too.)