Citrix Profile Management Architecture - Why it is Not Based on a Mandatory Profile Any More

Ron Kuper asked in a comment why the architecture of Citrix Profile Management was changed from being based on mandatory profiles to capturing the entire profile content by default. This change happened between versions 1 and 2.

A Bit of History

Citrix Profile Management is based on the product sepagoPROFILE, which I architected and co-developed. sepagoPROFILE was a differencing solution based on a mandatory profile, i.e. the product identified which parts of the file system and registry were changed during a user session and stored those deltas in a dedicated directory per user. The reasoning behind this was that file server space would be saved since only partial copies of each profile had to be stored.

This proved to be wrong.

Mandatory profiles are typically very small. The size of a mandatory profile is negligible compared to what gets stored individually, per user, during the lifetime of a profile.

Downsides of Mandatory Profiles

With this reason pro mandatory profiles out of the way, let us have a look at the cons:

  • Merging large amounts of data into the registry at logon can be slow. This prolongs logons.
  • Scanning the registry for changes takes time. This prolongs logoffs.
  • Creating a mandatory profile is not as easy as it sounds. This complicates deployments.
  • There is no easy migration path from existing local and roaming profiles. This also complicates deployments.

Central Management of User Settings

We felt that these downsides outweighed the only really remaining advantage of an architecture based on mandatory profiles: the ability to centrally configure the user environment by changing registry values or placing icons on the desktop.

Additionally, there a much better ways to centrally manage user environments than by tweaking a mandatory profile. Either use Microsoft’s Group Policy Preferences or one of the alternatives from third-party vendors.

Switching Architectures

When sepagoPROFILE was acquired by Citrix in 2008 both teams felt that this was the perfect (and only, really) time to change architectures. While a rebranded sepagoPROFILE was released as a beta version of Citrix User Profile Manager (UPM), we modified the code to work with local profiles. That version was released as Citrix User Profile Manager 2.

Thus UPM version 1 never really existed. The first “official” version was version 2.

Comments

Related Posts

Fixing Office 2007's Quick Access Toolbars With Citrix User Profile Manager

Fixing Office 2007's Quick Access Toolbars With Citrix User Profile Manager
Not sure where user profile management might be useful? Here is an example that should apply to almost everyone. The obvious new user interface feature of Microsoft Office 2007 is the ribbon. But there are numerous other UI enhancements over Office 2003. One of these are the Quick Access Toolbars. If you are not sure what I am talking about: the following screen shot should give you an idea (from a German version of Office, sorry):
User Profiles

Citrix User Profile Manager (UPM) and the Broken Rootdrive

Citrix User Profile Manager (UPM) and the Broken Rootdrive
Terminal server application compatibility scripts have been around for a long time - so long in fact, that I considered them a legacy and stowed away any knowledge of them in a very remote area of my brain. When a Citrix customer brought up a problem with the mapping of ROOTDRIVE in the User Profile Manager forum, at first I had no clue what he was talking about. Luckily, the customer was able to pin the problem down to a specific command that failed when, and only when, User Profile Manager was processing the logon. This is the story of UsrLogon.cmd, ACRegL.exe and UPM.
User Profiles

Latest Posts