How to get Citrix Cloud ready for disaster recovery

Jo Harder explains what it takes to make a secondary location work for DR purposes.

No one really expected a widescale pandemic that would spread across all corners of the globe. Events like these, however, further reinforce the need for a rock-solid disaster recovery plan to address your Citrix Virtual Apps and Desktops deployment. A proper business continuity plan aims at mitigating business disruptions to keep operations going in the occurrence of an unplanned event.

What are your Plan B options in the event that Citrix Cloud experiences a failure at one of its Points of Presence (PoPs) or the primary datacenter housing your Citrix workloads is suddenly unavailable?

PoPs and Core Components

Citrix Gateway Service is now serviced from 15 PoPs throughout the world; Canada was just added in late March. In addition to multiple PoPs per geographical region, these PoPs are hosted by more than one cloud provider, which provides additional redundancy.

Citrix takes responsibility for redirecting user connections automagically such that administrators do not need to configure or act upon any changes when an outage occurs. Citrix’s SLA for Citrix Cloud is 99.5% of uptime, and status for each region and service is posted on

Even after the Gateway Service and other core components are appropriately redirected by Citrix, access to the workloads, more often called VDAs (Virtual Desktop Agents), is necessary. After all, what good is it for a user to initiate a session if no virtual applications or desktops are available?


Within the Policies tab of the Studio console, zones should be configured to designate the logical primary and secondary locations. However, before an additional zone can be configured, a second Resource Location must be designated, and at least two Cloud Connectors should be deployed.

While some administrators may be tempted to implement a single Cloud Connector with the intention of deploying a second Cloud Connector at the time that a disaster strikes, that’s not always possible at that point in time due to networking or system load. A single Cloud Connector represents a single point of failure, and not deploying a second one in order to save a minimal amount of money may be a poorly calculated wager.

Secondary zone VDAs and application resources

Now, we get to the interesting part of business continuity planning for Citrix Cloud environments: ensuring that VDAs and application resources are available so that users can seamlessly failover to the secondary zone.

Citrix Cloud workloads can be located on premises or hosted by a cloud provider. Most often, the VDAs and backend resources, i.e., databases, file servers, and other servers, are located in the same datacenter and on the same or logically near subnet; so, for purposes of our discussion, we will discuss these as co-located resources.

VDAs can be deployed as standalone or provisioned. With Citrix Cloud, Machine Creation Services (MCS) is the only supported provisioning mechanism. In most cases, creating a gold image and provisioning VDAs is most effectively addressed using MCS. However, let’s delve into the pros and cons of this decision as related to business continuity.

Where a secondary zone has been deployed to support business continuity, saving the gold image in the second location is necessary because the primary is no longer available during the failure. Just having the gold image available in the second location may not be enough for many environments. Keeping in mind that it takes a few minutes for provisioning and registration, VDAs may not immediately be available to service user connections being directed to the secondary location. Although there is some cost and capacity associated with permanently deploying a minimal number of VDAs within the second zone, this will ensure that the first users can resume activities with little or no downtime.

Configuring Autoscale to ramp VDAs based on demand will further ensure that enough Citrix resources are available as additional users begin bombarding the system. Of course, success of the failover is also dependent upon backend resource availability, and this is largely contingent upon successful replication of those servers. Enterprise standards for replication and restoration of database servers, file servers, and other related servers should govern availability during an unplanned event.

This approach to VDA availability in the secondary zone is valid whether the workloads and resources are housed by a cloud provider or on premises. However, cloud-hosted workloads and resources offer an additional option that may impact how VDAs are created.

For example, when hosting workloads and resources within Microsoft Azure, the Azure Site Recovery (ASR) capability enables lightning-fast replication of VMs to a secondary datacenter. This solution works well for backend resources, but what about VDAs?

If VDAs are created as standalone, ASR can likewise be used to populate the secondary site. However, this means that each VDA must be created and modified individually. As such, VDAs may become inconsistent over time due to human or installation variations.

Where a very small number of VDAs exist, this approach may suffice, and the cost and functionality of ASR services as compared with a minimally provisioned secondary environment should be calculated and tested.

In general, designating a secondary zone and using MCS for gold image provisioning at the secondary location is typically the best way to proceed.


Citrix takes responsibility for redundancy and remediation of Citrix Virtual Apps and Desktops core infrastructure in the event of a disaster; however, the enterprise is responsible for ensuring that Cloud Connectors, VDAs, and backend resources are available within the secondary zone. The quantity, availability, and processes for populating the failover zone will vary according to your requirements and budget.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.