Share via

USMT Internal Workflow

  • Article
  • ScanState process
  • LoadState process

Note

For more information about how USMT processes the rules and the .xml files, see Conflicts and Precedence.

ScanState process

When you run ScanState on the source computer, ScanState goes through the following process:

  1. First, ScanState parses and validates the command-line parameters. Then, ScanState creates the ScanState.log file and begins logging.
  2. ScanState collects information about all 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, and registry keys and values that store the settings of Adobe Acrobat are grouped into a single migration component.
    There are three types of components: those that migrate the operating system settings, those that migrate application settings, and those that migrate users’ files. ScanState collects information about the application settings and user data components from the .xml files that are specified on the command line. The operating system settings are collected based on the following:
    • If the operating system on the destination computer is Windows XP, you must specify /i:MigSys.xml on both ScanState and LoadState command lines in order for any operating system settings to migrate. In addition, you should specify /targetXP with ScanState to indicate to ScanState that the operating system on the destination computer is Windows XP.
    • If the operating system on the destination computer is Windows Vista, the manifests control how the operating system settings are migrated. You cannot modify these files. In this case, if you want to exclude certain operating system settings, you will need to create and modify a Config.xml file.
  3. ScanState then determines which user profiles should be migrated. By default, all user profiles on the source computer will be migrated. However, you can include and exclude users using the User Options. The system profile (the "All users" profile (in Windows XP) or the Public profile (in Windows Vista) is always migrated. That is, you cannot exclude these profiles from the migration.
  4. In the "Scanning" phase, ScanState does the following for each user profile selected for migration:
    1. 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”, then 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 onwards, 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.

2.  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).  
3.  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.  
4.  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 the *not* system profile and the context of the \<rules\> section is “User” or “UserAndSystem”, then the rule is processed further. Otherwise, this rule is ignored.  
5.  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](cc749023\(v=ws.10\).md).  
    In addition, any migration unit (file, registry key or registry values) that is in a \<UnconditionalExclude\> section will not be migrated.

Note

ScanState ignores some subsections like <destinationCleanup> and <locationModify>. These sections are only evaluated on the destination computer.

  1. 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.
  2. In the "Saving" phase, ScanState writes the migration units that were collected to the store location.

Note

ScanState does not modify or change the source computer in any way — that is, the source computer will not be changed by running ScanState.

LoadState process

The LoadState process is very similar to that of ScanState. ScanState collects migration units (file, registry key, or registry values) from the source computer and saves them to the store. Similarly, LoadState collects migration units from the store, and applies them to the destination computer.

  1. First, LoadState parses and validates the command-line parameters. Then, LoadState creates the LoadState.log file and begins logging.
  2. LoadState collects information about 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, and registry keys and values that store the settings of Adobe Acrobat are grouped into a single migration component.
    LoadState obtains information for the application settings components and user data components from the migration .xml files that are specified on the LoadState command line. The operating system settings are obtained by one of the following:
    • If the operating system on the destination computer is Windows XP, you must specify /i:MigSys.xml on both ScanState and LoadState command lines in order for any operating system settings to migrate. This is because these tools obtain the components that specify the operating system settings from MigSys.xml.
    • If the operating system on the destination computer isWindows Vista, the manifests control how the operating system settings are migrated. You cannot modify these files. In this case, if you want to exclude certain operating system settings, you will need to create and modify a Config.xml file.
  3. LoadState then determines which user profiles should be migrated. By default, all user profiles present on the source computer will be migrated. However, you can include and exclude users using the User Options. The system profile (the "All users" profile (in Windows XP) or the Public profile (in Windows Vista)) is always migrated. That is, 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 specify /lac. If /lac is not specified, any local user accounts that are not already present on the destination computer, will not be migrated.
    • If specified, the /md and /mu options are processed to rename the user profile on the destination computer.
    • 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, USMT will attempt to apply the settings to a local account. For more information, see Identify Users.
  4. In the "Scanning" phase, LoadState does the following for each user profile:
    1. 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 onwards, 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.

2.  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.

3.  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 the not system profile and the context of the \<rules\> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.  
4.  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 in the .xml files, see [Conflicts and Precedence](cc749023\(v=ws.10\).md).  
    In addition, any migration units (file, registry key or registry values) that are in a \<UnconditionalExclude\> section will not be migrated.  
5.  LoadState evaluates the destination computer specific subsections (for example \<destinationCleanup\> and \<locationModify\>).  
6.  If the destination computer is Windows Vista, then the migration units that were collected by ScanState using [Downlevel Manifests](cc721992\(v=ws.10\).md) are processed by LoadState using the corresponding [Component Manifest for Windows Vista](cc721992\(v=ws.10\).md). The [Downlevel Manifests](cc721992\(v=ws.10\).md) are not used during LoadState.

Important

It is important to provide the .xml files on the LoadState command line that you want LoadState to consider and use. Otherwise, any destination specific rules (such as <locationModify>) in these .xml files will be ignored, even if the same .xml files were provided during ScanState.

  1. 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 (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs on. For this reason, you should log off after you run LoadState.