Inside User Profiles

After the system creates a user profile, the system doesn't write it to the server until the user logs off. When the user does log off, Windows first checks to see whether certain parts of the profile aren't supposed to roam. By default, anything stored within the History, Local Settings, Temp, or Temporary Internet Files folder under the user's profile aren't copied to the server and won't roam. These files include things such as temporary files cached by Microsoft Internet Explorer (IE) and certain application-specific data such as Outlook offline store files (.ost files). You can add to the list by setting an Administrative Template policy on the computer within a Group Policy Object (GPO). You can find this policy under User Configuration\Administrative Templates\System\User Profiles\Exclude Directories in Roaming Profile.

One big improvement that Win2K made to the process of writing user profile changes is the default behavior when Windows copies files to the roaming profile on logoff. In NT 4.0, Windows copied all files in the profile to the server during each logoff, regardless of whether all files had changed. In Win2K or later, Windows compares the date stamps and timestamps of the files in the local and roaming profiles to determine which ones need to be written on logoff, then writes only those files. This approach results in much quicker logoff times than in NT 4.0 and more efficient use of the network. The OS also looks for changes when the user logs on, so if something has changed on a user's server-based roaming profile that's newer than the user's locally cached copy, the system writes the changed files at logon.

Controlling Behavior
You might want to change certain user profile default behaviors for your environment. I've already mentioned that you can use Group Policy to alter which folders within the profile roam and which don't. You can also change policies that control profile behaviors related to how the system responds to a slow link when downloading the profile from the profile share. If Windows detects what it considers a slow link, as I defined earlier, both profile and Group Policy processing behavior will change. When Windows detects a slow link for a user who has a roaming profile, it won't load that profile from the server; instead, the user uses his or her locally cached profile. You can change the behavior of the profile under slow link conditions by using Group Policy to set policy on the machine. Specifically, you can change some policy settings under Computer Configuration\Administrative Templates\System\User Profiles that control this behavior. For example, if you enable the Prompt User When Slow Link Is Detected policy, the user will receive a dialog box at logon that offers the option of waiting for the roaming profile or using a locally cached copy of the profile. You can also use the Logs User Off When Roaming Profile Fails policy to prevent users from being able to log on if they can't load their roaming profile.

You can use Group Policy to control some additional useful behaviors. For example, if you want to delete the locally cached profile of every user who logs off a Windows machine, you can enable the Delete Cached Copies of Roaming Profiles policy under the policy area I mentioned in the previous paragraph. This policy is especially useful on Windows terminal servers, on which you might have many users logging on to the machine and consequently many cached profiles that take up disk space.

You can also set a size quota on user profiles. Remember that the profile can contain files in addition to settings. These files can grow quite large and, if those profiles roam, they can consume a lot of server disk space when written to the user profile share and can significantly slow down logon and logoff. In some cases, you might want to limit the ability of the user to stuff things into a profile, and you can use profile quotas to set this limitation. You can set a profile quota policy within a GPO under User Configuration\Administrative Templates\System\User Profiles\Limit Profile Size. Note, however, that doing so can be problematic in some environments because legitimate reasons might exist for a profile to grow, and preventing it from doing so could adversely affect the user's ability to do his or her job.

Troubleshooting Guide
I've seen many types of problems with user profiles, and certainly, the problems worsen if you've deployed roaming user profiles. However, certain tips and tools can help you get a handle on the problems in your environment.

The first thing to understand is how user profiles behave under unusual conditions. For example, what happens if a user has a roaming profile specified but no locally cached copy, and Windows can't access the roaming copy? In XP and Win2K, the system creates a temporary profile from the default user profile for the user under \%systemroot%\documents and settings\temp to let the user continue working. However, when the user logs off, the system discards the temporary profile; as a result, any changes made to the profile are lost.

Here's another common scenario. What happens if two users with the same username log on to a workstation—will one of the user's profiles overwrite the other? The answer is no, but the reason is less than obvious. Remember that each locally cached copy of a profile registers itself by the user's SID in the registry, ensuring that the problem I just mentioned doesn't happen. Two identical usernames won't be a problem because the SIDs will be different. However, where does the system store the second profile? The answer is that Windows appends the domain (or workgroup) name of the user to the folder path that's created under the Documents and Settings folder. For example, let's say that you have a jsmith defined in the AD domain mycompany
.com (NetBIOS name mycompany) and another jsmith account defined on the local workstation named workstationA. The local workstation-based jsmith logs on to workstationA first, and local user jsmith gets a profile created under \%systemroot%\documents and settings\jsmith. Then, the domain-based jsmith logs on to the same workstation. Windows creates a profile for the second jsmith under \%systemroot%\documents and settings\jsmithmycompany to identify the origin of the account. It's confusing but effective.

Almost every Windows shop I've come across experiences one big problem with user profiles for which no good answer exists. Sometimes, as the user is logging off of a system, the system doesn't fully unload the user's profile. Some process running on the workstation will still have a handle open to the profile—usually to the ntuser.dat registry hive—that prevents the profile from fully unloading. This situation can cause all kinds of grief with the workstation because a user's changes within ntuser.dat might not be successfully written to the user's roaming profile or because Windows might be unable to delete the locally cached copy of the profile, if you've set that option. Additionally, if you use a tool such as delprof.exe (from the resource kit) for remotely deleting locally cached profiles, that utility might be unable to delete the local profile. The only reasonable resolution I've found is to reboot the workstation, which ultimately releases whatever handles exist to the profile. Of course, this action isn't feasible in certain circumstances. Microsoft provides at least one tool to help mitigate this situation, in the form of an XP policy to increase the number of times that Windows tries to unload the profile before giving up. This policy, which you'll find under Computer Configuration\Administrative Templates\System\User Profiles\Maximum retries to unload and update the user profile, can help if this problem is rampant in your environment.

If you're unsure about what's going on with your user profiles, I recommend you turn on verbose userenv logging. The userenv.log file is in the \%systemroot%\debug\usermode folder on all Windows 2003, XP, and Win2K machines. To enable verbose logging for both user profiles and Group Policy, follow the instructions in the Microsoft article "How to Enable User Environment Debug Logging in Retail Builds of Windows" (http://support.microsoft.com/?kbid=221833). This log file records detailed information about what's happening during profile loading and unloading and can be handy when you need to troubleshoot profile problems.

Not Perfect, but Better
Compared with the days of NT 4.0, user profiles are much improved. Understanding how they work under the covers can help you resolve problems that occur in your environment. When user profile problems arise, the default response is to delete the profile and start over, but doing so can result in time lost for both you and your users. I encourage you to use the tools I've mentioned, particularly userenv logging, to determine the problem before you take drastic action.

End of Article

   Previous  1  2  [3]  Next