How USMT Works
Applies To: Windows 7, Windows 8, Windows 8.1, Windows Vista
USMT includes two tools that migrate settings and data: ScanState and LoadState. ScanState collects information from the source computer, and LoadState applies that information to the destination computer.
The ScanState Process
The LoadState Process
Note
For more information about how USMT processes the rules and the XML files, see Conflicts and Precedence.
The ScanState Process
When you run the ScanState tool on the source computer, it goes through the following process:
It parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
It collects information about all of the migration components that need to be migrated. A migration component is a logical group of files, registry keys, and values. For example, the set of files, registry keys, and values that store the settings of Adobe Acrobat is grouped into a single migration component.
There are three types of components:
Components that migrate the operating system settings
Components that migrate application settings
Components that migrate users’ files
The ScanState tool collects information about the application settings and user data components from the .xml files that are specified on the command line.
In Windows Vista®, Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
ScanState determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, which is the "All users" profile in a source computer running Windows® XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated, and you cannot exclude these profiles from the migration.
In the "Scanning" phase, ScanState does the following for each user profile selected for migration:
For each component, ScanState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
Note
From this point on, ScanState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. ScanState processes all components in the same way.
Each component that is selected in the previous step is processed further. Any profile-specific variables (such as CSIDL_PERSONAL) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to “User1”, then CSIDL_PERSONAL would expand to C:\Users\User1\Documents, assuming that the user profiles are stored in the C:\Users directory.
For each selected component, ScanState evaluates the <detects> section. If the condition in the <detects> section evaluates to false, the component is not processed any further. Otherwise, the processing of this component continues.
For each selected component, ScanState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
ScanState creates a list of migration units that need to be migrated by processing the various subsections under this <rules> section. Each unit is collected if it is mentioned in an <include> subsection, as long as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence in the .xml files, see Conflicts and Precedence.
In addition, any migration unit (such as a file, registry key, or set of registry values) that is in an <UnconditionalExclude> section is not migrated.
Note
ScanState ignores some subsections such as <destinationCleanup> and <locationModify>. These sections are evaluated only on the destination computer.
In the "Collecting" phase, ScanState creates a master list of the migration units by combining the lists that were created for each selected user profile.
In the "Saving" phase, ScanState writes the migration units that were collected to the store location.
Note
ScanState does not modify the source computer in any way.
The LoadState Process
The LoadState process is very similar to the ScanState process. The ScanState tool collects migration units such as file, registry key, or registry values from the source computer and saves them to the store. Similarly, the LoadState tool collects migration units from the store and applies them to the destination computer.
ScanState parses and validates the command-line parameters, creates the ScanState.log file, and then begins logging.
LoadState collects information about the migration components that need to be migrated.
LoadState obtains information for the application-settings components and user-data components from the migration .xml files that are specified by the LoadState command.
In Windows Vista, Windows 7, and Windows 8, the manifest files control how the operating-system settings are migrated. You cannot modify these files. If you want to exclude certain operating-system settings, you must create and modify a Config.xml file.
LoadState determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the User Options. The system profile, the "All users" profile in a source computer running Windows XP, or the Public profile in a source computer running Windows Vista, Windows 7, and Windows 8, is always migrated and you cannot exclude these profiles from the migration.
If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must use the /lac command-line option. If you do not specify the /lac option, any local user accounts that are not already present on the destination computer, are not migrated.
The /md and /mu options are processed to rename the user profile on the destination computer, if they have been included when the LoadState command was specified.
For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, it attempts to apply the settings to a local account. For more information, see Identify Users.
In the "Scanning" phase, LoadState does the following for each user profile:
For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.
Note
From this point on, LoadState does not distinguish between components that migrate operating-system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.
Each component that is selected is processed further. Any profile-specific variables (such as CSIDL_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL_PERSONAL would expand to C:\Users\User1\Documents (assuming that the user profiles are stored in the C:\Users directory).
Note
LoadState ignores the <detects> section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.
For each selected component, LoadState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is not the system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.
LoadState creates a master list of migration units by processing the various subsections under the <rules> section. Each migration unit that is in an <include> subsection is migrated as long, as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence, see Conflicts and Precedence.
LoadState evaluates the destination computer-specific subsections; for example, the <destinationCleanup> and <locationModify> subsections.
If the destination computer is running Windows Vista or Windows 7, then the migunits that were collected by ScanState using downlevel manifest files are processed by LoadState using the corresponding Component Manifest for Windows 7. The downlevel manifest files are not used during LoadState.
Important
It is important to specify the .xml files with the LoadState command if you want LoadState to use them. Otherwise, any destination-specific rules, such as <locationModify>, in these .xml files are ignored, even if the same .xml files were provided when the ScanState command ran.
In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a <merge> rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, do not take effect until the next time the user logs on. For this reason, you should log off when the LoadState command actions have completed.