Edit

Share via

Test the migration

Always test the migration plan in a controlled laboratory setting before deploying it to the entire organization. In the test environment, at least one computer is needed for each type of operating system from which data is being migrated.

Once the entire migration process is tested on a single computer running each of the organization source operating systems, conduct a pilot migration with a small group of users. After migrating a few typical user states to the intermediate store, note the space required and adjust the initial calculations accordingly. For details about estimating the space needed for the migration, see Estimate migration store size. Registry-setting and file-location information might need to be adjusted in the migration-rule files. If changes are made, test the migration again and verify that all data and settings migrated as expected. A pilot migration also gives the opportunity to test the space estimates for the intermediate store.

If the test migration encounters any errors, examine the ScanState and LoadState logs to obtain the exact User State Migration Tool (USMT) return code and associated error messages or Windows application programming interface (API) error message. For more information about USMT return codes and error messages, see Return codes. More information can be obtained about any listed Windows system error codes by typing in the following at a command prompt window:

net.exe helpmsg <error_number>

where <error_number> is the error code number generated by the error message. For more information about System Error Codes, see System Error Codes (0-499).

In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. Microsoft recommends using the /v:5 option when testing the migration. This verbosity level can be adjusted in a production migration. Reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations. Higher verbosity levels can be used if the log files need to output to go to a debugger.

Note

Running the ScanState and LoadState tools with the /v:5 option creates a detailed log file. Although this option makes the log file large, it's helpful in determining where migration errors occurred.

After the pilot migration is verified that it successfully migrated the specified files and settings, USMT is ready to be used in the environment to migrate data. For example, using USMT with Microsoft Configuration Manager. For more information, see [Manage user state in Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).

Note

For testing purposes, an uncompressed store using the /hardlink /nocompress option can be created. When compression is disabled, the ScanState tool saves the files and settings to a hidden folder named File at <StorePath>\USMT. The uncompressed store can be used to view what USMT stored or to troubleshoot a problem. An antivirus utility can also be run against the files. Additionally, the following items can be used to troubleshoot problems with the migration:

  • The /listfiles command-line option.
  • The diagnostic log that lists the files that were gathered.