After we released XenApp / XenDesktop 7.6 a few weeks ago, many customers and partners are now working on upgrading their existing Citrix infrastructures. While upgrading my lab environment I realized that this common infrastructure management task is a vital aspect that gets overlooked quite often when evaluating desktop and application virtualization solutions.
Typically every 6 – 12 months, Citrix and VMware release a new version of the product, a feature pack or at least a hotfix rollup pack. In case you would like to leverage the new features / improvements, one or more infrastructure components, such as the Controller or the Agent running on each of the workers, need to be upgraded. But rolling out these changes can be a smooth ride or a bit of an adventure, depending on the vendor.
Back in late 2010 we introduced the Flexcast Management Architecture (FMA), with the release of XenDesktop 5.0. FMA is radically different from the former Independent Management Architecture (IMA), that powered XenApp 6.5 and earlier versions. With the merge of XenApp and XenDesktop over the following years, FMA is now the foundation for all Citrix desktop and application virtualization products, such as XenApp/XenDesktop 7.6. One of the benefits of FMA is that upgrades and migrations are radically simpler than with IMA in the past.
For organizations that have not adopted the FMA architecture yet, please refer to the XenApp Upgrade page for detailed information about how to get to FMA quickly.
In this blog post I’d like to compare the procedures of upgrading an existing infrastructure in Citrix XenDesktop / XenApp and VMware Horizon.
Let’s start with VMware Horizon.
For upgrading from Horizon 5.x to the newly released version 6, VMware recommends following the instructions outlined in the upgrade guide. When reading the documentation it becomes obvious that there are strong interdependencies between the various components, but very limited backwards compatibility. This forces admins to upgrade a Horizon site in a fixed order and in essentially one go (aka big bang), rather than in a phased approach, as otherwise core features remain unavailable until all components have been upgraded. For example an upgraded Composer will not provision / manage any virtual desktops with an older Agent installed. Since Composer is also not backwards compatible with older versions of the Connection Server, provisioning has to be disabled in a very early step of the upgrade procedure. After all components have been upgraded provisioning can be re-enabled. This effectively prevents the admin from creating or managing linked-clone VMs for the duration of the upgrade. Another example is Security Server, which is not compatible with an old Connection Server and would therefore not allow any remote user sessions.
Below you can find a visual summary of the VMware Horizon upgrade procedure. Please note that, in order to keep the diagram readable, I’ve just included the core steps / sub-tasks (full version here).
Now let’s focus on Citrix XenDesktop / XenApp.
When upgrading from XenDesktop / XenApp 5.6 or 7.x to the new version 7.6, we also recommend following the upgrade documentation, which can be found in eDocs.
The most noticeable difference when upgrading an FMA-based infrastructure, when compared to VMware Horizon (and older IMA-based environments), is that within a XenApp or XenDesktop site for each component +/- 1 major version is supported for production use. This means each component can be upgraded independently based on your convenience, which makes planning and performing upgrades much simpler.
This means (for example):
- If you would like to get the latest Controller features, but still have Windows XP workers (which are supported with XenDesktop 5.6 FP1 only), just upgrade the Controllers to 7.6 and leave the desktops untouched.
- If you have the need for some new HDX features, but do not want to touch the Controllers, just upgrade the respective virtual desktops or desktop catalogs.
Of course you will not get the full benefits of the new version, until you’ve upgraded all components. For example you will see the following message when selecting a new Controller feature for a Delivery Group that has not been upgraded yet:
But I believe this is very much expected behavior.
It’s important to keep in mind that the XenApp / XenDesktop migration procedure is that it is essentially non-disruptive, which means for upgrading the Controllers no downtime of the site is required. So while one Controller is upgraded and rebooted the remaining systems will keep the environment available, which enables admins to fulfill their SLA obligations. After half of the Controllers in a site have been upgraded, the site database will need to be upgraded as well, which will cause brokering of new sessions to be suspended for a few seconds.
In addition it’s worth mentioning that with XenApp / XenDesktop 7.x the version of the operating system and the Citrix software have been decoupled (unlike older XenApp versions). So assuming you are on Windows Server 2008 R2 and XD 5.6. You can upgrade the site to XD 7.6 without upgrading the operating system. Then when you are ready for the OS upgrade, you can install XD 7.6 on Server 2012 R2 add this new controller to the site and eject one of the Windows 2008 R2 controllers. Rinse and repeat until the entire site is on Windows 2012 R2. This adds another layer of flexibility to the upgrade process and enables you to perform the upgrade / migration at the speed that is optimal for your organization, rather than Citrix forcing you to complete the upgrade in one shot.
Below you can find a diagram outlining the upgrade procedure (incl. all tasks) for recent versions of XenApp and XenDesktop.
Furthermore we worked hard on simplifying the component upgrade experience. With the latest versions, every step is wizard driven and super simple (IMHO). Below you can find a short video of upgrading a Controller including the XenDesktop / XenApp site and a XenApp Worker.
XenDesktop Controller Upgrade
XenApp Worker Upgrade
In case your workers are running XenApp 6.5 and you´d like to migrate them to XenApp 7.6, make sure to check the “How to” guide for upgrading XenApp 6.5 workers to XenApp 7.6 available in eDocs.
The following table summarizes the key differences of Citrix XenApp / XenDesktop and VMware Horizon, in regards to infrastructure upgrades:
Follow me on Twitter @tberger80.