One of the less-known features of Windows is the roaming user profile. I know that this is not well-known because I often see suggestions that fail to take the roaming user profile scenario into account. Indeed, if your program behaves badly enough, you can cause data loss. (More on this later.) What is a roaming user profile? Well, your user profile is the collection of things that reside under your %USERPROFILE% directory. (This is not quite true, but it’s a good enough approximation for the purpose of this discussion. An important exception will be noted next time.) Your per-user registry is kept in %USERPROFILE%\ntuser.dat, so your per-user registry is part of your user profile. In highly managed environments (corporations), system administrators can set up user profiles on a centralized server, so that users log onto any machine and have available their files and settings. This is accomplished by copying the user profile from the server when the user logs on and copying it back to the server when the user logs off. (Of course, there is also caching involved to save time if the user logs back onto the same machine.) What does this mean for you, the programmer? For one thing, it means that the path to the user’s profile can change from one logon session to the next. If the user runs your program from Computer A, their user profile directory might be C:\Documents and Settings\Fred, but when they log off from Computer A and log on to Computer B, the directory to their user profile might change to C:\WINNT\Profiles\Fred. In particular, that file that used to be at C:\Documents and Settings\Fred\My Documents\Proposal.txt has moved to C:\WINNT\Profiles\Fred\My Documents\Proposal.txt. If your program has a feature where it offers a list of recently-used files (or auto-opens the most recently used file), you may find that the file no longer exists at its old location. The solution is to use profile-relative paths, or even better, shell virtual folder-relative paths (e.g., recording the path relative to CSIDL_MYDOCUMENTS), so that when the profile roams to a machine with a different user profile path, your program can still find its files. For another thing, you cannot just cruise through the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry key expecting to find all the user profiles and possibly even modify them, because the copy of the user profile on the local computer might not be the authoritative one. If the profile is a cached roaming profile, then any changes you make will either (1) be lost when the user roams back to the computer after using another computer, or (2) cause the local profile to be considered newer than the master copy on the server, causing the changes the user made to the copy on the server to be lost! (Which of the two bad scenarios you find yourself in depends on the time you change the cached profile and the time the target user logs off that other computer.) Another consequence of roaming user profiles is that your program can effectively see itself changing versions constantly. If Computer A has version 1.0 of your program and Computer B has version 2.0, then as the profile roams between the two computers, both versions 1.0 and 2.0 will be operating on the user profile in turn. If versions 1.0 and 2.0 use the same registry keys to record their settings, then your registry formats had better be both upward- and downward-compatible. This is a particularly painful requirement for operating system components, which consequently need to maintain bidirectional registry format compatibility with systems as old as Windows NT 4. (Windows NT 3.51 had a different model for roaming user profiles.)

Yet another consequence of roaming user profiles applies to services. Prior to Windows XP, if a service holds a registry key open after the user logged off, then the registry hive cannot be unloaded and consequently (1) consumes memory for that profile even though the user is no longer logged on, and (2) prevents the user’s local registry changes from being copied back to the server. This “hive leakage” problem was so rampant that in Windows XP, the profile unload code takes a more aggressive stance against services that hold keys open too long. You can read more about the changes to registry hive roaming in the Resource Kit article linked at the top of this entry.