There are two primary components to a user’s profile – registry information and files.  This article will focus on the registry portion where last write wins becomes an issue.  While session sharing will mitigate this issue since only a single profile will be loaded (e.g. one session being shared by all apps equals one profile), there will be scenarios where multiple sessions occur or may be required and thus the potential for last write wins.  Specifically I will discuss the differences in how User Profile Manager functions over traditional roaming profiles when it comes to managing the NTUSER.DAT file (the user’s registry settings also known as the HKEY_CURENT_USER or HKCU registry hive). 

During logon the NTUSER.DAT is copied down to the local machine the user is logging on (as well as the profile’s files).  The NTUSER.DAT file contains the user’s registry settings (HKCU) that are unique for every user (user being defined as a security account GUID).  The exception is when a mandatory profile is applied where all users share the same NTUSER.DAT (but then it’s renamed to NTUSER.MAN).

During logoff, a roaming profile will copy the entire NTUSER.DAT file back to the central network share.  In this situation, the last session to end will have its NTUSER.DAT file saved.  Thus any settings in the ‘previous’ NTUSER.DAT on the network share will be lost if it happens to have changed since being copied down to the current session.  If the user has modified any profile settings in any of their active sessions, then the NTUSER.DAT file will have changed since the original version was copied down.

The difference with User Profile Manager is it will scan the current user hive (HKCU) and only writes back the changed registry settings.  User Profile Manager does this is by loading the ‘centrally stored’ DAT file called the ‘user store’ (file name is %USERNAME%.DAT) within the user’s active session (in other words with the currently active HKCU hive) and performing a diff against that HKCU.  The results of the diff are then written into the user store.  It does not overwrite the previous NTUSER.DAT file.  So is this good?  It seems good, so let’s take a closer look and see.

Let’s look at roaming profiles and User Profile Manager using a simple example.  I have two separate XenApp sessions – one session has Microsoft Word and the other has Microsoft Excel (work with me for now on why there would be two sessions).  I make changes to my Microsoft Word application settings in the first session.  In the second session I make changes to Microsoft Excel application settings.  I close out the Microsoft Excel session first.  My roaming profile unloads and the NTUSER.DAT file is written back to the network share replacing the existing copy.  Then I close out the Microsoft Word session.  And again the NTUSER.DAT file is then written back to the network share replacing the one just copied back from the Excel session.  I’ve just lost my Microsoft Excel settings.  While I’ve used Microsoft Office applications for simplicity sake, this would be true for any two applications in this scenario.

What User Profile Manager does is as simple as easy: only save the net changes and merge them to the user store.  User Profile Manager’s method is to scan the registry for changed settings and then write these settings to the user store DAT file on the network share.  Thus User Profile Manager ‘merges’ these changed settings into the user store instead of categorically copying back an entire DAT file over any previous DAT file at each logoff.  Thus different sessions being logged off will have their net changes written back to that central DAT file.  Goodbye to last write wins!