| Date: | February 6, 2006 / year-entry #48 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060206-00/?p=32383 |
| Comments: | 32 |
| Summary: | Earlier, we learned about roaming user profiles, wherein the master copy of the user's profile is kept on a central server (which for the purpose of discussion I will call the "profile server") and is copied around to follow the user as she logs onto computers throughout an organization. In the comments, many people said... |
Earlier, we learned about roaming user profiles, wherein the master copy of the user's profile is kept on a central server (which for the purpose of discussion I will call the "profile server") and is copied around to follow the user as she logs onto computers throughout an organization. In the comments, many people said that what they really want is for the files to be stored in a central location without any copying. That is what redirected folders gives you. Redirected folders are a way for a domain administrator to specify that selected folders in the user profile (for example, the Desktop, the Start menu, the My Documents directory) are not stored in the user profile but rather on a separate server (which for the purpose of discussion I will call the "folder server"). Note that this feature can be turned on independently of roaming user profiles. Roaming user profiles copies the user profile around; redirected folders let you pull folders out of the user profile. There are four combinations of these two settings, and each of them has its merits. If you've been following along so far, you already see how they interact, but I'll spell it out in pictures this time. The diagrams are color-coded as follows:
For illustration purposes, I've shown only two redirectable folders, although in reality there are plenty more.
The first case is the common case: The profile neither roams nor contains redirected folders. Since there is nothing roamed or redirected, the fact that everything is kept on the local computer is hardly surprising. This is the most common configuration on consumer machines, where there is no IT department running the show.
In this configuration, the profile is still local, but we've redirected the My Documents folder to another location. (Though just to prove a point, I left the Start menu unredirected.) Some people redirect their My Documents to another, presumably much larger, drive on the same machine. Another common configuration in this same model (local profile + redirected folder) consist of redirecting My Documents to a folder server. This alternate configuration might be seen in a corporate network so that each user's documents are kept on a file server that is regularly backed up and has shadow copies enabled so the files can be recovered easily. You might even see it in a home network if you have accounts on multiple machines but want to keep all your documents in a central location. The downside of this arrangement is that if your My Documents server becomes unavailable, you lose access to all your documents.
This is the configuration with a roaming user profile but no redirected folders. As we learned earlier, the master copy of the user profile resides on the profile server. When you log on, the server copy of the profile is pulled down to update the local profile, and when you log off, and changes to the local profile are pushed back to the server. This is the classic roaming profile configuration where all user data lives in the profile. Since the document folders are not redirected, the profile server can go offline and you can still do your work since your documents are cached locally.
In this final configuration, we have enabled both roaming profiles and redirected folders. This is another common corporate configuration since it reduces the amount of copying that happens at logon and logoff but still keeps the user's profile and documents on managed servers so they can be backed up and otherwise centrally administered. A common gotcha for keeping the files entirely on a folder server is that if the folder server becomes unavailable, you lose access to your documents. This is particularly painful in laptop scenarios where the computer spends a lot of its time not connected to the network that houses the folder server. You can use offline files, however, to make these scenarios much more tolerable. What is the lesson here? First, as we already noted when we discussed roaming profiles, one reason why you can't manipulate the profile of a user that is not logged on is that the profile you may happen to find might not be the master copy, and what's worse, modifying the local copy can result in it becoming the master, ultimately resulting in data loss when the two versions are reconciled. Second, even if you somehow manage to get the user to log on so that the local copy is the master, and even if you are running as local administrator, the user's files may have been redirected to another server where the local computer's administrator account do not have access. The upshot is that you simply cannot manipulate another user's profile without actually running in the context of that user. You need to be aware of these other scenarios where the user's data is simply not accessible. |
Comments (32)
Comments are closed. |
Interesting article. Thanks for the info here (and in all of your other articles). Good reading, even for non Win32 developers.
Keep up the good work!
I wonder whether the model is just plain broken. For example, how can a roaming model can sanely separate the registry configuration data of an app from the installed version of that app? That’s a heavy burden to lay on every Windows developer. This is a stiff tax all developers are expected to pay to support a small number of large companies–isn’t that corporate welfare? :)
You know what has a really good roaming model? GMail and other web-based apps. If roaming is a high priority, it’s probably not good to depend on locally installed apps.
"is copied around to follow the user as she logs"
Offtopic, but why "she"?
This lack of ability to manipulate a user’s profile without that user being logged in complicates my job significantly at times. Or at least it did, to the point where we decided to disable roaming profiles wherever feasible. Is anything being done to resolve this in Vista?
What sort of "resolution" are you looking for? By definition, a remote profile isn’t kept on the local machine. It’s unclear you you "resolve" a definition.
And it gets worse if you have a roaming account and you’ve ever logged into a machine with another language of Windows UI – you start getting shell folders in the new language created willy nilly that can be very hard to eliminate.
I actually discovered this *at* Microsoft when I logged onto a few "foreign
UI" machines in a test-lab to review a localization pass. The problem was apparently well known to loc-pm colleagues but not to Windows team. I don’t know if it ever got fixed.
Monday, February 06, 2006 11:18 AM by Mike Williams
> And it gets worse if you have a roaming
> account and you’ve ever logged into a
> machine with another language of Windows UI –
> you start getting shell folders in the new
> language created willy nilly that can be
> very hard to eliminate.
They break each other’s registries too, like changing UI fontnames to fonts that don’t even contain characters needed to display the Start menu, etc. That makes it time to reinstall Windows on both machines.
Even with a single language, there are neat effects when Microsoft Word is installed on the D drive of one machine, so the user’s Start menu contains a shortcut to the D drive, and then the user logs in from a machine that doesn’t have a D drive and Windows downloads a broken shortcut to overwrite a previously working shortcut.
Monday, February 06, 2006 2:21 PM by Dave
> For example, how can a roaming model can
> sanely separate the registry configuration
> data of an app from the installed version of
> that app? That’s a heavy burden to lay on
> every Windows developer.
Microsoft didn’t lay that burden on any developer, including not on themselves. The only question is how anyone could sanely use roaming.
I redirected my documents folder to my network drive on my home network. I intended to then set-it up for offline file sync. For some reason unknown to me or XP help topics I cant do this – the offline files option isntavailable. I’m just flumoxed.
What was worse, was during the initial ‘move’ process of redirecting my documents the HP ‘battery testing’ program turned of my laptop power. This interrupted the redirect move and I ‘lost’ my files (I didnt because they were backed-up). The whole experience was stressful and I didnt get the offline file sync (XP Pro)
yours sincerely
fur-rust-tray-tid of Seattle
This post looks broken even in maximized 1280×1024 IE window. What resolution was it composed for?
Wendy: Windows XP doesn’t support Fast User Switching and Offline Files simultaneously.
http://support.microsoft.com/?scid=279765
(I’m told this is fixed in Vista.)
The page looks bad because of the floating right-hand navigation thingie messing with the <BR CLEAR=ALL>. I don’t know how to fix it.
But my Lapop only has one account on it – mine. Why didnt the UX TELL me to switch off FUS (maybe I cant) off to explore now and play around with the accounts generally… oh FUN ;-)
Actually it does say that in the user interface. If you try to turn on Offline Files while FUS is already enabled, it says, "Offline Files cannot be enabled while Fast User Switching is enabled. To change your Fast User Switching setting…"
Just so you know – If you set up My Documents on a network drive, and enable Offline Files Storage, My documents is automatically flagged for offline file storage – you appparently cannot prevent this (I have empirical evidence for this on a couple of laptops – one where this was desirable behavior, and one where it was not)
How about replacing those <br clear="all"> tags with some <br clear="left"> ones…
Right, the "master copy" of the profile moves around depending on where the user is logged in. That’s why it’s called "roaming". The only way to be sure you’re operating on the correct copy of the profile is to log the user in.
==What sort of "resolution" are you looking for? By definition, a remote profile isn’t kept on the local machine. It’s unclear you you "resolve" a definition.==
Part of the problem is that XP does not obey this definition. The remote profile does end up being kept on the local machine sometimes. Then sometimes that old remote profile later overwrites the newer remote profile. Therefore, even if you have guaranteed that a user has logged off of all machines, you still can’t be sure that modifying their profile on the server will result in them *ever* getting that modification.
When the user logs off, the master copy goes to the server, as you requested. I discussed the details of how conflicts are resolved in the referenced article. Everything is "resolved" as described there. Sounds like you want roaming profiles to be redesigned – even if it were (say with "Roaming Profiles 2"), the old model would have to remain in place for backwards compatibility with existing deployments, so you as a programmer have to deal with it anyway.
Except that the master copy doesn’t always go to the server. That is, sometimes the user logs off and the profile is not copied back to the server. Sometimes the user logs on and the "master copy" is not copied from the server but instead they end up with a cached profile that was already on the machine. Sometimes that cached profile overwrites the "master profile" that was supposed to be on the server.
I would be happy with roaming profiles as they are designed if they worked as designed, but they don’t.
I can’t tell whether you’re saying that the underlying algorithm is bad or just the implementation. The implementation can be fixed; the algorithm can’t be changed for compatibility reasons.
I guess I’m saying the implementation is busted.
It sounds like the algorithm i fine, if the implementation worked properly you could manipulate a profile without the user being logged on.
No, you cannot assume the local profile is the master, because the user might be logged onto some other machine – at which point that other machine’s profile becomes the master. The local copy is stale. If you try to edit it, you will corrupt the user’s profile when they roam back to the local machine.
Yes, that should work. Too bad there’s no guarantee you have permission to access the server.
Hence my original statement that this fact is annoying and makes my job more difficult. Why can’t the "master copy" be on the server when a user is logged out? Why not make it so that an administrator can *flag* a profile as the master copy. What happens if you get 2 master copies? Go for which ever one is more recent.
That’s the kind of behavior I was hoping would be changed in Vista.
Sure there is, I’m the system administrator. And it still doesn’t work consistently.
Sorry, I think I understand now that you were operating under the perspective of a programmer or a program trying to manipulate profiles somehow, whereas I was looking at it from the perspective of a system administrator. I’m actually both (administrator and programmer), but the profile issues have only been a problem for me as an administrator.
If you’re an administrator on the profile server then go nuts.
It is possible to ensure that the user is logged off of all machines. At that point the master *should* be on the server and it should be safe to modify it from there.
To be sure that you touch every profile, current ones and for all new users on your network, you should use code that runs under the users credentials, preferably during login. A login script is perfect for touching the profile at the right moment. You can use Group Policy for that. Then there is no need for a master profile. The profile "at hand" is updated with your changes. Ofcourse computer settings should be changed outside the user context (startup scripts, services, etc.)
Being an admin myself I’ve ran in to these issues as well.
What I’ve found is that redirecting "My Documents" to a home folder and disabling cache copies of local profiles works particularly well for us.
Of course the downside is when the file server goes offline but we find that rarely happens.
The problem I hear you guys discussing happens when the local and server copy of the profiles merge. I haven’t heard about ‘master copies’ or such, but I do know for a fact profiles ‘merge’ together when there is a discrepancy.
Roaming profiles are fun arent they?
boxmonkey: Maybe this is what you’re looking for: http://support.microsoft.com/kb/q146192/