Frequently Asked Questions

General

• How much space is needed on the destination computer?
• Can I store the files and settings directly on the destination computer or do I need a server?
• Can I migrate data between operating systems with different languages?
• Can I change the location of the temporary directory on the destination computer?
• How do I uninstall USMT?

Files and settings

• How can I exclude a folder or a certain type of file from the migration?
• What happens to files that were located on a drive that does not exist on the destination computer?

.xml files

• Where can I get XML examples?
• Can I use existing custom .inf files that were written for USMT 2.6x?
• How can I validate the .xml files?
• Why do I have to include the .xml files on both the ScanState and LoadState command lines?
• Which files can I modify and specify on the command line?
• What happens if I do not specify the .xml files on the command line?

Conflicts and precedence

• What happens when there are conflicting XML rules or conflicting objects on the destination computer?

General

How much space is needed on the destination computer?

The destination computer will need enough available space for the following:

• Operating system
• Applications
• Size of the uncompressed store*
• Twice the size of the largest file that will be migrated*

Note

You will need the last two items listed (*) because when you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer. The files are decompressed (and decrypted if necessary) during this process. Then LoadState transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file.

Can I store the files and settings directly on the destination computer or do I need a server?

No, 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 Universal Serial Bus (USB) drive), or you can store it directly on the destination computer. For example, create and share C:\store on the destination computer. Then run ScanState on the source computer and save the files and settings to \\DestinationComputerName\store. Then, run LoadState on the destination computer and specify C:\store as the store location.

Can I migrate data between operating systems with different languages?

No. USMT does not support migrating data between operating systems with different languages. That is, the operating system of the source computer must match the language of the operating system on the destination computer.

Can I change the location of the temporary directory on the destination computer?

When you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer before saving it to the final location. USMT does not allow you to change this temporary location.

How do I uninstall USMT?

For instructions on how to script an uninstall of USMT, see the Release Notes for USMT 3.0.

Files and settings

How can I exclude a folder or a certain type of file from the migration?

You can use the <unconditionalExclude> elements to globally exclude data from the migration — for example, 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 How To Exclude Files and Settings topic. For the syntax of this element, see the XML Elements Reference.

What happens to files that were located on a drive that does not exist on the destination computer?

USMT will migrate the files to the %SystemDrive%, while maintaining the correct folder hierarchy. For example, if E:\data\File.pst was on the source computer, but the destination computer does not have an E:\ drive, the file will be migrated to C:\data\File.pst where C is the system drive.

Note

If there are <locationModify> rules in the .xml files that specify to migrate the files from a drive that does not exist on the destination computer (but that did exist on the source computer) to a drive that does exist on the destination computer, the files will be migrated correctly.

.xml files

Where can I get XML examples?

See the following topics:

• How To Exclude Files and Settings
• How To Reroute Files and Settings
• How To Include Files and Settings
• XML Examples
• Conflicts and Precedence

Can I use existing custom .inf files that were written for USMT 2.6x?

No, you cannot use .inf files with USMT 3.0. In order to use USMT 3.0, you will need to re-author the migration behavior into the new .xml file format.

How can I validate the .xml files?

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

Why do I have to include the .xml files on both the ScanState and LoadState command lines?

Unlike previous versions of USMT, the .xml files are not copied to the store. Because ScanState and LoadState need the .xml files to control the migration, you will need to specify the same set of .xml files on the ScanState and LoadState command lines. However, you do not have to specify Config.xml 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, simply modify the Config.xml and specify the updated file with LoadState. Then, LoadState will only migrate the files and settings that you want to migrate.

If you leave out an .xml file from LoadState, then all data that was migrated with the missing .xml files (that is in the store) will be migrated. However, the migration rules that were specified on the ScanState command line will not apply. For example, if you leave out MigApp.xml, and it had a rerouting rule like MigsysHelperFunction.RelativeMove(“c:\data”, “%CSIDL_PERSONAL%”), USMT will not reroute the files, and they will be migrated to C:\data.

Which files can I modify and specify on the command line?

• If the destination computer is running Windows XP, you should specify MigUser.xml, MigApp.xml, and MigSys.xml on both command lines. You can modify each of these files if you want to change how the data is migrated. If you want to exclude any components from the migration, you can also create and modify Config.xml.
• If the destination computer is running Windows Vista, you should specify MigUser.xml and MigApp.xml on both command lines. You can modify each of these files. You should not specify MigSys.xml because MigSys.xml is only applicable when the destination computer is running Windows XP. When the destination computer is running Windows Vista, 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), you should create and modify Config.xml.

What happens if I do not specify the .xml files on the command line?

• ScanState. If you specify /targetxp then only user accounts are stored and migrated. If you do not specify /targetxp, then all user accounts and default operating system components are migrated.
• LoadState. If you do not specify any files on the LoadState command line, then all data that is in the store will be migrated. However, any migration rules that were specified in .xml files on the ScanState command line will not apply. For example, if you leave out MigApp.xml, and it had a rerouting rule like MigsysHelperFunction.RelativeMove(“c:\data”, “%CSIDL_PERSONAL%”), USMT will not reroute the files, and they will be migrated to C:\data.

Conflicts and precedence

What happens when there are conflicting XML rules or conflicting objects on the destination computer?

See Conflicts and Precedence for more information.