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.
3 Comments
Hi Helge,
Thank you very much for dedicating a response (just seeing this now)!
Merging and scanning for deltas sounds more intensive than simply copying & streaming indeed.
I’ll state a known fact – the current architecture is better for most scenarios.
Still I’ll argue that there are a few scenarios (mainly Task Workes) where the mandatory architecture has more benefits.
I’ll try to explain; maybe you could change my mind once and for all :)
For several organizations with thousands of Task Workers all using the same set of applications – The move from legacy PS4.0 architecture using the “unofficial” UPM1 with mandatory profile to state of the art XenApp 6.5 with UPM4.x was painful.
Regardless of the amount of educated use of GPP, UPM exclusions, Folder Redirections etc. the following “Forgotten” issues suddenly appeared:
* The new profiles share was much larger than the old one, by several factors for some
* “Profiles inconsistencies” started to show again (Usually ending in the deletion of a profile by a the support team in order to “fix” the application..)
* HKCU keeps getting larger each user
* “Junk” files just keep finding their way to the user’s profile
* Probably one or two more issues I do not think about at the moment.
Of course we all know all of these issues but back then using UPM1 with mandatory and picking just the few files and registry settings needed for each user eliminated them entirely.
For these customers of ours (Banks, Telecom – lots of call center employees) upgrading to XenApp 6.5 with UPM4 was actually a step back. “Profile Problems” has returned.
What are we missing?
Can you really say Mandatory + Deltas has no other benefits than central management (which I agree is unappealing) ?
There is certainly a value to profile management solutions based on mandatory profiles. I would say those are typically “simpler” scenarios with a small set of applications where the administrator wants to control a large part of the environment. You described it well.
My guess is, though, that for most scenarios the “sync all” approach is better, partly because it is much easier to set up (no inclusion lists), especially with a large application set.
Just remembered something important – In the above mentioned situations we used UPM1 in “Include” mode (If I recall the term).
I.e. – no need for massive delta scans for changes and merges. Only specified regkeys and files were saved.