USMT Failures Due To Bad Profile List Entries

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:

cscript.exe "%ScriptRoot%\MDTValidateUserProfileFolders.wsf"

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Comments (17)
  1. Anonymous says:

    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 SettingsbshirleyNTUSER.DAT) failed (3) Dumping hive list at HKEY_LOCAL_MACHINESystemCurrentControlSetControlhivelist… [REGISTRYMACHINEHARDWARE] => [REGISTRYMACHINESECURITY] => DeviceHarddiskVolume1WINDOWSsystem32configSECURITY [REGISTRYMACHINESOFTWARE] => DeviceHarddiskVolume1WINDOWSsystem32configsoftware [REGISTRYMACHINESYSTEM] => DeviceHarddiskVolume1WINDOWSsystem32configsystem [REGISTRYUSER.DEFAULT] => DeviceHarddiskVolume1WINDOWSsystem32configdefault [REGISTRYMACHINESAM] => DeviceHarddiskVolume1WINDOWSsystem32configSAM [REGISTRYUSERS-1-5-20] => DeviceHarddiskVolume1Documents and SettingsNetworkServiceNTUSER.DAT [REGISTRYUSERS-1-5-20_Classes] => DeviceHarddiskVolume1Documents and SettingsNetworkServiceLocal SettingsApplication DataMicrosoftWindo [REGISTRYUSERS-1-5-19] => DeviceHarddiskVolume1Documents and SettingsLocalServiceNTUSER.DAT [REGISTRYUSERS-1-5-19_Classes] => DeviceHarddiskVolume1Documents and SettingsLocalServiceLocal SettingsApplication DataMicrosoftWindows [REGISTRYUSERS-1-5-21-2007108519-768573118-610138143-500] => DeviceHarddiskVolume1Documents and SettingsAdministrator.CONTOSONTUSER.DAT [REGISTRYUSERS-1-5-21-2007108519-768573118-610138143-500_Classes] => DeviceHarddiskVolume1Documents and SettingsAdministrator.CONTOSOLocal 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 SettingsbshirleyNTUSER.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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList 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

  2. Anonymous says:

    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?

  3. Anonymous says:

    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

  4. Anonymous says:

    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

    End If

    End IF

    End If    

  5. dynas2001 says:

    I tried the more eligant solution above (qmm is causing exactly what you mentioned brizzad) and it doesn't seem to work.

    Deleting the old profile from the profile list key (old domain) does seem to get past it though. adding the /ue or /ui:newdomain* doesn't work fo rsome reason. Any ideas? Do i Have to /UE:* to stop it from trying to load any of those profiles?

  6. Anonymous says:

    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.

  7. Vincent Alunni says:

    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.

  8. James P Morgan says:

    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 –

  9. James P Morgan says:


    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 configSYSTEMPROFILE. 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 –

  10. James P Morgan says:


    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 configSYSTEMPROFILE. 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 –

  11. James P Morgan says:


    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

  12. James P Morgan says:


    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

  13. James P Morgan says:


    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.

    J P Morgan

  14. I'm using this to troubleshooting usmt issues I'm having with MDT 2010 and it is returning an error: Profile 'C:winntsystem32configsystemprofile' 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.

  15. Brizzad says:

    @WBrady1965 – Check out this TN entry:…/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.

  16. john B says:

    we have the QMM migration happening and we are in the above boat. Hoping i could avoid the qmm method above since they will not support us.

    I told scanstate to include only the proper domain (the new one) but it still fails.

    Any ideas?

Comments are closed.

Skip to main content