Understanding and Troubleshooting the Windows Temp Profile
Posted by William Diaz on February 17, 2011
When there is a mismatch between the local profile of a domain user and the network profile, you are going to run into a scenario where the user is logged on with a temp profile. The problem becomes apparent when the user sees only a standard desktop, which is missing their previous saved customizations and personal settings. This profile is created from the Default user account in C:\Documents and Settings\Default User + the settings applied by group policy and logon scripts. When this occurs, it is important to know why so that we can identify the problem and correct it.
When you logon for the first time with a new profile, that profile is created in C:\Documents and Settings\username. As you begin working and personalizing the desktop, programs, Windows appearances, connecting to printers, etc, these settings become a permanent part of your profile. In an environment where roaming profiles are enabled these personalization’s are also written to some network location (e.g. the local office file server) so that they can follow you to other workstations you log on to. Your roaming profile is composed of various folders and files copied from your local profile, e.g. Favorites, Contacts, Application Data, and most importantly ntuser.dat, also known as HKCU, the part of the registry that contains all your configurations. The roaming profile is written to the network profile when you log off each time and any changes made locally are merged to the profile on the network share afterwards. The next time you logon to that workstation, the profile on the local computer and network are compared. If there is a mismatch, then you run into a Windows logon prompt similar to this.
Often times this is related to a permissions issue on a folder or file or a missing folder or file. Sometimes the message contains the path to where the mismatch occurred. At this point, the user is logged on as TEMP. The purpose of this is to protect the user’s profile from becoming further modified.
When the issue is not clear from the logon prompt, you can turn to the Windows Event Viewer to find the issue and correct. Here is an example where we did just that. The events can be found in the Application log of the Windows Event Viewer and manifest themselves as Errors with a source of Userenv:
If you open the first error from the bottom, the cause presents itself:
There is an exe file (more on that later) that resides in the network share of the profile that does not reside in the local profile. To preserve the local profile, it is backed up and Windows will attempt to log on to the backup (username.domain)*. In failing, the user is instead is logged into a temp profile. The following two events demonstrate this:
To resolve this, simply navigate to the network profile and delete the file in the description of the event above, yeawl.exe:
If this were a legitimate file, then do the opposite and copy it locally or back it up and then delete it. Afterwards, reboot the system and log on should proceed normally.
Now that we know the why, it is worth looking into how we got here. Again, the Windows Event Viewer provides the details. Scrolling down before logon we see this:
At 4AM, the local McAfee scan starts. 4 minutes into the scan it finds a yeawl.exe, a Trojan, in the local documents and settings folder of the user and deletes it. However, when the user logged off the previous evening, the exe still resided on system and since its location is included with the roaming profile, it was copied to the network profile during that log off. When he logged on the next day, the profiles are compared and yealw.exe is missing on the local profile, resulting in the logon problem in the beginning of the article.
*In some cases, a backup profile looks like a temp profile. When this happens, you can still recover the original profile. See here.
Windows Explored 
Griz said
Thank you for your excelent explination. I was able to find the problem, but it my case it is a bit more involved. It is a GPO issue. The description states: “Windows cannot access the file gpt.ini for GPO” I have not found out anything helpful on the web about this problem and windows tells me, although they have an Event ID (1058) for this they curredntly have no help for it. Hmm typical. The policy that is in the error string is missing from the sysvol folder on the domin controler, but I do not find any such policy in the registry on the local workstation. Any ideas?
William Diaz said
Is this happening only with a single workstation? Does it apply to any domain account logging onto the workstation? Assuming it is workstation specific, I would start by running Autoruns and see what startup scripts are loading; this will be the first thing you see at the top of the list and you can quickly jump into the registry from here. Did you manually search the registry for the CN ID in event 1058? Other things to check are to run rsop.msc and right click both Computer and User Configuration and select Properties. Anything out of the ordinary there? And last, run process monitor and enable boot logging. When done, search the log for the string of the the CN you are seeing in event 1058.
Griz said
First , Let me thank you for your quick response. It is happening to a few workstations, but some domain accounts can log in ok. I will be running Autoruns on the affected boxes as soon as they are free again. I just downloaded Autoruns and am checking it out on an extra workstation in my office as I have never worked with it. I will post when I have run through your suggestions. Sadly I am not part of the IT department anymore, but with cut-backs I am the most experienced tech here so … I appreciate your help.
William Diaz said
Locate the OU the domain accounts that experience the issue are located in and see what policies are being applied, assuming you have access to AD (it sounds like you may not anymore). Perhaps there is a policy on one of the OUs that is no longer present in sysvol and needs to be removed.
Griz said
OK, I believe I have a handle on this problem now. The AD is in bad shape due to too many inexperienced techs trying things, but that is is another issue altogegher and not what was causing the temp profile to load. I should have looked further into the event viewer to see another file in another path that did not belong and the local profile was looking for it. (the mismatch you spoke of). Anyway it seems I can solve these as they come up now. Thanks for your help and thanks for showing me the Autoruns program. It will be valuable for other things as well.
TEMP Profiles vs Username.domain Profiles « Windows Explored said
[…] These are often created when the local profile and the roaming profile are not the same. For example, a user logs on to their normal workstation and as the local profile is compared against the roaming profile, some file is missing, or some folder or file security rights in either of the profiles have been modified that do not allow it to be read or written so that both the profiles cannot be merged. An example of mismatching profile can be found here. […]