If you’ve ever used the Files And Settings Transfer Wizard to migrate from an older operating system to Windows XP or from one Windows XP box to another, you know that it works fairly well. But the tool is targeted at migrating individual PCs and is considered impractical for large-scale migrations involving many computers.

Fortunately, Microsoft offers the User State Migration Tool (USMT), which is designed specifically for large-scale migrations. In this article, I’ll introduce you to the USMT and show you how to configure it for better migrations.

Acquiring the USMT

Although the USMT is not installed by default, it is included on the Windows XP Professional installation CD. The necessary files are located in the CD’s \VALUEADD\MSFT\USMT folder.

Anatomy of the USMT
The USMT consists of several files, six of which you need to be aware of. Two of these files are executables, while the other four are configuration files. The two executable files are Scanstate.exe and Loadstate.exe. Scanstate.exe compiles information contained on the old workstation. Loadstate.exe is responsible for placing the collected information onto a new computer (or new Windows installation). The four configuration files are Migapp.inf, Migsys.inf, Miguser.inf, and Sysfiles.inf. I’ll show you how to customize these files later in this article. For now, it’s just important to know that they exist.

Basic USMT usage
The migration process involves running Scanstate.exe on the user’s existing workstation. The collected information is stored in a centrally available location, such as on a network drive. Next, you install Windows and the necessary applications on the new workstation. Finally, you run Loadstate.exe on the new workstation to migrate the user’s settings.

Although this sounds like a lot of work, the entire process can be streamlined or automated in various ways. For example, you could e-mail all of the users the Scanstate.exe file and have them run it before leaving for the day. Or you could schedule Scanstate.exe to run automatically. Additionally, you could use disk-imaging software to automatically install Windows and the necessary applications on the new PCs, or you could configure a system login script to run Loadstate.exe the next time the user logs in.

Working with Scanstate.exe
Both the Scanstate.exe and the Loadstate.exe are command line tools. The syntax for Scanstate.exe is as follows:
 
SCANSTATE migration path
[/C /I input.inf]* [/L scanstate.log] [/V verbosity_level] [/F] [/U] [/X]

The command begins with an argument that specifies the migration path for the information you will collect. In this syntax, the /C switch tells Scanstate.exe to continue even if it encounters a Filename Too Long error. The /I switch tells the utility which INF file to use to define the rules defining the information collection process. (You can specify multiple INF files.) The /L switch tells the utility what file to use for logging data collection errors. The /V switch tells the application what level of verbosity to use. You can use values ranging from 1 (least verbose) to 7 (most verbose). This switch is optional. The /F switch tells the utility that files will be migrated, and the /U switch tells the utility that user settings will be migrated. The /X switch tells the utility that no files or settings should be migrated. Before you use the utility, it’s important for you to know that the/F, /U, and /X switches are intended for troubleshooting purposes only and should never be used in a real migration.

Here’s an example of the command in action:
 
SCANSTATE \\servername\sharename\userfolder /I .\migapp.inf /I
.\migsys.inf /I .\miguser.inf /I.sysfiles.inf /I .\files.inf

Working with Loadstate.exe
The syntax for the Loadstate.exe switch is as follows:
 
LOADSTATE migration path [/I inputfile.inf] [/L loadstate.log] [/V verbosity level] [/F] [/U] [/X]
 

All of the switches in Loadstate.exe do the same thing they do in Scanstate.exe. Once again, the /F, /U, and /X switches are for troubleshooting purposes only. A typical Loadstate.exe command might look something like this:
 
LOADSTATE \\server_name\share_name\user_folder /I .\miguser.inf

Modifying the configuration files
The default configuration files are designed to migrate the following files and settings:

  • Internet Explorer settings
  • Outlook Express settings and store
  • Outlook settings and store
  • Dial-up connections
  • Phone and modem options
  • Accessibility
  • Classic desktop
  • Screen saver selection
  • Fonts
  • Folder options
  • Taskbar settings
  • Mouse and keyboard settings
  • Sounds settings
  • Regional options
  • Office settings
  • Network drives and printers
  • My Documents folder
  • My Pictures folder
  • Cookies folder

Sometimes, however, the settings listed above simply aren’t enough. For example, your workstations may have some data directories that need to be migrated. Likewise, there could be objects on the list above that shouldn’t be migrated. For instance, maybe you don’t want to migrate the Cookies folder. You can easily custom tailor the migration process to meet your needs by modifying the contents of the four configuration files I mentioned earlier.

Before you begin
Before you attempt to modify the configuration files, I should point out that the process requires basic Windows scripting knowledge and knowledge of the Windows registry. If you modify the configuration files incorrectly, you could destroy Windows on the new machine or cause a variety of other problems. Therefore, unless you feel comfortable performing the techniques I’m about to show you, I recommend going with the default settings.

The names of the four main migration configuration files denote each file’s purpose. For example, Migapp.inf is responsible for migrating applications, while MIguser.inf migrates user settings. The modification tricks I’m about to show you should work with any of the four files, as they relate to scripting syntax rather than to actual objects. You should, however, define the migration of objects within the appropriate file.

Variable support
Variables are designated by a phrase enclosed by two percent signs. For example, %BRIEN% would refer to the fictitious variable Brien. Generally speaking, you’ll have to deal with two types of variables, environmental variables and registry variables.

