Deploying Windows XP, Managing User State (Part 2) Page 2

USMT

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 TargetServerTargetShareTargetDirectory /i MIGSYS.INF /i
 MIGAPP.INF /i MIGUSER.INF /i SYSFILES.INF /s /f /v:1

>> Frequently Used Switches