Update 2010-05-07: Based on the feedback from James below (thanks James!) and similar feedback from a Microsoft Support Engineer (thanks Frank!) who hit the same failure due to Registry corruption, I’ve updated the attached script so it does not fail in these cases.
Update 2013-09-23: I've attached a new version of the script that ignores "special" profiles like System and checks for temporary profiles.
One of the main goals of the User State Migration Tool is to capture and restore data in user profiles. There are some conditions related to user profiles that may cause the tool to exit with an error. One of these is bad ProfileList entries.
Windows stores the registered user profiles on the machine in the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. The subkeys of this key, which are named after the user account SID, hold the user profile information. The physical location on disk for each user profile is stored in the ProfileImagePath entry in each subkey. If this entry in any profile subkey is pointing to a location that does not exist, USMT will fail. The most common cause of this condition is deleting the user profile folder manually using Windows Explorer instead of using the User Profiles user interface (System Control Panel, Advanced tab). Unfortunately, the USMT logs do not make it obvious that this is what caused the failure.
Since this condition is hard to diagnose from the logs, I created an MDT script (MDTValidateUserProfileFolders.wsf) that will examine all the ProfileList entries and check to see if the ProfileImagePath folder exists. It will also check to see if there are any unregistered folders in the profile storage folder (usually C:\Documents and Setting on XP/2003 and C:\Users on Vista and higher). This condition can also lead to USMT failures. If any profile folders are missing or there are extra folders in the profile storage folder, the script will exit with a return code of 1.
This will allow you to validate these conditions and take action (fail the task sequence, take other steps, etc.) if the undesired state exists. It could also be deployed in a package before the OS migration to see which machines have the issue, so a technician could remedy the situation ahead of time.
MDTValidateUserProfileFolders.wsf (included in the attached Zip file) requires that the function library scripts MDTLibSpecialFolders.vbs (also included in the attached Zip file) and ZTIUtility.vbs (included with MDT) be in the same folder. If you are using this with MDT, you can simply copy MDTValidateUserProfileFolders.wsf and MDTLibSpecialFolders.vbs to the MDT Scripts folder. You would then use it in a Run Command Line step in the Task Sequence with the command line of:
This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.
Can the error code in the scanlogs during scanstate reference an error that occurs during the migunits phase of usmt? Usually I experience this with an error code of 10 with level 7 verbosity.
I appreciate the publication of this code.
However, i ran into ONE situation where i had a PROFILELIST Registry key but it had NO SUB-KEYS? It was a Key ending in "500" but empty, on a Windows 7 32-bit image?? I updated the code to perform a "ISNULL" on the ProfileImagePath ELSE the code will abort when
it tries to verify the existance of a 'null'
path. You may want to add the check also, for others.. Again, thanks for the code.. J P Morgan - firstname.lastname@example.org
I hate to bother you again, BUT i am getting a failure using the latest MDTValidateUserProfileFolders.ZIP.
The script is FAILING on Windows 7 X64. When it checks for the "NTUSER.DAT" (new code check you added) it
says that the file DOES NOT EXIST..?? It is only doing it for the config\SYSTEMPROFILE. The 'NTUSER.DAT" DOES EXIST !!
however it displays in lowercase "ntuser.dat". The oFSO.FileExists checks for a file "NTUSER.DAT: (in uppercase).
When i change to use 'ntuser.dat" (in lower case) it DOES FIND the FILE??
Is it a Posix issues , i thought systems stored file name in BOTh upper and lower case.
Anyway, you may know EXACT reason why it fails when the NTUSER.DAT file is lowercase??
Let me know if you do.
J P Morgan - email@example.com firstname.lastname@example.org
Looks like i was WRONG about the 'lower-case' "NTUSER.DAT' causing the problem.
The WSF 'errors-out' on finding the SYSTEMPROFILE NRUSER.DAT WHEN i execute it from
a compiled AUTOIT script. When i ran manually from a command prompt or automated from
a command prompt windows it DOES NOT 'THROW" the error about NTUSER.DAT 'missing'.
I am at a loss at this time.. as to why it ONLY does it on Windows 7 X64 when
executed in a comannd prompt that was spawned from a Compield AutoIT script.
I am running using the Local; Administrator account, with UAC 'turned-off'??
Sorry to bother you.
J P Morgan
Further investigation shows that it DOES NOT give me the error with the SYSTEMPROFILE on another Windows 7 X64
system. The other ystem is Joined to a doamin, where as MY original system is in a workgroup. I tried both systems
with UAC disabled and they work the 'same' as with UAC enabled.
It MAY be 'something' about my system config, i have ALOT of things installed, including some Virtual App
Sorry to raise an issue when there may not be one.. i will perform further analysis and let you know what i find.
Thanks.. J P Morgan
Seems that i MAY have identified and resolved the AutoIT issues when running your MDTValidateUserProfileFolders.wsf
script from a Compiled AutoIt script. I had to create TWO compiled Autoit script, one for x86 and one for x64 compiled
platforms. When i selected 'compile for x64 platform' option, the resulting Autoit compiled acript that is 'wrapper'
for your scripts, was SUCCESSFULLY able to 'find' the NTUSER.DAT in the SYSTEMPROFILE folder.
Hope this helps.
I'm using this to troubleshooting usmt issues I'm having with MDT 2010 and it is returning an error: Profile 'C:\winnt\system32\config\systemprofile' does not contain a user registry hive file (NTUSER.DAT)
Notes: Our Windows directory is named WINNT
Our profiles are on D:\Profiles
For reasons I cringe even thinking about, but that is where I am. I'm not sure where to go next. There really is no NTUSER.DAT in that systemprofile directory.
Hi folks, Ned here again. Occasionally, someone pings me to explain why USMT 4.0 scanstate is running slowly. My first demand is to see the scanstate.log file, having provided the argument /v:5 . That log shows the command-line, the XML files selected, and what "slow" really means. In this particular example the cause is like Soylent Green: it's peeeeoplllllle!!! The Scenario and Symptoms Scanstate is stuck for a long time at "starting the migration process" on a production computer. Often for many minutes, even though a test computer goes through that same phase in a few seconds. The Examination and Gathering phases are as quick as a test computer. There are no errors in the console and the migration eventually completes. The scanstate.log shows many entries like: Waiting 6000 msec to retry hive load (tries remaining: 17 )... IndirectKeyMapper: RegLoadKey(HKEY_USERS,S-1-5-21-2007108519-768573118-610138143-1118, C:\Documents and Settings\bshirley\NTUSER.DAT) failed (3) Dumping hive list at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\hivelist... [\REGISTRY\MACHINE\HARDWARE] => [\REGISTRY\MACHINE\SECURITY] => \Device\HarddiskVolume1\WINDOWS\system32\config\SECURITY [\REGISTRY\MACHINE\SOFTWARE] => \Device\HarddiskVolume1\WINDOWS\system32\config\software [\REGISTRY\MACHINE\SYSTEM] => \Device\HarddiskVolume1\WINDOWS\system32\config\system [\REGISTRY\USER\.DEFAULT] => \Device\HarddiskVolume1\WINDOWS\system32\config\default [\REGISTRY\MACHINE\SAM] => \Device\HarddiskVolume1\WINDOWS\system32\config\SAM [\REGISTRY\USER\S-1-5-20] => \Device\HarddiskVolume1\Documents and Settings\NetworkService\NTUSER.DAT [\REGISTRY\USER\S-1-5-20_Classes] => \Device\HarddiskVolume1\Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windo [\REGISTRY\USER\S-1-5-19] => \Device\HarddiskVolume1\Documents and Settings\LocalService\NTUSER.DAT [\REGISTRY\USER\S-1-5-19_Classes] => \Device\HarddiskVolume1\Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows [\REGISTRY\USER\S-1-5-21-2007108519-768573118-610138143-500] => \Device\HarddiskVolume1\Documents and Settings\Administrator.CONTOSO\NTUSER.DAT [\REGISTRY\USER\S-1-5-21-2007108519-768573118-610138143-500_Classes] => \Device\HarddiskVolume1\Documents and Settings\Administrator.CONTOSO\Local End of hive list Waiting 6000 msec to retry hive load (tries remaining: 16 )... IndirectKeyMapper: RegLoadKey(HKEY_USERS,S-1-5-21-2007108519-768573118-610138143-1118, C:\Documents and Settings\bshirley\NTUSER.DAT) failed (3) Looking closer, you see 20 of these entries repeated for one or more user profiles. Cancelling processing with CTRL+C takes just as long as waiting for the pause to end naturally. You have to kill the scanstate.exe process manually if you want it to stop sooner. What is the data telling us? I’ll start Windows Explorer and regedit.exe , and then look at the user profile folder and the registry ProfileList key: If XP --> C:\Documents and Settings If Vista/Win7 –> C:\Users HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList See the issue? My file system looks like this: But my registry looks like this: Notice how there are six user SIDs in the ProfileList key, but only three user profiles on the file system. It is supposed to look like this: Where are Brett Shirley and the others? I'll tell you where: in the bit bucket, because somebody thinks that deleting a folder on the file system is the same as deleting profiles. It's not. That error we kept seeing the log is: C:\>net helpmsg 3 The system cannot find the path specified. Why does USMT keep looking? USMT 4.0 tries to enumerate each profile 20 times, waiting 6 seconds a try, before giving up and moving to the next profile. This design handled a particular third party product that temporarily locked and renamed ntuser.dat files - a user's "HKEY_CURRENT_USER" registr
could someone please help me how to set it up thru sccm 2007 task sequence so it will ignore or skip bad profiles in registery so we don't have to wait for it to retry 20 times with 6000 msec each time? we don't want to do it manually to check registery before we do OS deployment for each workstation.
thanks in advance.
Please take a look at these:
Had an issue with the system profile as well so I modified the script to skip this profile. Here is the relevant section
If instr(1, subfolder.Path, "SystemProfile", 1) > 0 then
oLogging.CreateEntry "Skipping System Profile", LogTypeInfo
If Not oFSO.FolderExists(sProfileImagePath) Then
oLogging.CreateEntry " !!Error: Defined profile folder """ & sProfileImagePath & """ does not exist.", LogTypeError
ZTIProcess = Failure
oLogging.CreateEntry " --Defined profile folder """ & sProfileImagePath & """ exists.", LogTypeInfo
If Not oFSO.FileExists(sProfileImagePath & "\NTUSER.DAT") Then
oLogging.CreateEntry " !!Error: Profile '" & sProfileImagePath & "' does not contain a user registry hive file (NTUSER.DAT)", LogTypeError
ZTIProcess = Failure
Sorry, my bad...just been checking the results and its actually now skipping all profiles, instr line should actually read as follows:
If instr(1, sProfileImagePath, "SystemProfile", 1) > 0 then
What can you do if there are two SIDs (during a domain migration) that point to the same profile path? USMT always bombs and I beleive it's because of these duplicate entries with different SIDs. We have been deleting the secondary SID (since we are imaging the machine anyway) but are being asked by the vendor who is performing the migration not to delete this second SID out of the user profile list. Is there a way to exclude profiles based on SIDs? Do you have any thoughts as to any work arounds?
@WBrady1965 - Check out this TN entry: blogs.technet.com/.../usmt-and-invalid-user-mapping.aspx. This isn't a straight-forward explanation, but you are correct - the multiple entries are the cause of USMT bailing.
If you are performing a Windows 7 deployment in the middle of a cross-forest active directory migration, you may have some logistical challenges on your hands. The vendor likely wants both SID entries present, until they have completed the user migration - and have all users logging in with their new domain credentials. Until that is done, you may require *both* entries on he machine. If the migration is being done via QMM - you can use VMOVER.EXE in cleanup mode (Cleanup=Yes, and Profiles=Yes) in the VMOVER.INI file to remove the legacy domain SID's from the ProfileList key for you.
Otherwise - reference that URL I mentioned above, as it does explain how USMT can be used to capture profiles for a specific domain sid, and ignore all others. That may be the more elegant approach, if the AD Migration is not yet completed.