Microsoft Tackles the "Last Writer Wins" Problem of Roaming Profiles in Windows 7 & Server 2008 R2
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.
Analysis
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”.
Update 2009-06-17:
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!
7 Comments
Rather than syncing the entire ntuser.dat file could not MS sync bit level changes to the file? Other file synchronisation utilities (Novell’s iFolder springs to mind) can sync just delta changes to a file rather than the file itself. Not only does this save bandwidth bit in the case of last write wins as long as the same key/value was not changed previous writes to different keys/values would remain untouched.
On the negative side I suppose this could lead to an inconsistent registry if delta changes from different OSs were written back to the same file.
The registry is a file system within a file, somewhat similar to databases, which are often stored in a single file, too. In order to synchronize only changed fragments the syc code would have to look into the file on both sides and manipulate the internal structure of the .DAT file. I doubt that is easy to achieve, and it would probably require a server-side component, too.
As to different versions of Windows using the same NTUSER.DAT: the structure of registry hive files has not changed since XP, so that should not be a problem. You can still mount an NTUSER.DAT from XP on Windows 7 and vice versa.
I think this feature was not designed to fix the last-writer-wins problem, but rather to provide a fix for users roaming on and off the netwerk.
By periodically syncing the users’ registry to the server it ensures a backup copy is available if the laptop would ever crash. This feature is especially convienent now more and more people are accustomed to never logging off their system but rather just putting it to sleep.
Maarten,
I had been thinking about laptop users with roaming profiles, too, that only log on and off every few weeks. But how many laptop users are using roaming profiles? Most probably have a local profile since network connectivity is intermittent.
On the other hand, this applies to desktop PCs, too, which are not shutdown as frequently any more as used to be the case a few years back but often only put into suspend or hibernation mode.
@Helge Klein – 8:34
I could imagine this little feature could provide exactly the answer for ‘why bother using roaming profiles for a laptop’, using this feature and proper redirection of the users’ data folders this allows for lesser dataloss / configuration loss in case of an failure of the laptop.
Desktops are less of a problem because when the user eventually logs out from his or her desktop, it will be connected to the laptop, with laptops however it could be the case that people only logout when they are at home and hence being confused by their loss of data.
I agree with your analysis. I don’t think this will resolve the last write wins problem at all.