User State Migration Tools
Published: November 19, 2001
Sharon Crawford covered the Files and Settings Transfer Wizard in an earlier column. She describes how this wizard helps the home and small business user move to a new computer with less pain and a whole lot less reconfiguration time. Although the Files and Settings Transfer Wizard is a huge help for individual users, it doesn't really fit the needs of the enterprise IT department. A large corporate department needs to deploy large numbers of computers in a consistent and repeatable fashion while minimizing the amount of Help desk support required. For this task, the User State Migration Tool (USMT) is the ticket. It supports migration of individual user settings from Windows 95, Windows 98, Windows NT Workstation 4.0, and Windows 2000 Professional to a new installation of Windows XP Professional.
By default, the User State Migration Tool transfers almost the same files and settings as the Files and Settings Transfer Wizard. What sets the USMT apart are two important differences:
| • | It is configurable for each environment, using INF files to control exactly what files and settings are transferred. |
| • | It is scriptable—the USMT uses two command line tools to control the saving and re–populating of the user's files and settings. |
The two command line programs that USMT uses are ScanState.exe and LoadState.exe. These programs can read from INF files to allow the system administrator to control exactly what gets migrated and how, collecting or leaving specified files, folders, registry entries, or registry subtrees. There are seven INF files included with the USMT. These files can be modified or additional files added to control specific applications and registry settings. The seven included files are the following:
migapp.inf
migism.inf
migsys.inf
miguser.inf
migwiz.inf
sysfiles.inf
usmtdef.inf
The command line for saving the user's settings can easily be included in a script the user is given to run before leaving for the day, or can be pushed to individual computers from a central server and run at a scheduled time:
scanstate [/c] [/i:inffile] [/l:logfile] [/v:verboselevel] [/f] [/u] [/x] <intermediate store>
where:
| • | c—continue past errors |
| • | i—INF file. Multiple INF files are supported. |
| • | l—log file |
| • | v—verbosity level from 1–7 with 7 being the most verbose |
| • | f—transfer the files specified (default is to include this action. This switch is primarily for troubleshooting) |
| • | u—transfer the user settings (default is to include this action. This switch is primarily for troubleshooting) |
| • | x—don't transfer user settings or files. Again, primarily for troubleshooting |
| • | intermediate store—the server location to transfer the settings to. |
The command line for restoring the user's settings, which can easily be included in a script and which must be run by someone with administrator level privileges is:
loadstate [/i:inffile] [/l:logfile] [/v:verboselevel] [/f] [/u] [/x] <intermediate store> with the meanings the same as for ScanState.
So what is the advantage in using a command line to save settings? If you're going to migrate one or two computers only, not really all that much—you can just do it. But if you're going to migrate as few as a dozen or up to several hundred or thousand, you don't want to go around to each person's computer and do the dirty work. Or expect the user to do it right. With the USMT, you configure exactly what you want to migrate, decide where to store the stuff (figure 50 MB for a typical user, but give yourself room for those users who have more than that), and then decide when you're going to do it. Test the configuration and scripts on a couple of sample computers, and when you're ready, run the whole process in a straightforward fashion. You get the user to fire off the save script, do a fresh install of Windows XP on each computer, and then run the reconfigure script to bring the user's files and settings back. When the user logs on the next time, the process will complete.
The only time–consuming part of this is the installation of Windows XP itself, and that can be automated either by using disk–imaging software or by installing automatically over the network if you are set up for that. A well–prepared IT team can easily accomplish the whole process over the weekend, reducing your company's downtime to essentially nil. It takes planning and preparation, and a team that understands how to do a whole lot of things all at once, but that is, after all, what good IT is all about.
