XenDesktop 5 answers our questions but raises new ones about XenApp

In my previous post I speculated how Citrix would plan to support Windows 2008 R1 and R2 DDCs.

With the recent announcements at Synergy Berlin on XenDesktop 5 Citrix’s strategy on supporting these OS’s in the next release of the product is becoming clearer.

No more XenDesktop IMA

The IMA service, that XenDesktop 4 was built upon, and has been the foundation infrastructure service of XenApp since the dawn of time, is being replaced with a new web-service in XenDesktop 5. This should remove the scalability limitations of IMA to allow XenDesktop farms to contain many tens or even hundreds of thousands of virtual desktops.

No mixed farms

We’ve already seen a move to not supporting mixed farms with the release of XenApp 6, where instead of allowing servers running the new version to join an existing XenApp 5 farm, you have to create a new farm, and provide aggregation of the two environments to the user using Web Interface. Citrix provide a migration utility for moving configuration settings and published applications from one environment to another, but you need to manage two distinct environments until your migration to XenApp 6 is complete.

This trend will continue with XenDesktop 5 due to the vast differences in architecture so it won’t be possible to have a mixed farm containing XenDesktop 4 and 5 DDCs or VMs.

Are new farms an issue?

Those who have been working with XenApp, Presentation Server or Metaframe for any length of time will already know that performing migrations to new versions via a new farm became the Citrix-recommended approach once Web Interface could connect to multiple farms to provide the application aggregation into a single view for users. So, from that perspective the requirement to create a new farm to migration is nothing new, and we’ve been doing it for years, but creating new farms does introduce challenges:

New SQL databases

As a new farm requires its own database, you will need to involve your DBA’s to get these created. For large enterprise environments that have multiple farms around the world this means multiple new databases, or for those with large complex replicated data store artchitecures this can be a large piece of work.

Parallel administration

With each new farm you add, there is a new admin console to manage it and training on how the various support staff, helpdesk, 2nd line, 3rd line etc all access this new console. Delegated administration and permissions need to be configured in the new farm to match (and hopefully improve on) the previous environment.

More images

If you use Citrix provisioning services to deploy your Xen infrastructure, each new farm means a new image to manage. This has to be maintained, patched etc and adds admin overhead to your release management cycles.

Retained legacy

We’re often keen to deploy the new stuff, but migrating 100% of users across to it can be painfull and often take considerable amount of time and resouce. Businesses may take the “if it ain’t broken, don’t fix it” approach and choose to stay on the existing stable platforms. This means legacy farms often hang around for many years, with noone taking ownership of them and funds long dried up to move anyone off them.

All these scenarious add cost and complexity to the environment.

Where does this leave XenApp?

Citrix have talked about moving XenApp to the new management platform and away from the old SQL blob-based datastore for a number of years. Now they have made this jump with XenDesktop (to iron out the version one bugs on a far lesser used platform?) I would expect the next release of XenApp to move to this model and require you to have a seperate farm without IMA and with a different datastore model.

This does raise the question of whether one should even start to move existing XenApp 4/5 farms onto a XenApp 6 platform if another big farm-wide move is on the cards for XenApp v.next. Should one wait and then only have to do one farm migration? Windows 2003/2008 server and XenApp 4/5 will be supported for quite a number of years to come, and going by Citrix almost-annual major release cycle, we could well see this new XenApp architecture appearing later in 2011.

Version explosion

Having customers on so many different platforms is going to be a stretch for Citrix developers and Engineering. If you look at the existing, and potential future branches of the XenApp code base you will see that producing hotfixes and service packs will become a major resource drain, sucking resources from producing the “new stuff” we all expect from our annual SA payments:

1. XenApp 4.5/5 on 2003 – supported until 31/03/2013
2. XenApp 5 on 2008 R1 – supported until 31/03/2013
3. XenApp 6 on 2008 R2
4. XenApp v.Next without IMA?

Each of these platforms have subtle differences requiring different binaries, hotfixes and service packs. XenApp 6 is vastly different with a new policy engine and different integration with RDS. I don’t ever remember a time when Citrix had this many versions of XenApp as supported production platforms.  Which platforms should Citrix release new features on? There is a vast expanse of XenApp 4.5/5 on 2003 who don’t need to upgrade (or can’t because of the jump to 64-bit OS would break too much).

We’ve already seen a new enhancement pack for printing released for XenApp 6 only – is this trend going to continue? Will there be any more “feature packs” for customers still on XenApp 5? I would imagine so, but the feature set of XenApp is going to get so complex across the four “flavours” it’s going to be a nighmare for support.

Is this going to be a problem for Citrix over the next few years? Time will tell.