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.

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.

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.

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.

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

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.

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.

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
  

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.

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

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.

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

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

See Conflicts and Precedence for more information.