The User State Migration Tool is used to move user’s files
and settings from one system to another during the migration process. When
running the tool, the ScanState component collects
the user files and settings from the source computer and places them into an
intermediate store. Later, the LoadState component is
run on the destination computer to move the files and settings from the store
to the machine running Vista.

The User State Migration Tool is designed to follow
instructions that are contained in migration rule files. The tool contains three
built-in migration rule files: MigApp.xml, MigUser.xml, and MigSys.xml.
Since these files are in XML format, you have the option of modifying any or
all of the default migration rule files. You also have the option of creating a
custom migration rule file. In this article, I will show you how it’s done.

Migration rule file basics

Both the ScanState and the LoadState utilities offer several command line switches
that you can use to custom-tailor the migration process to meet your needs. If
you plan on using any of the built in migration rule files, modified migration
rule files, or a custom migration rule file, you will have to use the /I switch with both ScanState
and with LoadState.

The syntax for using the /I
switch is relatively simple: just specify the /I switch followed by a colon and the name of the migration rule
file that you want to use. For example, if you wanted to tell ScanState to use the MigApp.xml
file, you would use the following command:


As you have probably already figured out, each of the
migration rules files have a different purpose, and the only way to gain total
control over the migration process is to use multiple rules files. If you
should need to use multiple rules files, you must use the /I switch once for each rules file. For example, if you wanted to
tell ScanState to use the MigApp.xml, MigSys.xml, and MigUser.xml
files, you would use the following command:

/I:MigSys.xml /i:MigUser.xml

Before I move on, there are two other things that you need
to know about the /I switch. First,
you will notice in the sample commands above that I did not specify a path to
the various XML files. If you don’t specify a path, then the migration rules
files must be located in the same folder as ScanState.exe
and LoadState.exe.

If you decide to store your migration rules files elsewhere,
you must provide the path to the file after the /I switch. You can specify a full path or you can use a relative
path. ScanState and LoadState
will work with either.

The /I switch does
not have to be used by itself. You can use the /I switch in conjunction with any of the other switches that ScanState and LoadState support.

Using the /I switch
With LoadState

When it comes to using the /I switch, LoadState uses exactly the
same syntax as ScanState does, so I’m not going to
waste your time going over the syntax again. However, you do need to know that
if you use the /I switch with ScanState, then you must also use
it with LoadState. Mismatching migration rules files
has some rather interesting consequences.

In previous versions of Microsoft’s User State Migration
Tool, the various XML files were considered to be so important to the migration
process that they were copied to the store along with the migration data; this
isn’t the case with the current version. If you specify an XML file when you
run ScanState, you must also specify that same file
when you run LoadState. There is one exception to
this, which I will cover later.

Right now, you’re probably wondering what happens if you do
mismatch migration rules files when running ScanState
and LoadState. The most common type of mismatch is
specifying a migration rules file when running ScanState,
but accidentally omitting the file when running LoadState.
As I have explained, the migration rules files provide rules for the migration
process. They tell the User State Migration Tool what needs to be migrated, and
what needs to happen to that data during the migration process.

With this in mind, let’s consider what happens if you
specify an XML file when running ScanState, but
forget to specify it when running LoadState. Since
you have used the XML when running ScanState, the
User State Migration Tool knows what data you want to migrate. In fact, the
data that is to be migrated is written to the store by ScanState.
When you run LoadState, it migrates
everything in the store. Since the data that was specified within the XML file
was written to the store, that data is migrated, even though the XML file was
not specified when you ran LoadState.

Although it sounds as though the migration will work
perfectly even if you don’t specify the XML files when you run LoadState, there is one very big problem with not
specifying the various migration rules files. The problem stems from the fact
that the migration rules files’ purposes are twofold. Yes, the migration rules
files tell the User State Migration Tool which files and settings to migrate,
but they also tell the tool what must be done with the data as a part of the
migration process.

For example, suppose some of the systems being migrated
contain a folder named C:\DATA that
contains all of the user’s documents. Since this folder isn’t really a
conventional place to store the user’s documents, you decide to move the files
to the user’s My Documents folder on the target system. To do so, you would
insert the following command into the MigApp.xml file:


In case you are wondering, CSIDL provides you with a way of
specifying a location on a target computer even when you don’t know the
absolute path of the target folder. For example, %CSIDL_PERSONAL% maps to My Documents. You can find a list of the
various CSIDL mappings at Microsoft’s Web

