Export (0) Print
Expand All

Frequently Asked Questions

Updated: May 31, 2012

Applies To: Windows 7, Windows 8, Windows 8.1

The following sections provide frequently asked questions and recommended solutions for migrations using User State Migration Tool (USMT) 5.0.

The destination computer needs enough available space for the following:

  • Operating system

  • Applications

  • Uncompressed store

You do not need to save the files to a server. If you are moving the user state to a new computer, you can create the store on a shared folder, on media that you can remove, such as a USB flash drive (UFD), or you can store it directly on the destination computer, as in the following steps:

  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 does not 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 this is necessary, for example, when the USMT binaries are located on read-only Windows PE boot media.

Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in your environment. However, the USMT binaries are designed to be deployed using xcopy. This means that they are installed on a computer simply by recursively copying the USMT directory from the computer containing the Windows ADK to each client computer.

If you have installed the Windows ADK on the computer, uninstalling Windows ADK will uninstall USMT. For client computers that do not have the Windows ADK installed, you can simply delete the USMT directory to uninstall USMT.

You can use the <unconditionalExclude> element to globally exclude data from the migration. For example, you can use this element 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 topic. 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, if E:\data\File.pst is on the source computer, but the destination computer does not have an E:\ drive, the file will be migrated to C:\data\File.pst, if C:\ is the system drive. This holds true even when <locationModify> rules attempt to move data to a drive that does not exist on the destination computer.

Yes. You can use custom .xml files that were written for USMT 3.0 with USMT for Windows® 8 . However, in order to use new USMT functionality, you must revisit your custom USMT files and refresh them to include the new command-line options and XML elements.

You can use the USMT XML Schema (MigXML.xsd) to write and validate migration .xml files.

The .xml files are not copied to the store as in previous versions of USMT. Because the ScanState and LoadState tools need the .xml files to control the migration, you must specify the same set of .xml files for the ScanState and LoadState commands. If you used a particular set of mig*.xml files in the ScanState tool, either called through the "/auto" option, or individually through the "/i" option, then you should use same option to call the exact same mig*.xml files in the LoadState tool. However, you do not have to specify the Config.xml file, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, modify the Config.xml file and specify the updated file with the LoadState command. LoadState will migrate only the files and settings that you want to migrate.

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

You can specify the MigUser.xml and MigApp.xml files on the command line. You can modify each of these files. The migration of operating system settings is controlled by the manifests, which you cannot modify. If you want to exclude certain operating-system settings or any other components, create and modify the Config.xml file.

  • ScanState

    If you do not specify any files with the ScanState command, all user accounts and default operating system components are migrated.

  • LoadState

    If you do not specify any files with the LoadState 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 command will not apply. For example, if you exclude a MigApp.xml file that has a rerouting rule such as MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%"), USMT will not reroute the files. Instead, it will migrate them to C:\data.

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft