Inside Windows Server 1002003 [Electronic resources] نسخه متنی

User State Migration

Users invest a lot of time and creative ingenuity in their local desktops. They also put quite a bit of effort into circumventing rules about where to save their files. When the time comes to migrate the user's desktops, the biggest challenge is to preserve their data and settings while implementing the new operating system and any new applications you're deploying at the same time.

Ordinarily, a deployment consists of three stages:

• Collect the user data and copy it to a server.




• Wipe the desktop drive and image it with the new operating system (OS).




• Transfer the user data back to the desktop.

Microsoft provides two tools that simplify the migration considerably:

• Files and Settings Transfer Wizard (FSTW) .
  This tool consists of an executable, Migwiz, and a set of INF files that determine what is to be migrated and where to migrate it. FSTW is intended to be used for standalone machines or individual users.




• User State Migration Toolkit (USMT) .
  This tool consists of two executables, Scanstate and Loadstate, and the same INF files used by FSTW. This tool is intended to be used in domain environments for migrating multiple users simultaneously.

Let's start by examining the INF scripts that are used to evaluate applications during a migration.

User Migration INF Files

Both the FSTW and the USMT use a suite of four INF files that act as migration scripts. Here's a quick list followed by a detailed look at the function of each file:

• Migapp.inf




• Miguser.inf




• Migsys.inf




• Sysfiles.inf

Migapp.inf

This script contains applications and their associated Registry entries and support files. It defines the following operations for a given application:

• The presence of the application in the Registry




• The prescribed environment for the application




• A set of instructions such as copying files to new locations and making new Registry entries

Table 19.1 lists the applications included in Migapp.inf. You can add more if you have third-party applications that aren't listed or in-house applications you want to automate during migration.

Here is a listing of the entries for Quicken to give you an idea of what the script does:

[View full width]
[Quicken 2001.Environment]
QuickenDir=Registry, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\QW.EXE 
[Path]
[Quicken 2001.Detect]
File, %QuickenDir%\QW.EXE, VERSION("ProductVersion","010.*")
[Quicken 2001.Instructions]
copyfilesex=Quicken 2001 CopyfilesEx
forcesrcfile=Quicken 2001 ForceSrcFile
[Quicken 2001 CopyfilesEx]
%QuickenDir%\QDATA.QSD,%QuickenDir%
%QuickenDir%\QW.CFG,%QuickenDir%
%QuickenDir%\QW.RMD,%QuickenDir%
[Quicken 2001 ForceSrcFile]
%QuickenDir%\QW.CFG
%QuickenDir%\QW.RMD

Miguser.inf

The Miguser.inf script includes user configuration settings in the Registry and the user profile that need to be copied to the new machine during the migration. Table 19.2 lists the default items in Miguser.inf.

Here is a sample of the actions taken on a portion of the user profile:

[Desktop Items.Detect]
Directory,%csidl_desktopdirectory%,EXISTS
[Desktop Items.Instructions]
ForceDestFile=ForceDestDesktop
CopyFilesFiltered=CopyDesktopFiles
[ForceDestDesktop]
%csidl_desktopdirectory%\desktop.ini
[CopyDesktopFiles]
dir=%csidl_desktopdirectory%\*

Migsys.inf

This script determines how to migrate operating system files and settings. Table 19.3 lists the system files that are included in the script. You can add others.

Here is a sample of the actions defined by the script for RAS connections to give you an idea of what the script does:

[Ras Connections]
AddReg = Ras.AddReg
[Ras.AddReg]
HKR\RemoteAccess\Profile\*
[Ras Connections.9X]
CopyFilesEx=RasCopy9X
[RasCopy9X]
%windir%\usmt.pbk,%CSIDL_APPDATA%\Microsoft\Network\Connections\Pbk,RasPhone.PBK
[Ras Connections.Environment.NT.Windows NT4]
RasUserFile = Registry, HKR\Software\Microsoft\RAS Phonebook [PersonalPhonebookFile]
[Ras Connections.NT.Windows NT4]
CopyFilesEx=RasCopyNT4

For the most part, there isn't much in this script that can be tailored. You may have specific settings in a system file that you want to migrate.

Sysfiles.inf

This script contains a list of operating system configuration files that require translation or special handling. Each operating system includes settings for all localized versions, such as French, Italian, German, Spanish, Chinese, Japanese, and so forth. The script also contains extensions for various files and their meanings and places to scan for them. Table 19.4 lists the operating systems included in the scan.

Using the Files and Settings Transfer Wizard