At any rate, including this command in the MigApp.xml file ensures
that all of the files contained in the C:\DATA
folder are written to the store. If you don’t call the MigApp.xml file when you run LoadState, though, LoadState will create a folder named C:\DATA on the target machine and place the user’s documents into
it. The files are not moved to the My Documents folder, because LoadState is unaware of the instruction to do so.

A reverse scenario

I have covered what happens if you include the migration
rules files when you run ScanState, but forget to
specify them when you run LoadState. But what happens
if you do things the other way around? What happens if you run ScanState without specifying any migration rules files?

Well, it depends on what other switches you have specified
for use with ScanState. As you may recall from the first
in this series, ScanState supports the
use of a switch named /TargetXP, which you can use to specify that the target
system will be running Windows XP. You would not use this switch during a
Windows XP to Vista migration; but, if you did, ScanState
would copy all of the user accounts from the source machine to the store but
wouldn’t attempt to copy anything else. If you were to run ScanState
without the /TargetXP
switch (as with a migration to Vista) and you did not specify any migration
rules files, then ScanState would copy the source
machine’s user accounts, as well as the default operating system components, to
the store.

As you can see, it is important to use the /I switch with both ScanState
and with LoadState. I don’t want to give you the
wrong idea, though: If you are going to be migrating to Windows Vista, don’t
blindly tell ScanState and LoadState
to use MigApp.xml, MigUser.xml,
and MigSys.xml.

In a real world XP to Vista migration, you don’t want to use
at all. This file is only used in migrations in which both the source and the
target computer are running Windows XP. When the target computer is running
Vista, the User State Migration Tool uses manifests in place of the MigSys.xml file.
You don’t have to do anything to get ScanState and LoadState to use these manifests. Manifest use is
automatic, and the manifests themselves cannot be modified.

The MigApp.xml and MigUser.xml files
are both valid for Windows XP to Vista migrations. Prior to using these files,
you should go through them and omit any code that isn’t applicable to your
organization, and add code for anything that isn’t being migrated by default.
Modifying this code should be fairly straightforward for anyone with basic XML

Generating the Config.xml file

Earlier in the article, I briefly mentioned that you should
always use the same /I parameters with ScanState as you do with LoadState,
but with one big exception. That exception involves a migration rule file that
I haven’t talked about yet, named Config.xml. The
thing that makes the Config.xml
file so special is that unlike the other XML files that I have discussed, it
does not exist by default. You will have to use ScanState
to create it.

Using the Config.xml file isn’t mandatory, but I recommend using it
any way. Creating a Custom.xml
file allows you to preserve the default XML files. That way, you can keep all
of your modifications in one place, which makes those modifications easier to
keep track of. The Custom.xml
file is particularly useful for specifying exclusions. For example, if you knew
that some users had been storing MP3 files on their systems, you could use the Config.xml file
to migrate all of the files found in C:\DATA,
except for MP3 files. There are lots of other ways that you can use the Config.xml file
to include or exclude various types of data; there is a great reference at TechNet.  

About the only thing that you can’t do with the Config.xml file
is exclude user accounts from being migrated. If you need to exclude user
accounts from the migration, you will have to use the /UE switch to exclude the user account. You can find a complete
reference to the command in Microsoft’s
Windows Vista TechNet site

Generating Config.xml

As I said, creating a Config.xml file isn’t mandatory.
You can just modify the other XML files; but, you don’t even have to do that.
You can run ScanState and LoadState
using the default XML files. I recommend creating and customizing the Config.xml file, however, because doing so will
give you a lot more control over the migration process.

Having said that, Microsoft recommends beginning the process
by installing the User State Migration Tool on a PC that is a good
representation of what you will be migrating. There will probably be some
variance among the PCs in your organization, but you want to pick a PC that has
most of the same applications as the other PCs that will be migrated. It will
also be helpful if any data stored on the hard drive exists in the same folders
as the data on other PCs that will be migrated. Once you have installed the
User State Migration Tool on such a PC, run the following command:

ScanState /genconfig:Config.xml /I:MigUser.xml /I:MigApp.xml

This command generates the Config.xml file, but, contrary to
its appearance, it does not create a store or prepare any data for migration.
The MigUser.xml
and MigApp.xml files are included in the command because
ScanState uses these files as a template for building
the Config.xml
file. Assuming you make the necessary modifications only to the Config.xml file,
you will not need to use the MigUser.xml or the MigApp.xml files
when you later run ScanState and LoadState.