Among the more annoying deficiencies of roaming user profiles in terminal server farms is what came to be known as “last writer wins”. It looks like Microsoft is trying to address the issue in the upcoming next version of its operating systems. Although this is a step in the right direction, I have doubts about the effectiveness of the cure.
But let me start at the beginning. The algorithm currently used for synchronizing roaming profiles back to the file server dates back to Windows 2000. The past ten years have brought no improvements whatsoever. Not even Vista has a different synchronization algorithm, only a new folder structure within the profile. But that has nothing to do with “last writer wins”. So it is no wonder that numerous profile management solutions have sprung up in the terminal server space. Interestingly, most third-party solutions do not even address “last writer wins” (Citrix User Profile Manager does, of course).
What is “last writer wins” anyway?
When Windows writes a locally cached profile back to the file server during logoff, it compares each file pair’s timestamps and overwrites only older files. This approach works well in the file system, but it fails miserably with the registry, because the registry is a file system within a file. A user’s hive (mounted to HKEY_CURRENT_USER during a session) is stored in the file NTUSER.DAT in the profile. Since the registry is modified in every session, NTUSER.DAT is always written back.
This becomes a problem if a user has several parallel sessions, common with Citrix Presentation Server / XenApp. Only the registry of the last session to close will persist, since all local copies of NTUSER.DAT are stored in only one place on the central file server.
A detailed explanation of this and most other profile-related issues can be found in our white paper on the subject.
What is new in Windows 7 and Server 2008 R2?
Microsoft introduces the ability to do periodic background copies of NTUSER.DAT from running sessions back to the file server.
Let me quote the explanation from the group policy setting controlling the mechanism:
Background upload of a roaming user profile’s registry file while user is logged on
Sets the schedule for background uploading of a roaming user profile’s registry file (ntuser.dat). This setting will only upload the user profile’s registry file (other user data will not be uploaded) and will only upload it if the user is logged on. Only the registry file of a roaming user profile will be uploaded–regular profiles will not be affected. This policy does not stop the roaming user profile’s registry file from being uploaded at user logoff.
If this setting is disabled or not configured, the registry file for a roaming user profile will not be uploaded in the background while the user is logged on.
To use this setting, first choose which scheduling method to use.
If “Run at set interval” is chosen, then an interval must be set, with a value of 1-720 hours. Once set, the profile’s registry file will be uploaded at the specified interval after the user logs on. For example, with a value of 6 hours, if a user logs on at 6:00am and is still logged in at 12:00pm, their registry file will be uploaded at that time. Further, if they are still logged in at 6pm, it will upload then, as well, and again every 6 hours until logoff. The next time the user logs on, the timer will start again, so the registry file will upload 6 hours later (in our example.)
If “Run at specified time of day” is chosen, then a time of day must be specified. Once set, the registry hive will be uploaded at that same time every day, assuming the user is logged on at that time.
For both scheduling options, there is a random one hour delay attached per-trigger to avoid overloading the server with simultaneous uploads. For example, if the settings dictate that the user’s registry file is to be uploaded at 6pm, it will actually upload at a random time between 6pm and 7pm.
Note: If “Run at set interval” is selected, the “Time of day” option is disregarded. Likewise, if “Run at set time of day” is chosen, the “Interval (hours)” option is disregarded.
Uploading NTUSER.DAT in regular intervals to the file server may seem like a good idea. However, I do not see any real value in it. Changes from one session get saved periodically, ready to be picked up by a second session. But since it is one way only (local to file server), the second session must be launched after an upload from the first session to be of any value. For that, the minimum interval of 1-2 hours is far too long.
“Last writer wins” is not addressed either. Registry changes are still written as one big chunk stored in NTUSER.DAT. The main difference is that overwrites occur more often than before.
Please feel free to correct me in case I entirely missed the point of the new group policy setting “Background upload of a roaming user profile’s registry file while user is logged on”.
It looks like Microsoft did not intend to solve the last writer wins problem with the background upload of NTUSER.DAT. According to Olga Ivanova, the background upload instead is aimed at scenarios where (laptop) users log off only very infrequently or never at all while connected to the network. In such cases this group policy setting helps indeed to keep a relatively up to date version of the user’s settings on the file server that can be used if data on the laptop is lost. But in order for this to work as a backup mechanism, the files inside the user profile also need be synchronized periodically, which is only the case if they are redirected from the profile to the network and at the same time made available offline.
Commenter Maarten saw all this earlier than me. Thanks, Maarten!