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.