Deploying Windows XP, Managing User State (Part 2)

by Marcin Policht

We continue looking at the role of user state in Windows XP migration with a focus on two tools from Microsoft: Files and Settings Transfer Wizard and User State Migration Tool.

The previous article of our series, presented general principles applicable to user state migration, including the identification of typical locations where user state and data are located and a description of some of the most common challenges involved in its implementation. We also summarized the most popular third-party tools that help automate it in larger environments.

This installment will focus on two tools offered by Microsoft:

  1. Files and Settings Transfer Wizard, which is intended primarily for individual use, is part of the Windows XP operating system. Although the original version suffered from some problems outlined in Microsoft Knowledge Base article KB307869, they were corrected in the Windows XP Service Pack 1.
  2. User State Migration Tool (USMT) is geared toward higher-volume migrations and is currently in version 2.6. It is downloadable from the Microsoft Download Center. Earlier versions of USMT were included on the Windows XP and Windows 2003 installation CDs.

Although both Microsoft products and third-party tools enable the simplification and automation of the user state migration process, a significant amount of preparations must still be done before the capabilities are fully realized.

First, you must identify users' settings, application, and data to be migrated. This can be a difficult task, depending on how consistent the environment is. Users' files may be scattered across local drives on their computers, which may also contain a number of nonstandard and nonapproved applications. Since users' data and settings must be temporarily copied from their regular location, extra disk space is a must. Again, it is up to you to evaluate how much storage will be needed — the outcome will vary depending on how complex and well known the environment is.

When determining how much space is needed, be sure to take into account the space user-specific files on local drives consume. This might include user configuration settings and preferences stored in registry and INI files as well as other sources (e.g., Internet Favorites), user documents, and archived e-mail. The most extreme approach involves copying the entire content of local disks and is likely to dramatically raise storage requirements. The SCANSTATE.EXE utility (part of USMT), offers some help with this process. It provides the estimated space requirements for storing settings and files copied during migration (when executed with /compress- /p switches).

The Files and Settings Transfer Wizard is accessible from the Start -> All Programs -> Accessories -> System Tools menu on Windows XP Home or Professional editions, as well as from the "Transfer files and settings" option of the Windows XP installation CD (remember to use the copy slip-streamed with Service Pack 1 or 2, because of problems with its original version). The Wizard works well in scenarios where a home or small office user wants to copy settings from one computer (which can be running Windows 9x, ME, NT 4.0, 2000, or XP version) to another (running Windows XP). Settings and files from the old computer can be stored on a floppy disk (although this method tends to be inconvenient and time consuming), another type of removable media, a network share, or copied via a direct serial cable connection between two computers (an option that is useful when a network connection is not available).

While the Files and Settings Transfer Wizard suffices for individual and small-scale migrations, it is not suitable for larger or more complex deployments.

A Wizard-driven interface makes the operation really straightforward. First, you are prompted to indicate whether the Wizard is running on an old computer or a new computer. In the first case, you must specify the location where user state data can be stored (giving you all of the above-listed options to choose from). After the location is specified, you must decide what is to be transferred (Settings only, Files only, or Both files and settings). A set of predefined options, covering Windows' settings (e.g., accessibility, display, mouse and keyboard, and network and printer connections), components (e.g., Command Prompt or Taskbar), applications (e.g., Internet Explorer, Microsoft Messenger, Netmeeting, Office, Outlook and Outlook Express, Real Player, or Winzip — for the complete list refer to this Microsoft Knowledge Base article 304903), profile and shared folders, and most common file types (the Wizard also provides the ability to modify these options). This completes the collection phase.

Since the applications themselves are not transferred, make sure they are installed on a new computer before transferring their settings. Once this is done, you can launch the Wizard. This time, select the 'New computer' option on the second page. At that point, you are presented with four different selections. The first three apply to the scenario where user state information must be collected from the old computer (either create a floppy-based Wizard Disk, which is initiated by running a:\FASTWiz.exe, or run it directly from the initial menu of a Windows XP installation CD). The latter option assumes the files and settings have already been collected, and it is what our example describes.

