USMT: A Quick Run-through Guide

Preface

For this guide keep in mind that Microsoft has plenty of USMT articles to help out. They are well documented, however may be a slower read especially for most experienced administrators. The goal of this guide is to focus on the basics as quickly as possible to get one started that has had no USMT experience but no stranger to dealing with administrative tasks.

There are many benefits to keep in mind, as well as planning that must go into large scale migrations, however I’ll be assuming that your first priority is to have USMT running as fast as possible to get a feel for it.

Obtaining USMT

Microsoft will recommend downloading the Windows Automated Installation Kit (WAIK) or the Windows Assessment and Deployment Kit (ADK, for those with Windows 8). For those not familiar with WAIK, it is a kit containing tools such as a Windows PE boot environment for booting from CD/USB/PXE which has a wide variety of uses and tools for gathering and deploying images and data along with such utilities like an upgrade adviser.

You can download the 1.7GB ISO,  alternatively Simon Jarvis repackaged just USMT from the ISO for convenience: Download USMT 4.01 (~7-8 MB)

Note: There is a hotfix available for those expecting to migrate Office 2010 settings in their environments!

Migration Paths

USMT has several versions with differing source and destination paths. Version 4.0 migrates FROM the following systems:

• Windows XP SP3
• Windows XP Professional x64
• Windows Vista SP1 and Windows 7 (All 32-bit and 64-bit editions)

TO these systems:

• Windows Vista and Windows 7 (All 32-bit and 64-bit editions)

Important: 32-bit to 64-bit migrations are supported, but 64-bit to 32-bit are not.

What Gets Migrated?

I shouldn’t summarize this as this is the whole reason we are using this tool. It’s best to know what is and isn’t moved over through Microsoft’s article on this.

Test Migration

With USMT installed, open a command prompt as administrator and navigate to the USMT directory.

Backup uses the scanstate executable in the USMT directory. This is the sole command used for backing up data. It has a wide range of syntax ranging from what users to be migrated, to encryption to be applied to the migration store. On any system that has an operating system matching one of the migration path sources you can run this command like so:

scanstate.exe c:\backup /o /all /c /auto /l:”c:\scanstate.txt” /localonly

c:\backup defines the local or remote folder where to store the migration data.
/o overwrites any older backup files. Useful for testing.
/all migrates every user on the system. For specific user cases look into the UI, UE, UEL syntax.
/c continues the backup on any errors (such as read or CRC errors)
/auto migrates using the application and document backup templates. More on this in the next section.
/l:”PATH” is where the log file is saved. Like the store path, this can be remote.
/localonly makes sure not to store anything from removable media

If this is used in a small environment where the migration will not be automated the easiest way to restore is to simply move the singular backup file to the new desktop or operating system, and run the file itself. Windows Vista/7 will use its built in Windows Easy Transfer program to walk through the recovery of the migration data. Otherwise loadstate will be our friend. Here is a quick general example on common syntax used for restoring the USMT store:

loadstate c:\backup /auto

Note that loadstate points to the backup directory (containing the USMT directory) and not the MIG file itself.

Fine Tuning

Further tuning is often needed! There are three main XML files which USMT uses for selecting data to migrate. When we used /auto in the last section it was filling in a few blanks for us. /auto is the same thing as /i:MigDocs.xml/i:MigApp.xml /v:13. MigDocs.xml and MigApp.xml are files included into the syntax for scanstate or loadstate to use when working with the data. /v: is for the log file verbosity (ranging from 0, default, to 15 which covers errors, debugging info, and status), see the online syntax to see what verbosity can be set to.

What are these USMT XML files?

MigDocs.xml

This XML file is generally not going to help when looking into it as much as the others as it is a very small XML file containing a call to a routine named GenerateDocPatterns. This isn’t very well documented on how the code itself works, but they do list what MigDocs does and does not migrate. Essentially this is comes down to all the data such as media files, word documents, excel files, etc.

If you wish to do a test run on what exactly this would move over on your system you can run the /genmigxml argument and looking at the XML it generates.

scanstate.exe /genmigxml:c:\genmig.xml

MigUser.xml

This is generally the same idea as MigDocs.xml. However the work is done by what is listed inside the XML file rules rather than the XML call to GenerateDocPatterns that MigDocs.xml uses. This should not be used in conjunction with Migdocs.xml as using both together may yield duplicate files (not in the file store, but on extraction a file may be copied twice to different locations). If you like to keep things as simple as possible keep with MigDocs.xml

MigApps.xml

This ports over application settings and such things as outlook PST files to the new system. The list of programs they migrate isn’t overly extensive, but it can never hurt to include this. Generally this file should always be used.

EXAMPLE

A quick example to toss in User and App migration settings as opposed to /auto would be:

scanstate.exe c:\backup /o /all /c /i:migapps.xml /i:miguser.xml /l:”c:\scanstate.txt” /localonly

XML Fine Tuning

I would never advise to adjust the XML files already provided. If after testing you wish to prevent certain files from being migrated do not adjust the standard files. Instead create a new XML file followed by adding it in as an argument to your command. This topic gets fairly in-depth. I would recommend taking a look at this TechNet article if this is a requirement for you.

Otherwise if you prefer, it may be easier to just look at a simple custom XML to see how it is done to prevent the old start menu and desktop shortcuts from being migrated which has frustrated me in the past.

Tips and Advice

As per usual, never skimp on the testing and planning before using this. I will say this – that getting a good degree of fine tuning is a challenge!

For testing, I created a utility, Mig Recovery and Viewer, to see what is inside the Mig file without having to extract and look every time on my test machine.