USMT best practices
This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0.
General best practices
Install applications before running the LoadState tool
Though it isn't always essential, it's best practice to install all applications on the destination computer before restoring the user state. Installing applications before restoring user state helps ensure that migrated settings are preserved.
Don't use MigUser.xml and MigDocs.xml together
If you use both .xml files, some migrated files may be duplicated if conflicting instructions are given about target locations. You can use the
/genmigxmlcommand-line option to determine which files will be included in your migration, and to determine if any modifications are necessary. For more information, see Identify file types, files, and folders.
Use MigDocs.xml for a better migration experience
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the
MigDocs.xmlfile is a better choice than the
MigUser.xmlfile, because the
MigDocs.xmlfile will gather a broader scope of data. The
MigDocs.xmlfile migrates folders of data based on location, and on registered file type by querying the registry for registered application extensions. The
MigUser.xmlfile migrates only the files with the specified file extensions.
Close all applications before running either the ScanState or LoadState tools
Although using the
/vscswitch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the
/cswitch USMT will fail when it can't migrate a file or setting. When you use the
/coption, USMT will ignore any files or settings that it can't migrate and log an error each time.
Log off after you run the LoadState
Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, you should sign out after you run the LoadState tool.
To create a managed environment, you can move all of the end user's documents into My Documents (%CSIDL_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders will help you to clean up files on the destination computer, if the
LoadState.execommand fails before completion.
We recommend that you run Chkdsk.exe before running the ScanState and LoadState tools. Chkdsk.exe creates a status report for a hard disk drive and lists and corrects common errors. For more information about the Chkdsk.exe tool, see Chkdsk.
Migrate in groups
If you decide to perform the migration while users are using the network, it's best to migrate user accounts in groups. To minimize the impact on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups.
Security best practices
As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues:
Encrypting File System (EFS)
Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see Migrate EFS Files and Certificates.
If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.
Encrypt the store
Consider using the
/encryptoption with the
ScanState.execommand and the
/decryptoption with the
LoadState.execommand. However, use extreme caution with this set of options, because anyone who has access to the
ScanState.execommand-line script also has access to the encryption key.
We recommend that you scan both the source and destination computers for viruses before running USMT. In addition, you should scan the destination computer image. To help protect data from viruses, we strongly recommend running an antivirus utility before migration.
Maintain security of the file server and the deployment server
We recommend that you manage the security of the file and deployment servers. It's important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files isn't exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see Microsoft Security Compliance Manager.
To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications such as Windows Live™ Mail, Microsoft Internet Explorer®, and Remote Access Service (RAS) connections and mapped network drives. It's important to make sure that end users know their passwords.
Local Account Creation
Before you migrate local accounts, see the Migrating Local Accounts section in the Identify Users article.
XML file best practices
Specify the same set of mig*.xml files in both the ScanState and the LoadState tools
If you used a particular set of mig*.xml files in the ScanState tool, either called through the
/autooption, or individually through the
/ioption, then you should use same option to call the exact same mig*.xml files in the LoadState tool.
The <CustomFileName> in the migration urlid should match the name of the file
Although it isn't a requirement, it's good practice for <CustomFileName> to match the name of the file. For example, the following example is from the
<?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">
Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax
MigXML.xsdschema file shouldn't be included on the command line or in any of the .xml files.
Use the default migration XML files as models
To create a custom .xml file, you can use the migration .xml files as models to create your own. If you need to migrate user data files, model your custom .xml file on
MigUser.xml. To migrate application settings, model your custom .xml file on the
Consider the impact on performance when using the <context> parameter
Your migration performance can be affected when you use the <context> element with the <component> element; for example, as in when you want to encapsulate logical units of file- or path-based <include> and <exclude> rules.
In the User context, a rule is processed one time for each user on the system.
In the System context, a rule is processed one time for the system.
In the UserAndSystem context, a rule is processed one time for each user on the system and one time for the system.
The number of times a rule is processed does not affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files
For example, if you have code that migrates the settings for an application, you shouldn't just add the code to the
You should not create custom .xml files to alter the operating system settings that are migrated
These settings are migrated by manifests and you can't modify those files. If you want to exclude certain operating system settings from the migration, you should create and modify a
You can use the asterisk (*) wildcard character in any migration XML file that you create
The question mark is not valid as a wildcard character in USMT .xml files.