USMT – Configuring Custom XML files
User State Migration (USMT) is a flexible framework for controlling how user data is managed during machine rebuilds. It uses XML for declaring rules over data is backed up and restored.
Every “component” has a unique display name and when being custom developed by administrators, they will generally consist of “documents” as a data type (just as the following role is likely to be “data” manipulation too.
The actions of the USMT configuration are determined by the rules created against each component. A component will be run according to its context, either once for each user (when context = “user”), once for each system (when the context = “System”) or for every user and system (when the context is set to "UserAndSystem").
Scanstate.exe and Loadstate.exe are the two utilities that interpret common XML. The utilities work respectively in backing up and restoring data so they work by interpreting different parts of the configuration file. The different elements within the rules section of a component determine how Scanstate.exe and Loadstate.exe will react.
The “rules” section within a component define objects (or a set of objects) and the particular types of rules that shall be applied to them. The example above begins by declaring which object are included within the scope of the migration component (in this case the files and folders of the “Common Music” directory). Note that every rule-set must have an statement as the tag defines what’s “in scope” for that particular component and will be relevant to all other rules on both source and destination computers.
Anyway, back to the rules.
The rule-set example previously shown has one additional rule () that will be enacted by Loadstate.exe on the destination machine. This rule is specifically in regard to the desktop.ini file within the “Common Music” directory and states that in case of a merge conflict, the destination file will take priority.
The tag or element (such as or ) determines if the object encased within it will be enacted upon during backup scanning or restore-time loading (or both).
Microsoft has really good documentation into the USMT XML elements at http://technet.microsoft.com/en-us/library/cc749366(v=ws.10).aspx. Apart from compulsory , a further eleven rule types that may be used with the migration of components. These are:
, , , , , , , , , ,
Only five of the first six rule types be commonly used in constructing custom USMT configuration files
Exclude and unconditionally excluding (in the case of a global exclusion file) data from User State backups are simple XML statements that encompass file or registry objects. Exclude rules are coupled to follow the compulsory Include rules to form the core framework of data migration.
When files and registry data has been marked for inclusion with User State Migration, additional rules exist for determining how the captured data will be overlayed on a destination machine. One option that might be considered would be to delete all existing content from the new machine before the new data is migrate across. This somewhat heavy handed approach is the purpose of the “Destination Cleanup” object.
It’s far more likely that the better approach is to merge captured data onto a new machine by specifying if the source or the existing data on the destination computer takes priority in the case of a merge conflict. This is achieved by using the Merge tag with its additional script tag.
HKCU\Software\Microsoft\Office\11.0\Access\Options [Default Database Directory]
%CSIDL_LOCAL_APPDATA%\Microsoft\Windows Live Photo Gallery\* [*]
By default, User State Migration expects to return file and registry data back to the same locations it was originally found. The “Location Modify” rule allows for new locations to be specified during a restore. When testing locationModify rules, be aware that you must capture with the locationModify rule completed. Altering locationModify rules against a previously captured USMT session will always cause the new rules to be ignored and captured files to be written back to their original location!
The locationModify rule must be called with a script of either Move, ExactMove or RelativeMove… all of which are extremely similar. RelativeMove appears to be the most heavily used variant with its two arguments being computed on the different source and destination environments. The “relative” idea of the move is from what is relative to the two machines – not the actual data object. This is especially useful when considering the problems of referencing folders when the source and destination machines are of different architectures etc.