Ned here again. As odd as it sounds, when you call Microsoft for USMT 4.0 support, you will be sent to the Directory Services team. This is because we support user profiles loading and unloading, as that is a core piece of interactive logons. It’s a tangled web.
Believe it or not, I support more than just DFSR. Really!
DS engineers at Microsoft also have to know about other dependencies USMT can take, such as the Windows Preinstallation Environment (WinPE). You can run USMT 4.0 within a WinPE session so that your scanning process takes place with the source OS completely offline. It’s a pretty slick new feature and we have some straightforward steps in the “Offline Migration with USMT 4.0” guide.
As with any new feature, some common questions start cropping up. Because Windows 7 is being deployed at insanely high rates USMT is becoming a hot topic. Below are some errors people frequently see with USMT running offline migrations in WinPE.
Error: “The subsystem needed to support the image type is not present”
This error is caused by running a 32-bit version of USMT within a 64-bit WinPE image. There are two rather obvious solutions to this:
1. Use an x86 version of WinPE when running an x86 version of USMT.
2. Use an x64 version of WinPE when running an X64 version of USMT.
It’s fine to use x64 WinPE and USMT to run a scanstate on an x86 offline OS. Always remember to specify the environment variable for the offline OS architecture being scanned. This variable is:
MIG_OFFLINE_PLATFORM_ARCH=<32 or 64>
For example, if the offline OS being scanned was 32-bit Windows XP, you would specify the following in the WinPE command prompt that is about to run scanstate:
Return Code 29: “A minimum of 250 MB of free space is required for temporary files”
You see this error even if you have forty bajillion GB free. When you examine your scanstate log you will see something to the order of:
2009-12-01 15:04:25, Info [0x000000] USMT Started at 2009/12/01:15:04:25.187
2009-12-01 15:04:25, Info [0x000000] Command line: scanstate z:store /offline:c:usmtoffline.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:5 /encrypt /key:****
2009-12-01 15:04:25, Status [0x000000] Activity: ‘MIGACTIVITY_COMMAND_LINE_PROCESSING’
2009-12-01 15:04:25, Status [0x000000] Activity: ‘MIGACTIVITY_AUTO_GENERATE_OFFLINE_VERSION’
Info [0x000000] Drive X: has 30 MB free; a minimum of 250 MB is required[gle=0x000000cb]
Info [0x000000] Failed.[gle=0x000000cb]
Info [0x000000] A minimum of 250 MB of free space is required for temporary files[gle=0x000000cb]
Info [0x000000] USMT Completed at 2009/12/01:15:04:26.078[gle=0x000000cb]
Info [0x000000] Entering MigShutdown method
Info [0x000000] Leaving MigShutdown method
This error will appear even if you are running scanstate.exe on the source computer’s local hard drive. The problem is that you’re missing a required environment variable that must be set in the WinPE CMD prompt in order to execute an offline migration. Use the following environment variable:
USMT_WORKING_DIR=<some non-WinPE path>
For example, to specify the physical computer’s C:temp path to act as the temporary storage space, run:
Naturally, you would also see this error if not using an Offline migration and the source computer hard drive really was out of disk space, or was exceeding disk quotas.
Return Code 36: “Use /offline to run gather on this platform”
This error is especially weird because the /offline switch is only available within scanstate.exe, not loadstate.exe. If you try to follow the error’s suggestion to use /offline in the loadstate, you get a new error:
An error occurred processing the command line.
loadstate ##ERROR## –> /offline
Undefined or incomplete command line option
The real problem is you’re running loadstate within the WinPE session, which is not possible. Loadstate must always be run within a running target OS, never in WinPE.
Scanstate /UI /UE rules with user names are ignored
Consider the following command being run in an offline migration:
Scanstate.exe c:store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:contosonedpyle /ue:** /i:migApp.xml /i:MigDocs.xml /v:5
You would expect that /ui:contosonedpyle and /ue:** would cause the Contoso domain user NedPyle to migrate, and all other user profiles to not migrate. When run, no user profiles are migrated at all. The same exact migration run on the same computer in an online migration works perfectly and only NedPyle is migrated.
This behavior is both expected and unavoidable. The WinPE computer has no knowledge of the domain and no way to perform SID translation. Specifying /ui:domainusername or /ui:*username is therefore an invalid command. If only the scanstate tool would tell you this!
To work around the limitation, you must use a SID in your /ui or /ue arguments. All profiles are defined in the registry as SIDs, and without the need to translate a user name USMT will work fine. So this would give the desired result:
1. The SID of my contosonedpyle user is S-1-5-21-1405795100-2172710363-725018148-1112.
2. My command-line to include this user but exclude all other users in an offline migration would be:
Scanstate.exe :store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:S-1-5-21-1405795100-2172710363-725018148-1112 /ue:** /i:migApp.xml /i:MigDocs.xml /v:5
To figure out SIDs I recommend the old reliable psgetsid.exe tool.
Want to know what all these cryptic error codes mean? Make sure you book mark the USMT 4.0 return codes matrix.
Hopefully the info above saves you a headache someday in your quest to deploy Windows 7, the greatest OS we have ever made.
- Ned “two trick pony” Pyle