User-State Migration

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, \\MyServer\usmt\Captured\%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.