What is the User State Migration Tool?
To get started, here is the first paragraph from the USMT help content on TechNet:
You can use Microsoft® Windows® User State Migration Tool (USMT) 3.0 to migrate user files and settings during large deployments of Microsoft Windows XP and Microsoft Windows Vista™ operating systems. USMT captures desktop, and application settings, as well as user accounts and users' files, and then migrates them to a new Windows installation. Using USMT can help you improve and simplify your migration process. You can use USMT for both side-by-side and wipe-and-load migrations. If you are only upgrading your operating system, USMT is not needed.
So, bottom line, USMT captures and restores a users files and settings (user state) so that the migration to a newer version of Windows (or simply a newly installed copy of the same version) is as seamless as possible for the end user.
However, you may be asking:
- How do I run USMT?
- What files does USMT migrate?
- What user accounts does USMT migrate?
- What operating system settings does USMT migrate?
- What application settings does USMT migrate?
- How does USMT store user state?
- When should I use USMT?
Lets work through these one at a time.
How do I run USMT? Well, USMT is a command line tool, so it is typically run by opening up a command prompt and entering the desired commands. However, USMT is broken into two different executables so it is necessary to run the proper executable for the proper job. Scanstate.exe is run on the old Windows install to capture user state and Loadstate.exe is run on the new Windows install to restore user state. Check out this link for more detail. (note, the process of running USMT is typically scripted such that it isn't necessary to type the full command line into every computer you run USMT on)
What user accounts does USMT migrate? By default Scanstate will gather every user account from the source computer and Loadstate will restore every user account to the destination computer. However, like everything else, this can be customized. Scanstate and Loadstate have a number of command line options that allow you to select which users accounts should migrate. For more info on how to configure the user accounts that Scanstate migrates, check here (click on the user options link at the top of the page).
What files does USMT migrate? Well, this depends on how USMT is configured. USMT is designed to consume XML files that tell it what to do; so through development of custom files USMT can be configured to migrate any file. However, USMT does ship with the MigUser.XML file that defines how all user profile data (files under "C:\Users" on a typical Vista install and "C:\Documents and Settings" on a typical XP install). Additionally, MigUser.XML instructs Scanstate to search the entire computer for files with common extensions. For more info on what MigUser.XML migrates, check here (click on the user data link at the top of the page).
What operating system settings does USMT migrate? USMT provides built in support for the migration of many operating system settings. A high level list of the settings that migrate can be found here. All of these settings migrate by default. In order to disable the migration of certain settings a custom config.XML (click on config.xml at the top of the page) must be created and edited.
What application settings does USMT migrate? Similar to the migration of files, USMT can be configured to migrate nearly any application setting (well, at least those that are stored in files or registry keys). However, once again USMT ships with an XML file that defines the migration of certain application settings. In this case, the file is MigApp.XML and the applications that it supports can be found here (click on supported applications at the top of the page).
How does USMT store user state? Although there are a few different formats that one can choose from, we call all of them a "migration store." The different formats are as follows:
- Uncompressed migration store: choosing this format produces a containing a .dat file containing all files selected for the migration. Settings and other information are stored in an additional .mig file.
- Compressed migration store: choosing this format produces a directory containing a single compressed file containing all files and settings included in the migration. This file has a .mig extension and cannot be opened without USMT.
- Compressed and encrypted migration store: choosing this format results in the same experience as the compressed migration store, however the file is also encrypted with the provided key string.
See the Scanstate syntax page for more details (click on the storage options link at the top of the page).
When should I use USMT? USMT is best used in automated deployment scenarios where a user is being migrated from one install of Windows to another (on the same computer) or when a user is being migrated from one computer to another (two different computers). USMT 3.0.1 currently supports migrating to and from the following operating systems:
- Windows 2000 to Windows XP, Windows Vista
- Windows XP to Winodws XP, Windows Vista
- Windows Vista to Windows Vista
Comments
Anonymous
January 01, 2003
why does this fail to bring in the outlook 2007 settings, when it brings in the outlook 2003 ones flawlesslyAnonymous
June 21, 2010
The comment has been removedAnonymous
June 26, 2012
> Windows XP to Winodws XP, Windows Vista When are you going to learn to spell "Winodws"???Anonymous
February 06, 2013
When we do a migration from win XP English to Win 7 Swedish,or Chinese ,there will be changes in the folder path right? suggestion on this please?Anonymous
February 06, 2014
Hi, thanks in advance, I am trying to exclude a folder from getting scanned by USMT. This folder location is being read from registry. PFB the changes done to MigDocs.xml for your reference. %WFPaths%* [*] However, this does not seem to work as expected. The folder location still gets scanned by USMT. We have following questions. 1.Is the above syntax correct? 2.Does MigXMLHelper.GetStringContent() support registry locations with white space characters? 3.Is there any other way to read the value from registry without using this method? Kindly let us know if you have answers for the above. Appreciate the help.