Beware of roaming user profiles

Date:June 30, 2005 / year-entry #169
Orig Link:
Comments:    38
Summary: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...

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.

Comments (38)
  1. Matt says:

    My first experience with roaming profiles was at school with NT4. I was using some computers that were prevented (by helpful administrators) from saving files to anywhere except for the Desktop. I was running massive simulations, so I used multiple computers at the same time, saving everything to multiple Desktops. Well, I logged off from all of the computers, and because I managed to logoff last on the computer with no useful files on the desktop, when I logged back in to the same user, I found–no useful files on the desktop! In my harried state after 12+ hours of simulations, I had naively assumed that the desktops were not cached, or would do some sort of file merge or something. Apparently not. Dataloss, indeed.

  2. The hive unload problem is even worse. The hive keeps a reference to the user’s token.

    Because of this, if you’re running with certain 3rd party authentication systems that enforce single sign on (you can only be logged into one computer at a time), the leaked hive means that the user can never log onto another computer until this computer is rebooted.

  3. asdf says:

    Your example seems like an insane thing to do. If I understand you correctly, the program is given an absolute path to the file to begin with and you’re suggesting we should take that path and map it to a path relative to the %USERPROFILE% (if it actually is relative to that) if it needs to store it?

    The dumb thing (IMHO) about CSIDLs are that barely any of them are mapped to environment variables so you either have to convert it to an absolute path when writing it or write out the CSIDL and the relative path (unless I’ve missed something). If you ever have to present that path to the user to edit, it always is in absolute form and your app is supposed to be clairvoyant now to decide if the user now wants it relative to that CSIDL still or as an absolute path. Environment variables (or something similar) would have made it much cleaner.

  4. I might bitch about eating our own dogfood, but a lot of the time it’s actually pretty damn tasty.


  5. boxmonkey says:

    As far as I’m concerned, roaming profiles are broken technolgy.

    Does not work as intended. At my company, we found that it caused way more problems than it fixed, so they decided to abandon roaming profiles (after spending 3+ years trying to get them to work properly) and moved back to local profiles in all cases except for the mandatory roaming profiles, which are the only ones that ever worked properly.

  6. PatriotB says:

    Then there’s the issue of "Application Data" vs. "Local SettingsApplication Data." The former roams with the profile by default, the latter does not. Many apps put everything in Application Data when certain things should be in Local SettingsApplication Data so they don’t add unnecessarily to the size of the roaming profile.

    One prime example of this is Firefox’s cache. It is stored in Application Data.

  7. Ben Cooke says:

    Hmm. I’d never actually used roaming profiles before, and just assumed that they’d mount the remote profile directory rather than copying it and syncing it. What happens if a user logs in to two systems at once?

    I think I can see now why my old university didn’t implement roaming profiles: they had different software everywhere depending on which department was responsible for a given set of computers and students often logged in on several machines simultaneously. I suppose also the fact that it was a hetrogenous environment with Macs and UNIX boxes as well as Windows machines played into it, though some degree of interop was obtained by having global "home directories" which mounted as $HOME on the UNIX machines and H: (which was also "My Documents") on the Windows machines. I’m not sure what it did on the Macs, as I never logged into one.

    It’s a shame, though, that roaming profiles don’t work better. I’m always cursing and weeping when I have to use someone else’s computer, or another one of my own that I’ve not applied my lastest favorite configuration change to, or the latest upgrade to my web browser, or whatever. I just wish that all machines in the world would work the way I want, regardless of whose machine it is and without me having to maintain them all separately. Not really feasible in practice, but in an ideal world…..

  8. KJK::Hyperion says:

    Why use roaming profiles at all, in this time and age? In Windows 2000 a new group policy was introduced that redirects the "roamable" parts of user profiles to an UNC path on each logon (there remains the issue of registry hives, which can’t be loaded over a network and must be still roamed the old way – are they at least merged key-by-key, or the most recent hive wins as a whole?)

  9. irf says:

    I haven’t used roaming profiles very much, but it’s always seemed to me this would only really work if all the apps were also installed as part of the roaming profile. Otherwise, once you get past cosmetic things like wallpaper and color schemes, there are just too many things that can cause inconsistencies, even if the apps are written "correctly" (which I bet many (most?) are not). But if you do all that it seems like it’s getting closer to a full-blown terminal-server model than a roaming profile model. Still, anything less than seems impractical to me.

    I have had some experience with environments where "My Documents" is mapped to a network path instead of the local drive, and while I do recognize the benefits of this for backup and even roaming purposes, even this causes problems. Things that come to mind are my inability to create shared folders there, and the fact that managed apps that are built there run with restricted security policy. It’s also really hard to find that path when I’m connected over VPN, if I don’t happen to remember it.

  10. Mike Swaim says:

    We had problems with roaming profiles, too. A user would log into a machine, customize our app, and then log into a second machine, not see his customizations, and call us to complain.

    This happened fairly often since our users ran 2 machines w/ 3 displays per machine.

  11. Bill says:

    I have always wondered why there isn’t something more like NFS mounted home directories in *nix under windows? I have tried setting up roaming profiles, but even in a small setup (200 users, 100 machines) the wasted bandwidth, disk and time were huge and the ability to log in to multiple machines and use the same files on both was missing entirely.

    It seems to me that every peice needed to make this happen is in there somewhere.

  12. mallardtheduck says:

    I tried roaming profiles once, worked fine when all the machines were similarly-configured NT4 boxes. Then I upgraded one to 2000 for testing purposes, when I logged in with my NT4 profile on the 2000 box it worked, but when I logged back into the NT4 box it had messed up my taskbar settings and caused the ‘Network’ control panel to vanish in such a way that I eventually had to create a shortcut to the cpl file on my desktop.

    Cross-OS version roaming profiles? BAD IDEA.

  13. pcooper says:

    I love roaming profiles. I just wish that more programs knew enough to use Local Settings/Application Data instead of just Application Data.

    Google Earth wants to install most of itself, including its cache I think, into my roaming profile. So does Opera, as well as most Java programs that I’ve seen.

  14. Yoni says:

    One thing I hate about Windows is the name of the home directory.

    C:Documents and SettingsYoni

    How does that make sense? In POSIX: /home/Yoni

    You may argue that you can shorten that to %USERPROFILE%.

    The immediate counterargument is bash’s: ~

    You said:

    "In particular, that file that used to be at C:Documents and SettingsFredMy DocumentsProposal.txt has moved to C:WINNTProfilesFredMy DocumentsProposal.txt."

    This is not a feature that programs should look out for. This is a design fault of roaming profiles in Windows. The directory should be the same, always.

  15. Moz says:

    I assume this breaks most dreadfully if there’s not enough disk space for the profile on the target machine? On a related note, is it possible to shrink the ntuser.dat file? I find that after a while that file gets very big and fragmented.

    What if I save a document as %USERPROFILE%…

    Should the app call PsychicUntanglePath() to find out whether that file should roam?

    Or does that break at the first ..? Or should the app resolve it to an absolute path before trying to match it against all the various system paths (&PROGRAM FILES%, %WINDOWS% etc etc)

    And for a real laugh, move your My Documents folder and watch lots of programs break. Even just to d:My Documents. I only did that once. Ditto putting Program Files on D: (hello the Office team, are you there?)

  16. Ben Cooke says:

    My "My Documents" directory is at "L:My Documents" (it’s a mounted network path from some other machine on my LAN here)

    I’ve never had any considerable trouble. I guess, though, that not really using any programs that treat that directory as special helps. I think that it’s true to say that most of the programs I use under Windows these days aren’t really proper Windows programs.

  17. Moz says:

    I suspect that when you first moved it some things broke. But from experience, every time I move it some things break. Too bad if at work I have it on C and at home its on D.

    This is different from not allowing a "c:program files" folder, which itself is enough to break some programs.

  18. Norman Diamond says:

    One machine had one single hard disk which had been partitioned as one single partition (a whopping 504MB), so Windows 95 and Office 95 were installed on C:.

    Another machine had two hard disks which could not be merged into one logical single partition in Windows 95, so Windows 95 was on C: and Office 95 was on D:.

    Roaming partitions brilliantly kept the Start menus in sync.

    If I recall correctly, it wasn’t even necessary to have any applications and it wasn’t even necessary to have more than one partition on either machine. Just have one machine with all default settings from the Windows 95 installation log in to the domain, log out, and another machine with all default settings from the Windows 95 installation log in to the domain. And vice-versa. The registry from the Japanese machine would get shoved into the registry of the US machine and vice-versa. The Japanese machine could understand 90% of the characters that got shoved into its registry but not vice-versa. In neither case was the result pleasant.

    In neither case did we have to worry about getting to the stage of "Indeed, if your program behaves badly enough,"

  19. pUnk says:

    Release Engineering dept. will be happy – a new item for the readme:

    1. Not compatible with "large fonts".

    x. Not compatible with roaming profiles.

  20. Michael says:

    Many apps put everything in Application Data when certain things should be in Local SettingsApplication Data …

    > One prime example of this is Firefox’s cache. It is stored in Application Data.

    The bug (active since 2000) was marked as fixed; supposedly next major release of Firefox should fix it (it took them just 6 years :().

  21. Rune Moberg says:

    Sort of related:

    In ("Windows User Experience Guidelines") it says under "uninstallation":

    "Remember to remove registry entries and shortcuts your application may have placed in the Start menu hierarchy. However, when removing your application’s folder structure be careful not to delete any user-created files"

    Well, "registry entries in the start menu" aside; Does this mean I should wipe my app’s registry entries under HKCU, or should I consider these "user-created files" and leave them alone?

    I expect that when dealing with roaming profiles, after uninstalling my app on computer A the user still expects to retain his settings when logging onto computer B to run the app from there.

    So… Preserve everything under HKCU then? Many uninstallers fail to do this.


  22. foxyshadis says:

    "On a related note, is it possible to shrink the ntuser.dat file? I find that after a while that file gets very big and fragmented."

    There are a lot of programs out there that can defragment the registry (and MFT and such). Personally, I use system mechanic to do it at every startup, but I don’t think it works for server editions; I know there are many others. I think some of them just call an nt function, but I don’t know what.

  23. Ben Cooke says:


    You can’t rely on the home directory being /home/USERNAME on a UNIX system. At the university I mentioned in an earlier comment, the home directories (which, if you recall, are mounted from elsewhere) are at /ufs/fsb04/users/USERNAME, where fsb04 is the name of the server my home directory happened to live on. Also, most systems have root’s home directory at /root rather than /home/root. Far better to just use $HOME, and not start second-guessing the system.

  24. Daniel says:

    My experience with roaming user profiles has beem very traumatic. You see, when you create an user, the default is XP is to use a roaming profile. If you logoff or shutdown before changing this setting, your profile is saved in your domain controller. Ok, now one year latter I got a brand new computer, and the first time I log on the network it will load that old profile. Oh, and did I mention that I live in Brazil and my first PC had a Brazilian-Portuguese XP and the second one an English XP? When I had a look in the mess at the Start Menu my first thought was to do a complete reinstall (actually, I just logged as local Admin, deleted my user, deleted the saved profile in the domain controller and started all over). I work in a small company and it is very commom for someone to log into someone else’s computer. When you log the first time in an XP computer, we have to remember to turn off the !@#$%&* roaming profile.

  25. DWalker says:

    One thing that, crazily, doesn’t even take into account your OWN LOCAL location for Documents and Settings is when you download a saved MSDN Webcast.

    You end up downloading an EXE, which is a self-extracting file created with WinZip. It asks you "Would you like to download the presentation onto your desktop?" [download here means extract]. You can’t supply another path.

    If you say yes, it unzips the WMV into a *hardcoded* and unchangeable location of C:Documents and SettingsAll UsersDesktop.

    MY computer happens to have its "all users" desktop at C:Documents and SettingsAll Users.WINDOWSDesktop, but do the people who package the MSDN Webcasts for download care? Apparently not.

    I have e-mailed them to ask what all this madness is, and we’ll see what their response is…

    David Walker

  26. Mike Owens says:

    Regarding the home directory on Unix-ish OSes, $HOME is not guaranteed to be set, and its use sometimes leads to problems very similar to the issues discussed here on Windows. (Usually trying to write in /, or just putting everything in the cwd).

    The normal way to attain the user’s home directory is use the pw_dir member of the struct passwd returned by getpwuid or getpwuid_r. You can check out some docs here:

  27. Universalis says:

    For moderate user-friendliness in "last used file" lists, is there an inverse of ExpandEnvironmentStrings() anywhere, or do we have to roll our own?

    It wouldn’t solve everything, but at least it should help with the %USERPROFILE% case.

  28. Steve Loughran says:

    I dont really care that my code doesnt work with roaming profiles, as I have never encountered them to work properly.

    1. I may have different policies on different boxes, and I dont want them to move.

    2. on a big site (i.e. mit), you dont want your profile cached on all the machines; you end up with a purging system

    3. no adequate merge of multiple profiles. Its too built around the "one user, one machine" model, and not "one user, one laptop, 3 VMware images and two remote desktop logins"

    I use groove to sync a large directory tree across all my windows boxes, all personal stuff lives there, where it is synchronized seamlessly round the world. One XP VM in the office acts as the always-available master, and also runs spambayes on outlook 7×24 to filter spam. On the laptop the directory tree is nailed down with encrypted files, the key held in the laptops TPM. It all works really well.

    Instead of blaming us developers for not supporting roaming profiles, lets all just recognise that they have always been broken, and move on.

  29. I might bitch about eating our own dogfood, but a lot of the time it’s actually pretty damn tasty.


  30. Stefan Kanthak says:


    don’t confuse %UserProfile% and %HomeDrive%%HomePath%!

    The latter can be set in the user account and defaults to %UserProfile% if not.

    So just configure your system as you like, but don’t complain that you don’t know its options.

    Moz (and others):

    %ProgramFiles% (and %CommonProgramFiles% too) as well as the parent directory of %UserProfile% and %AllUsersProfile% can easily be moved away from %SystemDrive% and work as expected.

    You just have to do it right: from Windows 2000 onwards use WINNT.SIF to redirect these folders (or correct ALL references in the registry and user profiles when you these directories later on).

    I’ve dozens of installations here where neither a C: nor a D: drive exists, %SystemRoot% resides on E:, %ProgramFiles% on F: and the user profiles on G:.

    It’s even possible to separate %ProgramFiles% and the user profiles from %SystemRoot% WITHOUT changing the path: reparse points exists, I can prepare a hard drive with 3 (primary) partitions and mount #2 and #3 into Program Files and Documents and Settings on #1 before I start the setup.

    Yes, there are some evil programs resp. their installers which have "C:Program Files" hardcoded, but they would fail on every non-english installation where "Program iles" is localized too!

    These are the programs that I discard. If their vendor is not flexible enough to adapt to my liking he won’t earn my money.

    It’s that simple.


  31. Things you ought to do though you may not personally benefit from it.

  32. I read Raymond Chen’s post entitled How do you convince developers to pay their "taxes"? with interest….

  33. Not all folders in the user profile are stored in the user profile.

  34. It’s not free, so spend it wisely.

  35. So the question that came in was along the following lines: We have Windows Server 2003 installed with

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index