Environmental variables are things like %USERNAME%. For example, if someone logged in as the Administrator, the contents of %USERNAME% would be Administrator. Registry variables are a CSIDL value enclosed by percent signs. For example, %CSIDL_PERSONAL% might be equal to C:\Documents and Settings. These variables can also be followed with a pathname or a wildcard. For example, %CSIDL_PERSONAL%\*.TXT could equal C:\Documents and Settings\*.TXT (all of the text files in the Documents and Settings folder).

File inclusion rules
One of the most common modifications to scripting files is a specification of additional files to be included in the migration. For example, suppose that a user kept a set of budget reports on his or her hard disk in a folder named C:\Budget_Reports. Obviously, you would want those files to be migrated.

Specifying the files involves locating the [Copy This State] section of the appropriate INF file and adding a CopyFiles label. This label then points to a section within the file. For instance, if your CopyFiles line is Copy Budget Reports, you must include a heading called [Copy Budget Reports] within the file. The code might look something like this:
 
[Copy This State]
CopyFiles=Copy Budget Reports
[Copy Budget Reports]
DIR=C:\Budget_Reports
DIR=C:\Budget_Reports\*
 

Now, let’s take a look at how some variables might play into an inclusion rule. Suppose that a user had a bunch of budget reports (all with the .XLS extension) stored on his or her desktop. You could use the %CSIDL_DESKTOP% variable to specify the user’s individual desktop within the script. For example, if you were to append the following command to the inclusion file, all of the XSL files on the user’s desktop would be migrated:
 
%CSIDL_DESKTOP%\*.XLS

File exclusion rules
Exclusion rules work similarly to inclusion rules, except that they tell the migration process which files shouldn’t be migrated. The syntax for an exclusion rule is nearly identical to that of an inclusion rule, but instead of using the CopyFiles command, you’ll be using the DelFiles command. For example, the following block of code would tell the migration process not to migrate those budget reports.
 
[Copy This State]
DelFiles=Delete Budget Reports
[Delete Budget Reports]
DIR=C:\Budget_Reports
DIR=C:\Budget_Reports\*

Registry inclusion and exclusion rules
Just as you can establish inclusion and exclusion rules for files, you can also establish such rules for registry entries. For example, suppose that my old workstations were running Norton Antivirus, but my new workstations were going to be running Hauri’s ViRobot. If that were the case, I would want to exclude any registry entries pertaining to Norton Antivirus to prevent them from being migrated to the new workstation. Likewise, if your company’s accounting software used some obscure registry entry, you’d probably want to specify those registry keys in an inclusion rule so that you could make sure that the accounting software would work correctly on the new workstations.

The syntax of registry inclusions and exclusions is similar to file inclusions and exclusions. Like file inclusions and exclusions, registry inclusions and exclusions must be defined within the [Copy This State] section of the .INF file. You must also define a section tag and then specify the registry location. For the purposes of this article, I’ll use the word ACCOUNTING as my section tag. To migrate a specific batch of registry keys, the syntax would look something like this:
 
[Copy System State]
AddReg=Accounting
[Accounting]
HKEY_LOCAL_MACHINE\Software\Vendor\Accounting\*=
 

You’ll notice that the last line of my sample code above ends in *=. This means that the migration process should copy all subkeys beneath this particular registry key.

Now, let’s take a look at a registry exclusion rule:
 
[Copy This State]
DelReg=Accounting
[Accounting]
HKEY_LOCAL_MACHINE\Software\Vendor\Accounting [Table EXE]=
 

As you can see, the AddReg command has been replaced by the DelReg command and *= has been replaced by [Table EXE]=.

Rule considerations
Earlier, I introduced the four script files you can modify and said you need to place your commands in the correct file. Even if you specify a command within the correct file, though, you must still consider how the command will be processed. For example, the DelReg command can be processed by either the Scanstate.exe or Loadstate.exe file. This means that if you want to get rid of a registry key, you can implement the DelReg command into an INF file and eliminate the registry key during the compilation process. If, on the other hand, you had already compiled the migration information and an unwanted registry key was accidentally migrated, you could add the DelReg command to an INF file and filter out the unwanted registry key during the Loadstate.exe process.

The AddReg command isn’t quite so flexible. Although this command can be run from either the Scanstate.exe or the Loadstate.exe files, it isn’t advisable to run them from Loadstate.exe. If they weren’t initially specified when the information was compiled through Scanstate.exe, the information may not even exist in the compilation, so Loadstate.exe won’t be able to process it. The same philosophy applies to the RENREG and REGFILE commands, which are used for more advanced registry manipulations.

In case you’re wondering what happens on the destination computer when AddReg and DelReg are used, it’s simple. If DelReg specifies a registry entry, nothing happens on the destination computer. The registry entry is simply not copied. If an entry is specified in the AddReg command, the entry is written to the destination computer. If the registry key already exists on the destination computer, it is overwritten.

As far as the destination computer’s other registry entries go, the migration process does not overwrite them. Only registry keys specified by the AddReg command are overwritten.

More rules for the adventurous
I’ve shown you the basics of modifying the various rule files. However, your imagination and scripting skills are the only real limits to what you can do with these files. In fact, the Microsoft Web site shows how to move registry keys from one location to a completely different registry hive through these scripts.