We’ve heard it loud and clear that most XenDesktop implementations are based on either:
•Totally new Citrix implementation based on XenDesktop only
•Existing XenApp environments that are adding XenDesktop, whether based on XenDesktop for a distinct
group of pilot users or presenting XenApp hosted apps through XenDesktop

For the latter, administrators are faced with determining if/how to reuse the existing infrastructure to make the transition smooth. If you’ve already seen the Adding XenDesktop to an Existing XenApp Environment white paper or Adding XenDesktop to Existing XenApp Environments TechTalk, you already know how to transition the Citrix features and components, but how should you transition the user profiles?

As you may have noticed, Citrix is encouraging a much more open architecture than we have in the past. We want you to successfully implement XenDesktop, and if Microsoft profiles or Citrix Profile management enable you to do that, great. If a third-party profile solution such as AppSense facilitates XenDesktop, so be it.

Many environments use Terminal Services roaming or mandatory profiles to support XenApp, which is a fine solution. But, that same profile configuration can’t be used as is for XenDesktop because a Terminal Services profile is loaded only by computers that have Terminal Services installed; XenDesktop VDAs don’t incorporate Terminal Services.

What does that mean? For example, for Terminal Services roaming profiles, that means that user settings, such as folder views, stored in the user profile can’t be applied to other computers, such as the local computer or XenDesktop VDAs, unless . . . some configuration adjustments are made. Could you point a network roaming profile to the same location as the existing Terminal Services roaming profile? Technically, yes. But do you want to do that? Maybe, maybe not.

If your users will be accessing multiple resources, i.e., XenApp and XenDesktop VDAs, at the same time, then calling the same roaming profile can create last writer wins issues. Because this type of profile saves everything, not just deltas, during each logoff, only the changes incorporated during the last session that closes down are retained; interim profile writes are overwritten. Users don’t like it when settings are “mysteriously” overwritten.

There may be operating system differences. For example, settings within a profile used to support XenApp 5 for Windows Server 2003 differ slightly when compared to Windows 7. And how GPOs are applied. And . . . well you get it. All the more reason that choosing the right profile solution is extremely important to ensure the best user experience!

Yikes, this is getting complicated!

If you’re spending too much time in Profile-ville, mark your calendar for the User Profiles for XenApp and/or XenDesktop TechTalk Solving User Profile Challenges for XenApp and/or XenDesktop TechTalk to be held on April 6th. See you there!