In all cases, ensure that the user state data has been collected before you proceed with the next step of specifying location (unless a serial cable connection between two computers is present, in which case a direct transfer is possible). Once the user files and settings are made available to the Wizard, the transfer takes place, and the user is prompted to log off. (The new settings will not take effect until you log on again.)



While the Files and Settings Transfer Wizard suffices for individual and small-scale migrations, it is not suitable for larger or more complex deployments (mostly due to a lack of support for automation and unattended operation). Such capabilities are provided by some of the third-party tools listed in our previous article as well as by USMT. When reviewing the options, be sure to consider the functionality benefits USMT offers (in addition to its obvious no-cost advantage). USMT's settings are highly customizable and adjust easily to different requirements. While the lack of a graphical interface makes USMT unfit for the typical home user, its command-line nature works well when incorporated into automated migrations. The tool also contains numerous provisions for a variety of issues that might surface during data migration, such as folder and file naming conflicts (which typically happen when consolidating or relocating users' data) or translating registry settings from Windows 9x to Windows XP, where applicable (e.g., if the location has changed between the versions).

Unlike Files and Settings Transfer Wizard (where a direct serial cable connection option exists), USMT is not capable of directly copying user state from one computer to another. Instead, it requires the intermediate store. It also cannot copy application installations (which means they must be installed on the new systems prior to transfer). However, USMT can be fully automated and executed in unattended fashion, without requiring user intervention to capture user state (unless migrated users encrypt their files using EFS with locally stored certificates — we will expand on this topic later). This is possible because the tool can copy state for all users who have their profiles stored on the source computer; however, by default it works only for users logged on interactively when migration is initiated. The tool operates in two stages, each with a corresponding set of executables and configuration files. During the first one, files and settings are collected by executing either SCANSTATE.EXE or SCANSTATEA.EXE on the user's old computer.

SCANSTATE.EXE is a UNICODE-capable tool intended for Windows NT, 2000, and XP systems; SCANSTATEA.EXE is an ANSI-based version designed for Windows 95, 98, and ME. Using SCANSTATEA.EXE, both are restored by running LOADSTATE.EXE on the new computer.

SCANSTATE.EXE can be run in the security context of a user whose state is being transferred or an administrative account (which facilitates unattended operation and allows migrating the state of all users whose profiles exist on the migrated computer), but LOADSTATE.EXE must be executed by an account with administrative privileges prior to the first time migrated users log on (to preconfigure transferred profiles).

The migration process is controlled through command-line switches and a number of INF files. Seven of them are included as part of the USMT source files:

  • USMTDEF.INF specifies rules to be applied when running SCANSTATE.EXE (and SCANSTATEA.EXE), affecting the behavior of all remaining INF files. This file should not be modified.
  • MIGISM.INF defines how SCANSTATE.EXE (and SCANSTATEA.EXE) perform operations like link migrations, cookies, or printers. This file should not be modified either.
  • MIGAPP.INF controls which applications and settings are included in the migration.
  • MIGSYS.INF determines which operating system settings (such as accessibility options, Command Prompt settings, and display and font properties) and Internet Explorer settings are migrated.
  • MIGUSER.INF specifies file locations and shortcuts (such as Desktop, My Documents, My Pictures, Shared Documents, and Start Menu Items) as well as file types to be migrated.
  • SYSFILES.INF contains the list of files that are not supposed to be migrated. These files are determined based on operating system incompatibility issues identified by Microsoft, so removing or uncommenting any of the entries is not recommended. This file should be included in every migration.
  • ARCHIVEAPP.INF is used when migrating settings for legacy applications.

With noted exceptions, INF files can be modified as needed (if you want to exclude a particular option, simply place a semicolon in front of a line in an INF file that contains a reference to it). It is also possible to create other, custom INF files to further alter the migration process (e.g., to migrate settings of applications that are not supported by default). This can be done following the rules defining the purpose of INF entries, as documented in USMT Help included with the product. With the exception of USMTDEF.INF and MIGISM.INF, INF files must be explicitly specified during the scanning phase (otherwise they are ignored). In its most common form, the SCANSTATE.EXE command-line utility has syntax similar to the following:

SCANSTATE \\TargetServer\TargetShare\TargetDirectory /i MIGSYS.INF /i

