Frequently Asked Questions

The destination computer needs enough available space for the following items:

• Operating system

• Applications

• Uncompressed store

Files don't need to be saved to a server. If moving the user state to a new computer, the store can be created on:

• A shared folder.
• On removable media, such as a USB flash drive (UFD).
• Directly on the destination computer.

To store it directly on the destination computer:

1. Create and share the directory C:\store on the destination computer.

2. Run the ScanState tool on the source computer and save the files and settings to \\<DestinationComputerName>\store

3. Run the LoadState tool on the destination computer and specify C:\store as the store location.

No. USMT doesn't support migrating data between operating systems with different languages; the source computer's operating-system language must match the destination computer's operating-system language.

Yes. The environment variable USMT\_WORKING\_DIR can be changed to an alternative temporary directory. There are some offline migration scenarios where changing the temporary directory is necessary, for example, when the USMT binaries are located on read-only Windows Preinstallation Environment (WinPE) boot media.

Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), the Windows ADK package needs to be installed on at least one computer in the environment. The USMT binaries can then be copied from the USMT directory located on the original computer where the Windows ADK was installed to additional client computers.

For computers that have the Windows ADK installed, uninstalling the Windows ADK from the computer uninstalls USMT. For client computers that don't have the Windows ADK installed, the USMT directory can be deleted to uninstall USMT.

The <unconditionalExclude> element can be used to globally exclude data from the migration. For example, this element can be used to exclude all MP3 files on the computer or to exclude all files from C:\UserData. This element excludes objects regardless of any other <include> rules that are in the .xml files. For an example, see <unconditionalExclude> in the Exclude files and settings article. For the syntax of this element, see XML elements library.

USMT migrates the files to the %SystemDrive% while maintaining the correct folder hierarchy. For example:

• E:\data\File.pst is on the source computer.
• Destination computer doesn't have an E:\ drive.
• C:\ is the system drive on the destination computer.

the file is migrated to C:\data\File.pst. This behavior holds true even when <locationModify> rules attempt to move data to a drive that doesn't exist on the destination computer.

The following articles include examples of USMT .xml files:

• Exclude files and settings

• Reroute files and settings

• Include files and settings

• Custom XML examples

Yes. Custom .xml files that were written for USMT 5.0 can be used with newer versions of USMT. However, in order to use new USMT functionality, the custom USMT files must be revisited and refreshed to include the new command-line options and XML elements.

The USMT XML Schema (MigXML.xsd) can be used to write and validate migration .xml files.

The .xml files aren't copied to the store as in previous versions of USMT. Because the ScanState and LoadState tools need the .xml files to control the migration, the same set of .xml files must be specified for the ScanState.exe and LoadState.exe commands. If a particular set of mig*.xml files were used in the ScanState tool, either called through the /auto option, or individually through the /i option, then the same option should be used to call the exact same mig*.xml files in the LoadState tool. However, the Config.xml file doesn't need to be specified, unless files and settings that were migrated to the store need to be excluded. For example, the Documents folder might be migrated to the store, but not to the destination computer. To do this type of migration, modify the Config.xml file and specify the updated file with the LoadState.exe command. LoadState migrates only the desired files and settings.

If an .xml file is excluded from the LoadState.exe command, then all of the data in the store that was migrated with the missing .xml files are migrated. However, the migration rules that were specified for the ScanState.exe command don't apply. For example, if a MigApp.xml file that has a rerouting rule such as MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%") is excluded, USMT doesn't reroute the files. Instead, it migrates them to C:\data.

The MigUser.xml, MigApp.xml, and MigDocs.xml files can be specified on the command line. Each of these files can be modified. Manifests control the migration of operating system settings. Manifests can't be modified. To exclude certain operating-system settings or any other components, create and modify the Config.xml file.

• ScanState

  If no files are specified with the ScanState.exe command, all user accounts and default operating system components are migrated.

• LoadState

  If no files are specified with the LoadState.exe command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in .xml files with the ScanState.exe command doesn't apply. For example, if a MigApp.xml file that has a rerouting rule such as MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%") is excluded, USMT doesn't reroute the files. Instead, it migrates them to C:\data.

For more information, see Conflicts and precedence.

Related topics

• User State Migration Tool (USMT) Troubleshooting.
• Extract files from a compressed USMT migration store.
• Verify the condition of a compressed migration store.