On a customer site visit a year or so back, I had a nice tour of the companies first level support tool (singular).  A simple user interface, web based management tool built on top of MFCom and apparently proven very successful.  On the first panel they look up the user name. 

Then there were two buttons on the screen.

  1. Force close of all XenApp sessions.
  2. Obliterate the roaming profile; a flat out RD /S /Q

That’s it – there were no other things that level 1 does and the argument was that this handles a large portion of the user help calls.   Password reset had to be here too, but stick with me on the high prominence of option 2.

As a Citrix Architect responsible for Profile Management, I say, “hum…”.

Corrupt User Profiles are a thing of the past! ?

This particular customer was moving from Microsoft Roaming Profiles to Citrix Profile Manager and reporting that the later was providing a nice reduction in forced profile obliterates, but it was too early for us to all jump up and down and celebrate how successful this would turn out to be and this is only a sample set of 1.  I need more.

Here’s my question?  Is Citrix Profile Manager really that good?

Frankly, I don’t know the answer, but I’m hoping that in reading this post, you will tell me if I’m right or not.  If you used to obliterate 100 profiles per day before Citrix Profile Manager, how many are you deleting now?  Why are they being erased?

Yes – this is a “high risk” post.  Please tell me why my product sucks…. Or, make me happy and tell me how it has helped you make profile problems go away. 

I’m half convinced that much profile erasing is actually done as a standard step of getting users running again and I will lay a wager that much of it is unnecessary.  But, if the user couldn’t work before and then they can work, then there was something unhappy in the profile.


Citrix CTP and Sepago Profile Architect Helge Klein wrote an excellent piece a couple years back on the difference between “Profile Corruption” and “Profile Inconsistency”.  His argument is that the idea of a “corrupt” profile is a myth; profiles do get inconsistent, but rarely if ever do the files and registry get “lost” or corrupted by the operating system. 

What happens most commonly – and here, I’m talking base operating system’s Roaming Profiles is that things get out of sync between the HKCU registry and the USERPROFILE disk. 

When that happens, a well coded application deals with it and fixes at runtime. Many applications don’t handle it too well and the result is an application that doesn’t work.  Then, the user calls their help desk, option “2” is selected to obliterate the user’s profile and then everything works again. 

What a draconian measure!  One small problem to fix with one application and it is solved by wiping out ALL of the user’s settings.  But, the user is running again and this is good.

Syncing HKCU Registry

Microsoft Roaming Profiles have improved with each release of the operating system and I’ll say that today, they deserve far less of the massive blame that they have received for all problems over the last 10 years. 

Here’s the problem.  In olden times, Roaming Profiles had some serious “last logoff wins” problems.  Going back to NT 2000, the user profile file system and HKCU registry were written to the central store on logoff without regard to other sessions the user may have.  A flat out overwrite. 

In a world of desktop PCs, this might be enough.  Roaming Profiles assumed the user would logoff of a first computer before logging onto a second computer and for Desktops, this might work.   In a Terminal Services XenApp world, this is a disaster, the users will almost always be logged onto more than one computer simultaneously.   

In Server 2008, Roaming Profiles are much better, the file system is synced back to the central store and this helps alleviate much of the trouble.  BUT, the HKCU registry is still COPIED back to the central store in its entirety so you get a world where the file system is relatively intact, but the registry is as it was for the last logoff and this is a classic opportunity for a “profile inconsistency”. 

My stuff is awesome

Citrix Profile Manager does a few things that help this out.

  • The user profile file system is SYNCED to/from central profile store.
  • Only things that were “changed”, “deleted” or “created” are candidates for adjustment to the central store.  It is not a blind sync.
  • The HKCU registry is also merged.  That’s a big win.

The second and third bullets above do great things to alleviate profile inconsistency.  We ASSUME users will be logged onto a whole bunch of computers at the same time and we SYNC file system and registry to protect against last logoff wins problems.  We are also aware of the existence of other sessions and over all, it’s super sliced bread kind of stuff that synchronizes LOTS of stuff, with very little day to day maintenance or per-application knowledge required.

My question
Is the customers first level support “profile obliterate” tool still useful?  I’m not saying that they’ve stopped using it, I’m asking if it has any value?

If you were a base operating system Roaming Profiles shop before and you are now a Citrix Profile Management shop, what were your observed experiences related to profile inconsistencies?

My best possible answer to hear is that we don’t really worry about it. We installed Citrix Profile Manager at the start and might update it occasionally, but for the most part, we leave it alone.   That would be a happy event, but I expect to hear other.

Blast away.  If you’d like to be less public, send me a direct email.  Joseph.Lastname at Citrix.com.

Joe Nord