>> Frequently Used Switches

Frequently Used Switches

\\TargetServer\TargetShare\TargetDirectory designates an intermediate location where collected user state data will be stored. By default, it is stored in compressed format in the USMT2.UNC subfolder, although compression can be turned off using the /compress switch, which allows you to manipulate the content of the collected data. Typically, it makes sense to assign a name to TargetDirectory that reflects the name of the user's Windows account and source computer (especially if the same user works on several, differently configured computers). The /i switch is followed by the name of an INF file that contains settings affecting migration behavior. There are also a number of other switches, the following of which are used most often:

  • /x specifies only custom entries defined in INF files will be applied (ignoring all default entries).
  • /o causes data in the target location to be overwritten.
  • /localonly ensures only files stored on local drives are copied to the target location (it is possible, through changes to INF files, to include files from mapped network drives in the migration).
  • /v followed by the colon and a number from 1 to 7 produces verbose output (with 1 corresponding to the lowest level of detail, and 7 to the highest). The output is written by default to the SCANSTATE.LOG file in the folder from which USMT is executed. You can modify its location with a /l switch, followed by the path and name of the log file.
  • /f migrates files (but not system or user settings) and can be supplemented with others, such as /u or /s.
  • /u migrates the entire HKEY_CURRENT_USER registry hive.
  • /s limits the migration of user settings to elements like mapped network drives and printers or Internet cookies.
  • /p in combination with the /compress option estimates the amount of a space necessary to store user state (results are written into USMTSIZE.TXT file).
  • /c continues operation even if a non-critical error is encountered (such as the presence of EFS files).
  • /all migrates state for all users whose profiles exist on the source computer (otherwise, the migration applies only to the currently logged-on user).
  • /user:DomainName\UserName migrates state only for the DomainName\UserName user specified.
  • /efs dictates the behavior when EFS files are encountered. It can be used with the following values:
    • /efs:abort, which is enabled by default, causes SCANSTATE.EXE to fail if an encrypted file is found on the source computer.
    • /efs:skip ignores EFS files during copy.
    • /efs:decryptcopy attempts to decrypt EFS files before copying takes place. If this is not possible, SCANSTATE.EXE fails unless /c switch is specified.
    • /efs:copyraw forces EFS files to be copied to the target location in encrypted format.

Syntax of LOADSTATE.EXE is similar, although in this case, one additional INF file - MIGRATION.INF is generated automatically when running SCANSTATE.EXE (or SCANSTATEA.EXE). MIGRATION.INF determines some of the migration settings used during data loading. This INF file, as well as the others used during the scanning phase, is applied implicitly — so they do not appear on the command line. Some of the switches used by SCANSTATE.EXE (such as the ones specifying the type of data to copy or determining EFS-related behavior) are no longer applicable; however, there are some new ones that are specific to the loading phase, such as:

  • /md:OldDomain:NewDomain allows user state to be transferred from one computer to another for user accounts that are being migrated between domains.
  • /mu:OldUserName:NewUserName is similar to the previously described option but is used when the user name changes during migration.
  • /lac:Password results in the creation of local accounts (with appropriate password) on the target computer (in scenarios where such accounts were used on the old computer — instead of domain-based ones),
  • /lae enables newly created local accounts.
  • /rollback records changes applied during the loading phase into a backup file, which allows rollback in case of LOADSTATE.EXE failure
  • /q allows LOADSTATE.EXE to run without checking whether the current user has Administrative privileges.

Note that both File and Settings Transfer Wizard and USMT do not transfer application passwords (this might impact applications like Outlook Express, Internet Explorer, or settings like those for mapped network drives). As per Microsoft Knowledge Base article KB283734, this is a feature intended to reduce the possibility of compromising your personal data. The tools also do not transfer ACLs on migrated files, so permissions must be applied separately following the migration to properly secure users' data. Similarly, as indicated before, additional precautions must be taken in situations where users have EFS-encrypted files. If EFS certificates are stored locally on the migrated computer, they must be transferred manually (typically using Certificates MMC snap-in) for each of the users.

This article was originally published on Friday Feb 11th 2005
Mobile Site | Full Site