Last week I published a blog post around ProfileUnity named: The future looks bright for User Environment and Workspace Management, which, looking at the numbers was very well received – if you’ve missed it you can find it here. Today I’d like to focus on a more specific, and well-known issue that has been with us for many years and does tend to cause some headaches from time to time: the last write wins. Again, this will underline the power and flexibility that ProfileUnity brings to the table.
Last write wins, you say?
If you have been in IT for some time you’ve probably come across the last write wins’ ‘challenge’ once or twice. Before we head over to how ProfileUnity can help, I’ll start with a brief explanation.
During user login, the user profile is copied down to the local machine the user is logging on to, this will include a file named NTUSER.DAT. The NTUSER.DAT contains the user’s registry settings (HKCU) which are unique for every user. Among other things, it will hold the users’ personal application settings.
According to Microsoft, the NTUSER.DAT is a “central hierarchical database” that contains information about the software, hardware and user profiles contained on a computer.
If we take traditional Roaming Profiles as an example, when a user logs off the NTUSER.DAT file will be copied back to a central file share, from where it was loaded, to begin with. If during the session, the user has made any changes to its profile, the existing NTUSER.DAT file will be overwritten (timestamps are compared). Something, which under ‘normal’ circumstances is what we want to happen, otherwise we would lose the changes made. When a so-called mandatory profile is used this doesn’t apply since all users will share the same NTUSER.DAT, renamed to NTUSER.MAN. Nothing is written back to the network share.
What happens
However, the problem with the NTUSER.DAT is that it is seen and treated (by the Operating System) a single file, while it holds settings for all our individual user/application settings. Since the NTUSER.DAT (almost) always changes, it will (almost) always be overwritten on logoff, as highlighted above as well. When a user has multiple sessions on multiple machines, the user’s profile will also be loaded at least twice. If changes are made in both sessions, let’s call them session 1 and 2, one will eventually overwrite the other.
When session 1 ends, the NTUSER.DAT file will be copied back to the network share, while session 2 is still active. Now when session 2 ends, the NTUSER.DAT will again be copied back to the network share like before, overwriting all settings that came down with the NTUSER.DAT when session 1 ended, assuming changes to the user profile/applications were made.
This happens because even though the NTUSER.DAT holds individual user/application settings, in the form of HKCU registry entries, it is still seen as one single file by the Operating System, meaning the time stamps of the individual NTUSER.DAT files will be compared and the one that’s most recent wins – hence ‘last write wins’.
When using RDSH based multi-user solutions, combined with published applications, having more than one version of your user profile active at the same time isn’t that uncommon. So-called workspace aggregators are also becoming more popular. While they do a great job at hiding the ‘back-end’ complexity providing your users with a single store/interface from where they can access all their resources – files, applications, desktops and more – if no proper action is taken issues like ‘last write wins’ might arise, potentially causing problems you can easily live without.
So, who wins? Well… We do
This is where ProfileUnity shines. We handle the user profile in a different way. No longer is the NTUSER.DAT seen, treated and saved as a single file, at least not in the traditional sense like I just described. We can break down and scan the user profile file by file and thus do the exact same thing with all registry related data. On a per application level, we can extract and load registry Tree’s and Sub-keys, including the values and data they hold.
For many years, we have been offering enhanced simultaneous user login capabilities. In fact, this dates back to ProfileUnity version 4.8 over six years ago. Like the rest of our portfolio ProfileUnity has evolved over the years and as it stands today we can get extremely granular when it comes to inspecting the user profile in a file by file manner.
By applying something we call ‘write by application level’ we are able to intelligently review the contents of a user’s profile at logoff to determine if changes have been made, and to only write back changes to those applications that have been altered. This reduces logoff times and avoids common ‘last write wins’ conflicts.
ProfileUnity offer features like file and registry isolation (as part of our Profile Portability engine) as well as pre, and post-login trigger points to make all this possible. User profile information, like individual registry values and data, can be saved or loaded on-demand, when an application starts or closes, for example. Of course, a trigger point can do much more than that, they can be configured for use by all available ProfileUnity modules – you decide what happens, and when it happens.
The level of granularity you apply is up to you. Save registry related information on a Tree, Key or Sub-key level, or you can go as far as the values and/or data they contain. This works for HKCU as well as HKLM.
By combining these types of technologies, we come to the principle of registry injection, which is what we do when it comes to loading user and application specific settings during, or post login. We do not alter the NTUSER.DAT file directly, instead, we inject registry related information through it (merge, replace, exclude). And while this may seem, and sound simple, in theory, some serious work has gone into this throughout the last couple of years.
Click image to enlarge
Concluding
I hope this article helped in explaining the ‘last write wins’ scenario and how this can easily cause issues in production environments. Next to that, I’ve also highlighted yet another ProfileUnity gem, which some of u might not have been aware of.
In one of my upcoming blog posts I will discuss, in a bit more detail why the Windows 10 Operating System is not the ‘one OS to rule them all’ and how technologies like our Profile Portability engine can help customers in tackling the challenges that come with migrating to Windows 10, for example but also what to be aware of once you have migrated to Windows 10, because it does not stop there.
