Understanding how user profiles work
If you were to ask 10 Windows administrators which part of their infrastructure is the most problematic, I'd wager that at least 5 of them would say user profiles. That number probably goes up to 8 or 9 if we're talking about roaming user profiles. Despite Microsoft's best efforts through the various releases of Windows, this piece of technology is problematic at best. So let's look at how profiles are supposed to work—with a detailed look at what happens when you create a profile and what happens when the system writes that profile to the server. Then we'll see what kinds of things can cause problems with user profiles and how you can try to avoid or correct them.
The User Profile Defined
A user profile is a set of files and folders that stores a user's personal preferences for his or her Windows desktop. For example, any shortcuts that users put on their desktop are part of their user profile, as are the preferences they select in Microsoft Outlook. Everything that's user-specific about Windows or applications running on Windows is stored in the user profile.
User profiles come in three flavors: local, roaming, and mandatory. Every user that logs on to a Windows workstation has a local profile, which by default is stored on Windows Server 2003, Windows XP, or Windows 2000 under the \%systemroot%\documents and settings\%username% folder (e.g., C:\documents and settings\joesmith). On Windows NT 4.0 machines, the local user profile is stored under \%systemroot%\profiles\%username%.
A roaming profile, as the name implies, follows the user to any workstation he or she logs on to. Windows accomplishes this roaming capability by writing the user's local profile to a designated server share each time the user logs off a workstation. If a user's profile doesn't roam, then every workstation that the user logs on to will have a different profile, potentially with different settings. Thus, roaming profiles are most commonly used in environments in which users frequently move from one computer to another and need to maintain all their settings. To make a local profile a roaming profile in Win2K and later, you simply modify the user object for a particular user in Active Directory (AD) to specify a Universal Naming Convention (UNC) path (e.g. \\s3gpo1\profiles\darren) designated as a roaming profile path, as Figure 1, page 20, shows. After you enter the path in the user object, the system writes the user profile to the designated server share at the next user logoff.
The mandatory user profile is a variation of a roaming profile. Mandatory profiles ensure that every user in an environment has the same profile. Mandatory profiles come in two variations—normal and super. A normal mandatory profile prevents users from changing any of their desktop or application preferences but still lets them, for example, put new shortcuts on their desktop or put documents in their My Documents folder. A super mandatory profile prevents users from saving any changes to their profile. Mandatory profiles are typically used in environments that require tight control over the user experience.
Regardless of the profile type, you need to remember one important thing about user profiles: The user always works from the copy of the local profile stored in \%systemroot%\documents and settings\%username% (or %systemroot%\profiles\%username% on NT 4.0). Even if the user has a roaming profile, the workstation downloads this profile from the server, caches it locally in this folder, and stores all changes the user makes to the profile during the logon session in the locally cached copy. The system writes those changes to the roaming profile when the user logs off, but, by default, the locally cached copy remains on the workstation. So, if the user logs back on to that workstation and has changed nothing on the roaming profile, the user will simply work from the locally cached copy without having to download the roaming profile again. I describe the mechanics of this process later in the article.
Under the Hood
Now let's look under the hood of the user profile. I mentioned earlier that the user profile stores the user's preferences and items such as shortcuts. In fact, the location of the user profile in XP and Win2K fittingly describes what a user profile contains—documents and settings. The documents portion of the profile can be any file-based resource that a user can store, including shortcuts, Microsoft Word documents, cached Internet files (e.g., cookies), and application-specific configuration files. If you look at a standard user profile in Windows Explorer, you'll see a directory structure like the one that Figure 2 shows.
As you can see from Figure 2, quite a few folders can store user-specific data within the profile. For example, the My Documents folder is the default location for storing Microsoft Office application documents and is a common place for users to save many other types of documents. The Desktop folder holds the contents of what appears on a user's desktop. If you were to copy an application shortcut into the Desktop folder in a user's profile, that shortcut would appear on his or her desktop. Some of the folders in the user's profile store documents that aren't necessarily visible to the user. The Application Data folder stores application configuration files. For example, Outlook uses this folder to store the layout of the Outlook screen that the user has chosen. Some folders are hidden completely from the user. As you can see by the shaded folder icons in Figure 2, hidden folders such as Application Data and Local Settings aren't meant to be directly accessible to the user by default.
The Settings portion of the user profile is stored in the ntuser.dat file within the structure that Figure 2 shows. If you open a registry editor on a Windows machine and navigate to the HKEY_CURRENT_USER hive, you'll see the ntuser.dat file contents. Ntuser.dat is a registry hive file that loads as HKEY_CURRENT_USER when a user logs on. As a result, Windows writes any changes you make to your user session—such as changing the background wallpaper on your desktop or changing an option in Outlook—to HKEY_CURRENT_USER, which is really ntuser.dat. As an aside, if you ever want to view the contents of another user's ntuser.dat file when the user isn't logged on, you can load this file into the registry as a temporary registry hive by using the load hive feature within regedit.exe (on Windows 2003 or XP) or regedt32.exe (on Win2K).
Note that mandatory profiles have a slightly different naming convention. A normal mandatory profile is one in which the ntuser.dat file has been renamed to ntuser.man. A super mandatory profile is a roaming profile in which the profile path ends in .man. For example, a roaming profile path called \\server\\profiles\stdprofile.man\ specifies a super mandatory profile.
Inside Profile Creation
The key to solving the mysteries of user profiles is to understand their wily ways, and to do that, you need to understand how Windows creates a profile. At a high level, the process is simple: If a user logs on to a Windows workstation for the first time and doesn't have a profile—either cached on the workstation or on a roaming server share—Windows creates a new default profile for that user. However, the process is more involved than you might think. Let's step through the user profilecreation process so that you can understand it thoroughly. Along the way, we'll review some details about profile creation that will help you if you ever need to troubleshoot profile problems. Because subtle differences exist in profile behavior between each of Microsoft's OS versions, I'm going to stick with XP in my example. This example assumes that a new AD domain user for whom you've defined a roaming profile path is logging on to the domain and to his or her workstation for the first time.
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.
