Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

Failover (im)possibilities of XenDesktop 7.x Part 1

On E2EVC 2015 Lisbon I presented together with Bas van Kaam the session Failover (im)possibilities of the XenDesktop product. Personally I thought the content deserves to be written down in an article series as well based on the same principles as the presentation. Per component I will describe the past (XenApp 6.x), the current situation (XenDesktop 7.6), the near future (XenDesktop 7.7) and ideas we have about functionalities that should be added (also based on the feedback from the audience of our session). Logically I need to thank Bas for his input and knowledge during the creation of the presentation, which lead to this article series (written based on my opinions).


First let’s start with explaining where the article is actually about. Many people are using Load Balancing and Fault Tolerance in one sentence. Let’s take a look at the definitions found on Wikipedia and you will see that the goal is different.

Load Balancing is meant to ensure that the load is divided over multiple components to ensure that the system is not overloaded, where Fault Tolerance is built to ensure that if a component fails another system will take the functionality of the component. In most situations load balancing and fault tolerant are combined together as the same components are arranging both functionalities. Like many product also for Citrix you can use the rule two is one, one is none, so ensure that at least two systems host the functionality. Looking at Citrix XenDesktop you would like to have two Delivery Controllers, two StoreFront servers and at least two VDA’s (hosting the same application set) in your infrastructure. If you have one datacenter those two systems are running in at the same location and you don’t really have to think about failover anymore. However when you have two or more datacenters you need to think about failover a bit more especially in you are (still) used to XenApp 6.5



In XenApp 6.5 (and earlier) the database is an important part of the Citrix infrastructure. The Microsoft SQL infrastructure hosting the database should be available as much as possible, so it’s logical to create a SQL high available infrastructure. However the Citrix infrastructure can lost contact with the database for a while, 96 hours to be exact, so a high available SQL infrastructure is not a requirement. This is realized by a feature called Local Host Cache (LHC), which is actually a (partial) copy of the database on the Citrix XenApp Server. Sometimes there were some issues with the LHC (the command dsmaint recreatelhc is not created for nothing), but in the basis it’s working fine and solves the need to have the database up and running all of the time.


Within the FMA architecture of XenDesktop there was no Local Host Cache functionality available, causing that the database should always be available. A SQL cluster is the minimum that you need to have. When the SQL server is not available, no new connections can be made anymore to the Citrix XenDesktop infrastructure. With the release of XenDesktop 7.6 Citrix introduced a new feature called Connection Leasing. Connection Leasing is according to Citrix a supplement to a high available SQL to enable users to connect or to reconnect to their most recently used Applications and Desktops, even when the site database is available.

This sentence already states that Connection Leasing is different than the Local Host Cache. Connection Leasing is supported for server-hosted applications and desktops (formerly known as XenApp) and assigned VDI desktops. A pooled VDI Desktop cannot leverage this new functionality. As the user is redirected to the machine which hosted his session before that database outage, load balancing will not be exactly carried out. Connection Leasing has even more limitations. In this article by Andrzej Golebiowski Connection Leasing is described in detail, so check this article if you are not familiar with Connection Leasing.

As Connection Leasing is a step in the direction it’s still limited and does not remove the high availability requirement.


For the upcoming release there is no functionality shown right now. Probably there will nothing changed in the upcoming XenDesktop 7.7 release, but however you never know what is developed currently. I personally hoped they made at least the configuration of Connection Leasing into a policy instead of the manual steps, but it looks like this is not the case.

Thinking Cap

People are still asking to get the same functionality back as the LHC is providing in XenApp 6.5. That should be doable as Citrix has more products that have a fallback for a lost database like Citrix Provisioning Services and Connection Leasing is partly doing this job already. On the other hand with pooled VDIs and Power Management included some big changes should be made into the product, like communication between the Delivery Controllers. So Citrix would be doing a great job if the Connection Leasing can be further improved to make it comparable with the Local Host Cache. Time will tell if Citrix customers are asking for this so much that Citrix will continue developing on this functionality.

Access Portal


Citrix Web Interface is the Access Portal that is mostly used for Citrix XenApp 6 environments. Within the Citrix Web Interface you can add multiple farms based on multiple Data Collectors. Unfortunate Web Interface is using each configured farm to check the user credentials, so the different farms should be in the same domain or the domains should trust each other. For each farm the icons will be displayed, so setting-up a different farm for (disaster) failover is not fully handled as you would like within Web Interface product. The needs are not that large as with Worker Groups you can set something within one farm in XenApp 6. However some guys within Citrix released an unsupported add-on for Web Interface for XenDesktop version 5 and higher (https://www.citrix.com/blogs/2012/11/24/xendesktop-high-availability-load-balancing-add-on-for-web-interface/). As it is unsupported I don’t think many companies are using it.


Web Interface successor is called StoreFront. With release 3 the product now is on the market for a while and is getting really close to all functionalities Web Interface is offering (which is still supported for all Citrix XenApp/XenDesktop versions). In basics StoreFront is offering the same functionality as Citrix Web Interface. Within Citrix StoreFront 3 also the load balancing between Delivery Controllers/Data Collectors is added (or at least the test has changed from fail-over to load balanced). The difference with Web Interface with is that it’s now default enabled, where within Web Interface you had to enable the check box for load balancing.

What StoreFront offers over Web Interface functionality is the possibility to use multiple XenDesktop sites and aggregate only one icon officially. This icon will be pointing to the main site first and if there is no availability the second site (or other more sites) will be used (where by default for each site an icon will be shown). This is nice technique for failover between sites and set-up for a disaster recover. The exact steps are already written down by several people, where the Shaun Ritchie has written down all the steps in detail in the article Citrix StoreFront High Availability and Aggregation – A dual site Active Active design.

The way this is handled is really nice and a big plus for having this functionality. However you need to have two XenDesktop sites including the requirements that belong to a XenDesktop site. In an upcoming article I will discuss the (im)possibilities using one XenDesktop site.


Currently StoreFront 3.0.1 is just released and I did not add any new functionality into the product for the multiple site configuration. It needs the same manual steps into the web.config file as described in the article of Shaun Ritchie. Just before our presentation Citrix released a Technology Preview of StoreFront 3.1 which includes the configuration of the multi-site configuration based in StoreFront console (GUI). Bas tested this for our presentation and currently you can’t do all configuration yet in the GUI and editing the web.config is required. Also the way the publishing is done, could be done better. However the edocs referred already to this better way (now changed to the current functionality), so we can expect that this will be available in the final release.

Thinking Cap

Logically before the Technology Preview of StoreFront 3.1 Bas and I have written down that we would like to see that the multi-site configuration could be done via a GUI (in the studio console or the currently StoreFront Configuration utility). But as it looks like this will become available in the upcoming StoreFront edition, we don’t have any special anymore that should be added in StoreFront concerning Failover possibilities.


In this article series I’m describing the Failover possibilities within the XenDesktop product based on the server components based on the presentation I presented together with Bas van Kaam. The article started explaining shortly the differences between Load Balance and Fault Tolerance, followed to mention that one is none for the components. For each component at least two machines should hold the functionality. As the article is about (disaster) failover in the case of two or more datacenters the article continued quickly describing the component, where the past, the current situation, the near future and wishes per component are described. In this article series the database and the access portal were discussed. In the upcoming article I will continue with Published App/Desktops (aka VDAs) and the PVS infrastructure.