Martin Buber once said,  “All journeys have secret destinations of which the traveler is unaware.” That holds especially true for Citrix end users, since when they click on a published resource within Receiver, they have no idea how or where that back-end journey is transpiring. Of course, you, as the administrator, know exactly where the traffic is heading and the intended result for the user, but the user just wants one thing: a quick and painless experience. So how can you achieve this for your end users? One thing to consider is using zones.

To explain, let’s talk through an example. Picture an environment; let’s say you have a data center in Santa Barbara and another in Raleigh, and each of these data centers is hosting thirty Windows 2016 servers with your standard set of applications published: Microsoft Office, Skype for Business, and Microsoft Paint. You’re using the Citrix Cloud Virtual Apps and Desktops service and leveraging the Citrix-hosted Workspace and NetScaler Gateway service. This environment may look very similar to this diagram:

If you have users on the West Coast, to ensure the best end-user experience, you would most likely want any sessions they launch originating in the Resource Location closest to their home location and vice-versa with a user connecting from the East Coast. This configuration is actually quite simple to achieve and is accomplished by using zones in Citrix Cloud. Citrix Cloud makes the initial creation of a zone very easy, when you create a resource location and install a Cloud Connector, a zone is automatically created for you. This zone will include any Machine Catalogs, Cloud Connectors, Host Connections and Delivery Groups created using that Resource Location. Easy, right? But before you jump in, there are a few things you need to consider.

Considerations:

  • When a hypervisor connection is placed in a zone, it is assumed that all the hypervisors managed through that connection also reside in that zone.
  • When a machine catalog is placed in a zone, it is assumed that all VDAs in the catalog are in the zone.
  • NetScaler Gateway instances can be added to zones. When you create a resource location, you are offered the option to add a NetScaler Gateway. When a NetScaler Gateway is associated with a zone, it is preferred for use when connections to VDAs in that zone are used.
    • Ideally, NetScaler Gateway in a zone is used for user connections coming into that zone from other zones or external locations, although you can use it for connections within the zone.
  • After you create more resource locations and install Cloud Connectors in them (which automatically creates more zones), you can move resources between zones. This flexibility comes with the risk of separating items that work best in close proximity. For example, moving a catalog to a different zone than the connection (host) that creates the machines in the catalog can affect performance. So, consider potential unintended effects before moving items between zones. Best practice is to keep a catalog and the host connection it uses in the same zone.
  • If the connection between a zone and Citrix Cloud fails, the Local Host Cache feature enables a Cloud Connector in the zone to continue brokering connections to VDAs in that zone. (The zone must have StoreFront installed.) For example, this is effective in an office where workers use the local StoreFront site to access their local resources, even if the WAN link connecting their office to the corporate network fails. For more information, see Local Host Cache.

Ensure that you configure your zone preference for users appropriately. There are three forms of zone preference. You might prefer to use a VDA in a particular zone, based on:

  • Where the application’s data is stored. This is referred to as the application home.
  • The location of the user’s home data, such as a profile or home share. This is referred to as the user home.
  • The user’s current location (where the Citrix Receiver is running). This is referred to as the user location. (User location requires minimum StoreFront 3.7 and NetScaler Gateway 11.0-65.x.)

For more detailed information on determining zone preference, check out this blog. 

You may already be familiar with the concept of zones in an on-premises Citrix XenApp and XenDesktop environment, however, there are a couple of functional differences to note:

  • In the XenApp and XenDesktop service, zones are created automatically when you create a resource location and add a Cloud Connector to it. Unlike an on-premises deployment, a service environment does not classify zones as primary or satellite.
  • In XenApp version 6.5 and earlier, zones included data collectors. The XenApp and XenDesktop service does not use data collectors for zones. Also, failover and preferred zones work differently.

When you are ready to begin configuring zones for your environment, you can easily start the process by logging into Citrix Cloud Studio and clicking on the Zones node in your console.

Hopefully, with this post, you’re able to determine if you should plan out your environment using zones or if everything will be contained within one Resource Location. Also if zones are for you, just keep in mind a few considerations and you should be on your way to a great end-user experience in no time. Keep an eye for our next blog post in our Cloud Guidepost series!

James Newton
Cloud Success Engineer