| Date: | June 30, 2005 / year-entry #169 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050630-20/?p=35143 |
| 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 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 For another thing, you cannot just cruise through the 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)
Comments are closed. |
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.
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.
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.
I might bitch about eating our own dogfood, but a lot of the time it’s actually pretty damn tasty.
For…
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.
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.
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…..
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?)
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.
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.
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.
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.
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.
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.
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%….xxx..foo.txt?
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?)
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.
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.
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,"
Release Engineering dept. will be happy – a new item for the readme:
1. Not compatible with "large fonts".
…
x. Not compatible with roaming profiles.
Sort of related:
In http://msdn.microsoft.com/library/en-us/dnwue/html/ch11d.asp ("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.
—
Rune
"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.
Yoni,
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.
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.
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
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: http://www.opengroup.org/onlinepubs/007908799/xsh/pwd.h.html
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.
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.
I might bitch about eating our own dogfood, but a lot of the time it’s actually pretty damn tasty.
For…
Yoni:
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.
Stefan
Things you ought to do though you may not personally benefit from it.
I read Raymond Chen’s post entitled How do you convince developers to pay their "taxes"? with interest….
Not all folders in the user profile are stored in the user profile.
It’s not free, so spend it wisely.
PingBack from http://www.gooli.org/blog/desktop-apps-could-fight-back/
PingBack from http://gluft.wordpress.com/2008/01/31/links-for-2008-02-01/
So the question that came in was along the following lines: We have Windows Server 2003 installed with