User-State Migration

Moving a user's data and settings from an old (Windows 95 or later) system to a new Windows XP system can be tricky. Part of the challenge is gathering all the links, settings, and other data that the user needs and leaving behind the items that the user doesn't need. By automating the process as much as possible, you can attain consistency and efficiency when you perform multiple migrations.

Microsoft provides two tools to help you perform user-state migrations: the Files and Settings Transfer Wizard (FSTW) and the User State Migration Tool (USMT). The tools are functionally similar, but FSTW's GUI-driven, user-friendly interface is less suitable for mass migrations than the highly customizable, scriptable USMT.

The Files and Settings Transfer Wizard
IT professionals who need to migrate more than just a few systems probably won't have much use for FSTW. However, if you understand its capabilities, you can use it as a quick solution when you don't have time to prepare USMT. In a nutshell, you execute FSTW on the source (i.e., old) system, save the user state to a network or disk location, then run FSTW again on the target (i.e., new) system to restore the user state. For a comprehensive list of files and settings that FSTW covers, see the Microsoft article "List of Programs Whose Settings Are Migrated When You Use the Files and Settings Transfer Wizard" (http://support.microsoft.com/?kbid=304903).

To access FSTW, on the XP system, go to Start, Programs, Accessories, System Tools, then select Files and Settings Transfer Wizard. The FSTW interface asks whether you want to create a Wizard Disk that contains the FSTW software for the source system. Alternatively, on the source system, you can access the FSTW program from the XP installation CD-ROM. To do so, insert the CD-ROM, choose Perform Additional Tasks from the Autorun Windows XP Welcome screen, then select Transfer Files and Settings.

FSTW is easy to use, requires no installation or advanced configuration, and provides a quick method for moving user data and settings. FSTW also gives you some flexibility in gathering files and settings. You can customize the files and settings you want to collect through the interface, but the tool uses all your customizations only once, so you must repeat the customization process on all subsequent migrations. In addition, FSTW lacks USMT's granularity and automation.

The User State Migration Tool
Originally part of the Microsoft Windows 2000 Server Resource Kit, USMT isn't installed by default in XP, but you can install it from the XP Professional Edition installation CD-ROM. If you'll be using USMT as a tool for mass migrations, you should load the USMT files to a network location to facilitate automation. USMT requires no installation; you simply need to copy the XP Pro installation CD-ROM's ValueAddMSFTUSMT folder to a shared location on your network.

When selecting a location, choose one that has plenty of room in which to store the user data and settings that you gather. Under the USMT folder, create a subfolder named Captured, which will be the target of USMT-gathered files. Although you can target any location for storing USMT data, I recommend—for the sake of simplicity—that you keep all USMT resources together. For the same reason, I recommend sharing the USMT folder on the server as USMT; this article's batch files reference the USMT share.

USMT Files
After you copy the USMT files and create a share, take a look at the files in the share. You'll notice a mixture of .exe, .dll, and .inf files. You'll also notice a subfolder called ANSI. The Unicode files that reside in the primary USMT folder won't run on Windows Me or Windows 9x. The Win9x OSs must run the ANSI version, which resides in the ANSI subfolder. To ensure that the correct version runs regardless of the OS you launch it from, you can use a cool batch-files trick, which I discuss later.

Scanstate.exe and loadstate.exe are the tools that you'll use for migrations. Scanstate gathers and saves user data and settings from a source system, and Loadstate restores the saved data to the target system. Both executables accept arguments that specify which .inf files to process, where the collected data and settings reside, and how USMT logs operations. Because the arguments passed to the executables can get lengthy, especially if you're using Universal Naming Convention (UNC) pathnames, you should use batch files with predefined arguments to run each tool.

The files with .inf extensions control the behavior of USMT when Scanstate runs. You'll notice many .inf files—some are user-modifiable, others shouldn't be modified, and none of them have self-explanatory names. (Later in this article, I dive into the purpose and usage of the .inf files.) The files with .dll extensions in the USMT folder are necessary to support both Scanstate and Loadstate operations.

Automating Scanstate and Loadstate Operations
You need to keep in mind a few rules related to USMT functionality and its correct usage. USMT is intended to support only migration of domain user–based profiles—not migration of workgroup-based profiles. You must run Scanstate, or the batch file that calls Scanstate, while logged on as the user whose profile you want to migrate. You must run Loadstate, or the batch file that calls Loadstate, as a user with administrative rights on the target system. The user you want to migrate must not already have a profile on the target computer. Because of this last rule, you must not attempt to run Loadstate as the user being migrated. To ensure success, I always run Scanstate as the end user and run Loadstate as the local administrator.

To simplify multiple migrations while ensuring that the transferred user data and settings are consistent, you can use variables and predefined paths in batch files. GetUser.bat, which Listing 1 shows, gathers data and settings from the source computer, and PutUser.bat, which Listing 2 shows, places the data and settings on the target system. For a list of the arguments that Scanstate accepts, see Table 1. (You should use the /u, /f, and /x parameters only when you need them for troubleshooting; Scanstate gathers the user settings, system settings, and data specified in the .inf files by default.)

Let's first look at GetUser.bat. Notice in Listing 1 that the batch file uses the variable %1 for the username; you need to enter a value in place of this variable. The batch file uses this value in the migration path, which is a required argument for Scanstate, and to create user-specific folders. The batch file then creates and names (using the variable) a subfolder, to which it will write migrated contents and log files. Notice that the batch file creates this folder beneath the Captured folder you created earlier.

Next, the batch file determines which OS is in use and jumps to the corresponding section to run the appropriate version of Scanstate. Only the path to scanstate.exe changes, so you can use one set of .inf files for both Windows NT–based and Win9x OSs. The batch file includes the /c parameter so that Scanstate continues past minor problems such as lengthy filenames. You must specify the path and filename of each .inf file that you want to process; to do so, include the path and filename, preceded by /i, as arguments to the scanstate.exe command. To ensure successful execution regardless of how the batch file launches, I suggest that you use full UNC pathnames. The /l and /v parameters provide the location, name, and verbosity level of the log file. The final argument, \MyServerusmtCaptured%1, is the path to which the batch file will write the captured files and settings data.

Now let's look at PutUser.bat. Loadstate requires a less complex string of arguments because it uses only one input file, migration.inf, which the Scanstate process creates. Also, no ANSI version of Loadstate exists: Because USMT is intended only for migrations to newer OSs, the batch file doesn't need OS discovery logic. Notice in Listing 2 that the batch file uses essentially the same syntax that Listing 1 uses for Scanstate. The same parameters are available, with the exception of /c. Again, the batch file uses a user-supplied variable to determine paths from which USMT will restore data and settings and to which the tool will write the log file.

You'll find that running Scanstate in what I call "full-throttle mode"—as it's run through GetUser.bat—collects more data than you probably need for a real-world migration. However, I suggest that you start with this mode so that you get a feel for which information gets migrated and how it all migrates to the target system. Then, by modifying or omitting certain .inf files, you can begin to prune out any pieces you don't want to migrate. To collect custom data and settings, you can also create your own .inf files and use the /i parameter to specify them in the batch file.

Modifying .inf Files
After you attempt a few test migrations and take note of the sizeable and diverse range of data and settings that USMT gathers by default, you'll probably determine that you need to do some tweaking to tailor USMT to your environment. The three .inf files you'll want to examine are migsys.inf, miguser.inf, and migapp.inf. You shouldn't modify sysfiles.inf, because it contains a list of files that must not migrate; this default list consists of OS files that might conflict with the target system's newer OS files. The only exception to this rule would be if you needed to add a file to the list to ensure that the file never gets migrated. Migsys.inf contains rules for migrating OS settings such as accessibility options, fonts, sounds and multimedia, and other look-and-feel settings. Miguser.inf specifies the user and machine folders that will migrate. These folders include, but aren't limited to, Desktop, Start Menu, Favorites, My Documents, and Quick Launch. Migapp.inf migrates settings for a select group of applications. The supplied application-migration rules cover a range of popular Microsoft and third-party applications, but keep in mind that only the settings migrate—the applications must be installed on the target system to take advantage of the migrated settings.

After you know where to look, you can begin customizing the .inf files to suit your needs. If you have some Windows programming experience, the structure of .inf files will be familiar to you. If not, you can use the following guidelines, but if you need to perform a lot of fine-tuning, you might want to do some additional reading about the structure of .inf files. If you have the Windows Server 2003 installation CD-ROM, check out the extensive User State Migration Tool – INF Commands document in the USMT folder.

The basic structure of .inf files uses section names encased in brackets. In the example that Figure 1 shows, version and System Settings are sections. The contents of a section will often reference a component or individual state further down in the .inf file. A component is a set of related rules that define a state for an item, whereas an individual state is defined by one file, registry setting, or folder. USMT handles most items listed in the default .inf files as components because the tool can deal with items more easily when they're grouped together. In Figure 1, for example, the items listed in the System Settings section are components, and each item shows up later in the .inf file as a section containing items that make up that state. To disable the collection of all files and settings that are part of a component, you simply place a semicolon in front of the component's name in the top section (in this case, System Settings). This process might sound complicated, but with a little practice, you'll be jumping around .inf files easily.

To expand the data that USMT gathers, you can add items to the default .inf files, but I recommend that you create a custom .inf file and process the .inf files by adding them to the Scanstate command line, preceded by /i. Listing 3 shows a simplistic example of a sample .inf file that uses components and shows how one section points to another. This illustration should provide some insight into the flow of the .inf files and get you started on creating your own. If you have access to the previously mentioned User State Migration Tool – INF Commands document, you'll find a wealth of information about modifying and creating .inf files therein.

Flexible Tool
Both FSTW and USMT are useful when you need to move users from one system to another, but the flexibility of USMT and the ability to automate its functionality make it better suited to enterprise migrations. Microsoft has made advances in the Windows 2003 version of USMT, including the ability to automate domain membership changes.

I close with some words of caution: If you switch versions midstream, you'll need to use the new .inf files. You'll also need to update your batch files because some arguments have changed.