27 Jun 2008 04:17 PM EDT

posted in XenApp by David Wagner

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!

Permalink | Comments (6) |

What if it is the same setting? How does UPM decide which one is the final? In this case, Word and Excel is a good example because they share common MS Office settings like fonts for example? Would the last dated change win?

Hello Henry,

If a user did change the same setting to two different values (a different value in each session), it would then come down to which session has that setting written back last.  I'm not sure how to ever get around that situation since it is the same setting (e.g. checking time stamps on which setting was set last and assume that is the one the user desires and intends?).  As long as the settings in question are different registry keys then this would not be an issue.

Thanks

I wonder if situations might happen where the merge of NTUSER.DAT updates cause conflicts, how would the UPM handle them?

Posted by Anonymous at Jul 02, 2008 06:12 | Reply To This

Are you asking if a registry key is added that conflicts with other registry keys?  Then you would need to configure UPM to exclude that registry key causing the conflict.  If the registry key is a must have for the user's profile, this sounds like an application that requires isolation due to application conflicts (e.g. Application Streaming and Isolation).

Or are you asking what happens if the user changes the same setting to different values in two different sessions?  In that case the last session to logout would have it's setting saved.

I wonder whats going to happen with the files in a profile. You talked about registry settings which get saved as

%username%.dat in a central location, where are the files saved/copied?

I implemented UPM in our test env. I could see a dat file getting created in the central share, but could not see any files uploading to the shared central drive. 

The default location is the same as the DAT file (in the user's home directory).  Files and folders are synched using SMB.  The configured profile folders (as defined in either the INI file or the GPO) will be synchronized during logon and logoff events.  There will be an 'spBackup' folder in the same directory as the DAT file which will contain the profile files and folders being synched (or if configured, archived in ZIP format).