The FSTW executable is Migwiz. The executable and support scripts are stored in \Windows\System32\USMT. The Windows Server 2003 CD has a copy of Migwiz and the support files that you can use to perform the data collection portion of FSTW at 9x/ME/NT4 machines. The Autorun screen on the CD lists the migration wizard under Perform Additional Tasks (see Figure 19.1).

The FSTW performs the migration in two phases. During Phase 1, you run the wizard at the existing machine to analyze and collect the Registry entries and files. This can take a long time, depending on the number of files you have. Plan on 30 to 90 minutes. The user should not access the machine during this time.

The wizard builds an enormous DAT file that contains the migration information. The wizard offers four ways to transfer the migration file to the new machine:

• Home network.
  This option permits you to transfer the files directly over the network. This option requires running the Home Networking Wizard to configure the machine. Most organizations with existing networks will not need to perform this evolution.




• Other.
  This saves the files to a folder where they can be transported by any means at your disposal, such as a Zip drive or by burning a CD or copying across the network. This is the option of choice for an organization with an existing network.




• Floppy or removable media.
  Users without a network can save the migration files to a floppy or Zip or Orb drive. Depending on the amount of user data on the drive, you might need a

  lot of floppies.




• Direct Cable.
  This is for users who do not have a network and do not want to use a stack of floppies for the transfer. The disadvantages of this method is its slowness and the fact that it calls for a certain degree of sophistication on the part of the user to choose the right type of serial cable and connect it correctly.

During Phase 2, you run the wizard at the new machine. When you are prompted with the message, Do You Have a Windows XP CD?, select I Don't Need the Wizard Disk. The wizard then knows you are in Phase 2 and prompts for the location of the migration files. Point the wizard at the file location and then sit back and wait for it to make the changes. This also takes a while.

If the wizard encounters a critical error, it will post an HTML page describing the nature of the problem. It also saves a log file in your user profile under Local Settings\Application Data. The Local Settings folder is hidden, so make sure you turn on hidden files before searching for it.

USMT

The User State Migration Toolkit (USMT) performs a similar function as the Files and Settings Transfer Wizard (FSTW) but it permits scripting the operations so you can run the migrations wholesale rather than retail. USMT only works with domain member computers. For standalone computers, use the FSTW.

USMT uses the same set of INF scripts used by the Files and Settings Transfer Wizard. Instead of the Migwiz executable, though, USMT uses two command-line executables:

• Scanstate.
  This compares the contents of the drive and Registry with settings in the INF scripts and builds a migration script.




• Loadstate.
  This takes the contents of the INF script built by Scanstate and applies it to a target machine.

There are several advantages to using USMT versus FSTW. One is the size of the migration file. Instead of building a big, unwieldy binary DAT file like FSTW, Scanstate builds a text-based INF script with folders that contain the files it needs to copy to the target machine. Scanstate also runs much, much faster than FSMW.

Here is the syntax for Scanstate. The entries should all be on one line:

[View full width]
scanstate <
location > /c /v:7 /l:usmt.log /i:miguser.inf /i:migapp.inf /i:migsys.inf /i:
sysfiles.inf

Here are the meanings of the Scanstate switches:

• <location> .
  This is the location where you want Scanstate to save the migration files. You'll need 100MB to 150MB depending on how many user files are on the machine. This can be a network drive.




• /c .
  Skips errors involving long filenames. The skipped files are logged in Longfile.log.




• /v .
  This is a "verbose" switch. There are seven levels of verbosity, with 7 being the most verbose. I always use the 7 setting. If something goes wrong, I want to see everything about the failure in the logs.




• /l .
  The name of the log file to hold errors and other messages. I usually use the name Usmt.log.




• /i .
  Identifies the INF script to use for state collection. As you can see, you can specify more than one INF script. Specify all four INF scripts if you want to migrate system, application, and user settings.

Scanstate builds a fairly hefty INF file called Migration.inf plus a folder hierarchy that contains any files identified during the scan. Copy these files to the target machine and then run Loadstate with this syntax (the entries should be on one line):

[View full width]
loadstate <
location > /v:7 /l:usmtload.log  /i:miguser.inf /i:migapp.inf /i:migsys.inf /i:
sysfiles.inf

In these command parameters, <

location > is the location of the migration files saved by Scanstate. Don't put the full path to the INF file, just the path to the folder that contains the top folder of the migration hierarchy, which is Usmt2i.umc. For instance, if the path to Migration.inf is D:\Usmtfiles\Usmt2i.umc\Migration.inf, <

location > would be D:\Usmtfiles.

After Loadstate finishes updating the machine, restart the machine to initialize the changes. If you get any errors, check the log for troubleshooting hints.