Share via

USMT Failures Due To Bad Profile List Entries

  • Article

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.

MDTValidateUserProfileFolders_v1.0.2.zip

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    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 Else If Not oFSO.FolderExists(sProfileImagePath) Then         oLogging.CreateEntry "  !!Error: Defined profile folder """ & sProfileImagePath & """ does not exist.", LogTypeError        ZTIProcess = Failure Else         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    

  • Anonymous
    January 01, 2003
    karennt, Please take a look at these: blogs.technet.com/.../usmt-pauses-at-quot-starting-the-migration-process-quot-for-many-minutes-then-works.aspx blogs.technet.com/.../setting-environment-variables-in-a-task-sequence.aspx Michael Murgolo

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    April 13, 2010
    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.

  • Anonymous
    April 23, 2010
    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 - j.p.morgan@lmco.com

  • Anonymous
    November 03, 2010
    Michael, 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. Thanks. J P Morgan - j.p.morgan@lmco.com james_p_morgan@hotmail.com

  • Anonymous
    November 03, 2010
    Michael, 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. Thanks. J P Morgan - j.p.morgan@lmco.com james_p_morgan@hotmail.com

  • Anonymous
    November 03, 2010
    The comment has been removed

  • Anonymous
    November 05, 2010
    Michael, 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 clients.. 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

  • Anonymous
    November 09, 2010
    Michael, 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

  • Anonymous
    January 14, 2011
    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.

  • Anonymous
    September 05, 2013
    The comment has been removed

  • Anonymous
    July 21, 2014
    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?