Last Update: Sep 04, 2024 | Published: Feb 04, 2013
We’re back with our discussion of utilizing Microsoft’s User State Migration Tool (USMT) as a means to save user files and settings from a failed PC. In the first article we installed the USMT and built custom XML files to control how the tool works. In this final article we’ll work on deployment and migration: bring everything together, run the tools, and get the user up and running on a new PC with their data intact.
In the first article, we left off with the ScanState tool and its basic command line structure. But before continuing, recall that the USMT files were moved into the C:USMT folder to simplify the command lines. Keeping that in mind, the basic syntax is:
scanstate {path to create migration store} /offlineWinDir:{drive letter of hard drive from old PC} /l:C:USMTscanstate.log /progress:C:USMTscanprogress.log /i:MigApp.xml /i:MigUser.xml /i:C:USMTExcludeDrive.xml /i:C:USMTInclude.xml /o /v:5
For the curious, here’s background on some of what’s going on in this command line: The .log files keep track of what ScanState.exe does, and they’re handy in the event there’s a problem. The /o switch is a safety net of sorts, telling the system to overwrite data in the storage location known as the Migration Store (if the Migration Store already exists). If data exists in the Migration Store and the /o switch isn’t used, then ScanState.exe fails. The /v switch just sets the logging level for the log files. The /v:5 option sets the logging level to include verbose and status output.
If migrating data for multiple users of the failed PC is your goal, then you’re in great shape because that’s exactly what the command above will do. If, however, you wish to grab the data for only a single user some changes will have to be made. Buckle up — things are about to get bumpy.
Survive a datapocalypse — revive files from a dead PC with USMT.
ScanState.exe has two great command line switches for picking out a single user: /ue and /ui. Use /ue:** to exclude all users and then use /ui:{username} to explicitly name the user you want. Straightforward enough, except when performing an offline migration — as is exactly the case when recovering data from a failed PC.
The problem is that in Offline mode it becomes possible that the computer running ScanState will have no means of performing a SID to username lookup, or at least it won’t think it does. Therefore, even if you specify a correct local username for /ui, you’ll come away with nada, zilch, nothing. The way around this is to use the SID with /ui… but how do you determine the SID?
The easiest way I’ve come across is to run a basic version of the ScanState command line, wait for the SID/username you’re interested in to appear, and then hit CTRL-C to terminate the command. Here’s an example: Say we’re running the USMT on a 64-bit machine, and the old PC hard drive is connected as letter G:. The USMT has been moved into the C:USMT folder for ease of use, and the data to recover is for a local user account named Michelle. The first step is to start by finding Michelle’s SID for her user account on the old PC.
To do this, open an elevated command prompt. Next, change directories to C:USMTamd64, and execute the basic ScanState.exe command line scanstate c:DeleteMe /offlinewindir:G:Windows /o /v:1. Once you see the local username Michelle, which has the old computer name in front of it (in the example shown below, the computer name is Intensity), hit CTRL-C to break out of the process.
I know this seems a bit hokey, but it works and as a bonus doesn’t require additional tools or even leave the command prompt.
Tip: The migration store used in the command line above doesn’t matter since nothing is really being stored there. Use a folder name such as C:DeleteMe so you don’t forget to get rid of that folder when your project is finished.
In my example, the user SID for Michelle is S-1-5-21-2576678085-3928563146-2067710265-1004, so the full ScanState command line to run is:
scanstate C:MigStore /offlinewindir:G:Windows /progress:C:USMTScanProgress.log /l:C:USMTScanLog.log /i:migapp.xml /i:migdocs.xml /i:C:USMTInclude.xml /i:C:USMTExcludeDrive.xml /ue:** /ui:S-1-5-21-2576678085-3928563146-2067710265-1004 /o /v:13
The elevated command prompt is already open and in the C:USMTamd64 folder, so everything’s ready to run ScanState. Type the command, hit Enter, and watch as the USMT goes to work. If all goes well, when it’s finished collecting data it will return a status code of 0 indicating everything is peachy, as shown below.
Great! All the user data for Michelle from the old system is now safely tucked away ready to be put into place on the new system. The USMT LoadState.exe tool is responsible for this part of the process. This command line will be built using many of the same options and .xml files used for the ScanState.exe command line. There’s one catch: ScanState can be run from any PC or even a USB drive, but LoadState must be run on the PC where the user files and settings will live. In other words, run LoadState on the user’s new PC.
Tip: If you run ScanState on a different PC than the user’s new PC, create the Migration Store on a network share that the new PC can access. ScanState can use UNC paths, so \serversharemigrationstore is a valid path for the Migration Store.
The LoadState command line will include a couple new switches: /lac and /lae. The switch /lac will create the local user account from the failed PC on the replacement PC. The account is created without a password unless you specify after the switch, as in /lac:{password}. Since /lac creates only a disabled local account, the switch /lae is used to enable the new account. A new password must be set when logging into the new PC for the first time with the account created by LoadState.
Tip: LoadState deals with passwords in clear text, so do NOT use a password with the /lac switch that you wouldn’t share with the whole world. Whatever you use, immediately login with the new account after LoadState completes and set a secure password for the account.
The syntax for LoadState is straightforward:
loadstate {path of migration store created by scanstate} /l:C:USMTloadstate.log /progress:C:USMTloadprogress.log /i:MigApp.xml /i:MigUser.xml /i:C:USMTInclude.xml /lac /lae /v:5
As with ScanState, when a 64-bit PC is used to run LoadState, the command will be run from the C:USMTamd64 subfolder. Otherwise, on a 32-bit system run the command from the C:USMTx86 subfolder.
To restore Michelle’s data, run the LoadState command on her new 64-bit PC from an elevated command prompt. For this example, this is the same PC ScanState was run on so the Migration Store is located in C:MigStore and the USMT is in C:USMT.
loadstate C:MigStore /l:C:USMTloadstate.log /progress:C:USMTloadprogress.log /i:MigApp.xml /i:MigUser.xml /i:C:USMTInclude.xml /lac /lae /v:5
When LoadState completes successfully a return code of 0 is displayed.
Log off the PC, allow the user to login, change their password, and get to work. Their desktop wallpaper, documents, custom folders, Internet Explorer favorites, and more will be available, just as they were when the old PC took its last breath.
The User State Migration Tool is a great resource for deploying and migrating PCs, but with a little creativity it can add value in more unconventional scenarios. Replacing a failed PC for a user presents just such an opportunity. Take advantage of the USMT and the process need not be traumatic for either the technician or the user.
One final tip: Copy the USMT folder to a USB flash drive along with generic versions of the custom Include.xml and ExcludeDrive.xml files. You’ll have it ready to use at a moment’s notice!