Michael Niehaus' Windows and Office deployment ramblings
Out of the box, USMT 4.0 migrates settings for Windows, Office, and various other applications (typically current versions as of 2009), mostly consumer-focused. (See http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx for the full list.) So what if you want to migrate settings from additional applications? Well, then you need to author your own migration XML file.
First though, you need to figure out what application settings need to be migrated. Does the application store its settings in a file? In a registry key? Per user or per system? There’s no single right way to do this, so you have to do some investigative work to figure this out for each application. Tools like ProcMon from SysInternals can help with that, by capturing details of all registry and file accesses made by the process. But there can be lots of data captured, so finding the data can be somewhat time-consuming.
So let’s look at a real example using Angry Birds, which is available for download from http://download.angrybirds.com/. Install this on a computer, then start ProcMon and tell it to capture details from process name AngryBirds.exe:
Then launch Angry Birds and click on “Play” to see where you left off – at that point, you know it’s read the saved settings, wherever those came from. At that point, you can stop the capture and begin scanning the captured data. Usually I start at the bottom (most recent) and work my way up, looking for something “interesting”. (What is “interesting” can vary by app, but you will begin to notice patterns that applications follow so the more applications you do this with, the better you’ll get at it.)
From scanning the ProcMon output, I can see a few references to my user profile folder:
Those files (“highscores.lua” and “settings.lua”) sound promising, especially since I noticed that the settings are per user (log in as someone else and you have different progress displayed) and I don’t see any relevant HKCU registry access in the trace.
OK, so we know what we want to capture and restore. Now we have to figure out how. Using your favorite XML editor (I use Visual Studio), create a new XML file that looks like this:
A few things to point out:
So then lets look at the condition:
This uses a helper function to determine if the specified directory exists. The “%CSIDL_APPDATA%” text is a reference to one of the many “environment variables” (listed at http://technet.microsoft.com/en-us/library/dd560744(WS.10).aspx) that can be used; the value will be substituted when evaluating the condition. Because this is a per-user rule, the condition will be checked for each user, with “%CSIDL_APPDATA%” pointing to the user profile’s roaming data folder (e.g. C:\Users\<userID>\AppData\Roaming on Windows 7).
The "include" rule specifies to capture all files and subfolders under the detected path. By default, these will be put back into the same location they were captured from, doing any necessarily translation for changes in %CSIDL_APPDATA% (e.g. drive letter changes).
That’s all there is to it – just tell Scanstate and Loadstate to use this new XML file and all of your Angry Birds progress will be preserved even through an OS refresh or replacement process.
Michael, why not simply migrate "%username%\appData\roaming" en masse? Isn't everything in this folder migrateable, by definition?
Drewfus, I don't think it's a good idea to copy the whole appdata/roaming folder. It's full of unused bits and bytes, and I don't think you have the exact applications on your new deployed OS as before?