Migrating User State using USMT 4.0

Transitioning user data from users' previous computer to the new computer has always been a daunting task for the IT support professionals. Users feel less intimidated by a new operating system if all their old operating system preferences are in effect the moment they first logon. With the release of Windows®  7, most of the businesses today are looking at upgrading their older Windows®  OS to Windows®  7.

Windows®  7 is more versatile than Windows® XP and builds on the revolutionary architecture introduced with Windows® Vista. Windows® 7 and Windows® Server 2008 R2 share the same kernel image. This is the first time that the Server and the Client OS have sim shipped on the same bits since Windows®  2000. The most significant architectural changes in Windows 7 are listed as below:

  • Preinstallation and Preboot Environment

  • Modularization and File based Disk Imaging

  • Multitiered Data Protection and UAC with elevation of privilege

These architectural improvements have motivated many organizations to switch to Windows®  7. However, it is important to migrate the User State on the new OS considering its business impact since most of the users store critical data in their profiles (e.g. My Documents, Desktop etc). To facilitate IT Helpdesk engineers perform easier and smooth user state migration, Microsoft introduced tools like the Windows Easy Transfer (WET) and the User State Migration Toolkit (USMT).

WET is a GUI utility that comes out of the box with Windows 7 to transfer user profile data from computers running n - 1 ( Windows®  Vista) or n -2 (Windows XP) to new computers running Windows®  7. It can be used to transfer user accounts, music, pictures, e-mails, certificates, documents etc. WET is the recommended tool for scenarios in which you have a small number of computers to migrate. It does justice to the needs of Home Users. However, for enterprises that require a standard configuration for all client operating systems and require automation to deploy the OS to hundreds and thousands of computers, WET is not a good option. This is where, the command line flexibility of USMT comes into picture.

USMT 4.0 is packaged with other deployment tools like ImageX, Windows® System Image Manager (Windows SIM) and Deployment Image Servicing and Management (DISM) in a single International Organization for Standardization (ISO) format named as the Windows Automated Installation Kit or the WAIK tool. You can download the WAIK tool for Windows 7 (which also supports deploying Windows Server 2008 R2) from the Microsoft Download Center. Remember, Bing is your friend 🙂

The following list shows the USMT components:

ScanState: scans the source computer, collects the files and settings, and then creates a store. ScanState does not modify the source computer. By default, it compresses the files and stores them as a migration store. ScanState copies files into a temporary location and then to the migration store.

LoadState: migrates the files and settings, one at a time, from the store to a temporary location on the destination computer. The files are decompressed, and decrypted if necessary, during this process. LoadState then transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file. Compression improves performance by reducing network bandwidth usage and the required space in the store. You can choose to turn off compression with the /nocompress option.

Migration .xml files: the .xml files used by USMT for migrations are MigApp.xml, MigUser.xml, or MigDocs.xml and any custom .xml files that you create.

Config.xml: to exclude components from the migration, you can create and modify the Config.xml file by using the /genconfig option with the ScanState tool. This optional file has a different format from the migration .xml files because it does not contain migration rules. The Config.xml file lists the components that can be migrated. You specify migrate = No for the components that you want to exclude from the migration. In addition, this file can be used to control some migration options new to USMT 4.0.

Component Manifests for Windows Vista and Windows 7: if the source or destination computer is running Windows Vista or Windows 7, the component-manifest files control which operating system settings are migrated and how they are migrated. These files are located on computers that are running Windows Vista and Windows 7, and you cannot modify them. If you want to exclude certain operating system settings when the source computer is running Windows Vista or Windows 7, you need to create and modify a Config.xml file.

Down-level Manifest files: if the source computer is running a supported version of Windows XP, these manifest files control which operating-system and Internet Explorer settings are migrated and how they are migrated. For example, when the destination computer is running Windows 7, the ScanState tool collects the data by using the down-level manifest files, and then the LoadState tool migrates the data by using the corresponding component manifest files for Windows 7.

The down-level manifest files are not used with the LoadState tool. The down-level manifest files are located in the USMT\Dlmanifests directory. You cannot modify these files. To exclude certain operating-system settings when the source computer is running Windows XP and the destination computer is running Windows 7, you will need to create and modify a Config.xml file on the Windows XP computer.

USMT internal files: all other .dll, .xml, .dat, .mui, and .inf files included with USMT are for internal use. You cannot modify these files.

USMT 4.0 introduces the following new features:

  • Hard-link migration store: USMT 4.0 introduces hard-link migration store for use in refresh computer scenario. Hard-link migration stores are stored locally on the computer that is being refreshed. It can be used to migrate user settings and data in less time and requires less storage space. The idea here is to create an additional reference (link) to the same file and then build a catalog of those links. Storing links consumes less disk footprint than the duplicating those files on a remote share or on a USB flash drive. Hardlink Migration can only be used in the Computer Refresh scenario (the new OS is installed on the same volume as that of the old OS and the same hardware is used). This is because of the restriction that hardlink can only exist on the same volume. If you use the hardlink switch for the scanstate command and provide the path to the migration store located on some other volume, network share or an external drive, scanstate will duplicate the files instead of creating hardlinks. The size of the migration store will be almost equal to the total size of the user profile. You can estimate the size of the Migration Store using the /p switch available with the scanstate utility. To check for individual profile size, you can type systempropertiesadvanced.exe in Search Programs and Files in Start Menu and click Settings under User Profiles pane. Note that you have to mandatorily use the /nocompress switch with the hardlink switch. By default if none of the switches are provided, scanstate will compress the migration store in an attempt to reduce space. A compressed migration store cannot be browsed using Windows Explorer. Microsoft Deployment Toolkit 2010 leverages Hard-Link Migration feature of the USMT via WMI scripts and creates a migration store called MININT under %systemdrive% which indexes the hardlinks.


scanstate C:\Store1 /c /o /all /hardlink /nocompress /i:MigUser.xml /i:MigApp.xml

  • Offline migration: USMT 4.0 enables you to collect data from an offline Windows operating system using the ScanState command in Windows® PE. In addition, USMT 4.0 supports migrations from previous installations of Windows contained in Windows.old directories. The offline directory can be a Windows directory when you run the ScanState command in Windows PE or to Windows.old when you run the ScanState command in Windows.


scanstate C:\OfflineStore /c /all /offlinewindir:C:\Windows /i:Miguser.xml  (within Windows PE)

Process to migrate user state data using USMT 4.0

Collect Files and Settings from the Source Computer

·         Close all applications

·         Run ScanState command


Prepare the Destination Computer:

·         Install the operating system

·         Install all applications


Restore Files and Settings on the Destination Computer

·         Run the LoadState command

·         Log off

Note: ScanState can be run on n-2 versions and within Windows PE (Preinstallation Environment) while LoadState can only be run on n-1 versions and is not supported within Windows PE.

USMT is available for both platforms; 32 Bit (x86) and 64 Bit (amd64).

Please do take a look at the video below on Technet Edge by Dan Stolts (renowned IT Pro Evangelist) that demonstrates the power of USMT.


If you are interested in attending an instructor led training on Windows Deployment, do consider the Microsoft Official Curriculum Course 6294A: Planning and Managing Windows 7 Desktop Deployments and Environments.

Course 6294A Details

Comments (0)

Skip to main content