Many customers today are starting their Citrix Cloud journey by integrating Citrix Virtual Apps and Desktops service with existing on-premises Citrix StoreFront and Citrix Gateway deployments. Though Citrix Virtual Apps and Desktops and Citrix Virtual Apps and Desktops service are very similar, one key difference in the architecture that we see almost everyone grappling with is an increased reliance on zones in Citrix Cloud (versus more traditional multi-site architectures on-premises). That has led to some confusion on how best to integrate these Citrix Virtual Apps and Desktops service environments into Citrix StoreFront.

In this blog post, I’ll look at common configuration scenarios, including enumeration, optimal HDX routing, and local host cache considerations.

Multi-Sites and Multi-Zones

When you want to add a new Citrix Virtual Apps and Desktops environment into StoreFront, the first step is to add Cloud Connectors in the Manage Delivery Controllers section so StoreFront will enumerate the site. This is also where things can first go awry.

Many customers transitioning to Citrix Virtual Apps and Desktops service will be also transitioning from multiple sites to one tenant (or site). Those multiple Citrix Virtual Apps and Desktops sites generally get mapped to Citrix Cloud resource locations, which are in turn presented to Citrix Virtual Apps and Desktops service as zones. Though these may previously have been independently managed locations as distinct Citrix Virtual Apps and Desktops sites, every Cloud Connector in every RL/zone in a given tenant has access to the master site database in Citrix Cloud. They are not isolated from each other. However, because these locations previously were isolated, we often see those RLs/zones added to StoreFront as separate sites, such as:

If you implement the above, you’ll notice duplicate resources because you are effectively enumerating the same site multiple times (three times in the above example). This means you must now implement multi-site aggregation to de-duplicate a self-inflicted configuration. Note that this aggregation will NOT de-duplicate resources across RLs/zones (more on this later). It’s only undoing the duplication that was created by enumerating the same site multiple times to present a single view of all resources site-wide. The configuration is now becoming quite complicated.

What we should be aiming for in most cases is mimicking the true site architecture in StoreFront. This means one entry for the Citrix Virtual Apps and Desktops service site with all Cloud Connectors contained within it (see the local host cache section of this article for more details on “all Cloud Connectors”). For customers with several RLs/zones, we tend to recommend defining load balanced VIPs to group the Cloud Connectors per RL/zone, then listing those VIPs within StoreFront. That simplifies the list and can offload some of the XML health checking from StoreFront.

The resulting configuration looks similar to the following:

In terms of how those servers are contacted, you can choose either load balanced or failover order as shown below:

Load balanced will probably fit most scenarios and should almost always be selected if listing Cloud Connectors individually (as opposed to load balanced VIPs) to avoid overloading a single server. If RLs are geographically disparate, you may consider failover order to help keep that XML traffic local.

This configuration eliminates the need for multi-site aggregation within StoreFront, simplifying things. This does have a trickle-down effect on Citrix Virtual Apps and Desktops service because a common use case for multi-site aggregation was to distribute user sessions (load balance or failover) across distinct Citrix Virtual Apps and Desktop sites (often in multiple locations). With those Citrix Virtual Apps and Desktops sites converting into Citrix Virtual Apps and Desktop service zones and the elimination of multi-site aggregation, session distribution for common resources across multiple locations must now be managed by Citrix Virtual Apps and Desktops service-based controls. That includes zone preference or application groups spanning multiple delivery groups.

Optimal HDX Routing

Another StoreFront configuration that can be affected by this transition from sites to zones is optimal HDX routing (also known as optimal gateway routing or OGR), which is used to assign Citrix Gateways to proxy user sessions based on the “location” of the VDA the user is connecting to. As you may have guessed, there are two ways to assign a Gateway to a VDA location — based on site membership of the VDA (as defined in the Manage Delivery Controllers window) and/or based on zone membership of the VDA. Customers with multiple Citrix Virtual Apps and Desktops sites distributed geographically typically would have assigned optimal HDX routing based on site.

With Citrix Virtual Apps and Desktops service, where most deployments will consist of a single site with multiple zones (and we mimic this in StoreFront as previously discussed), optimal HDX routing should pivot to primarily leverage zones instead. To implement zone-based Gateway mappings, in the optimal HDX routing window, select Manage Zones and enter the zone name exactly as it appears within Citrix Virtual Apps and Desktops service. That’s it! The resulting configuration should look similar to this:

Local Host Cache

Now that we are all (maybe too) familiar with zones, another important aspect of integrating StoreFront with Citrix Virtual Apps and Desktops service is LHC functionality. This is one of the driving factors for many customers behind continued usage of StoreFront with Citrix Virtual Apps and Desktops service. One, somewhat counterintuitive, consideration with zones is what happens when the site is operating in LHC mode (which would kick in if a Citrix Virtual Apps and Desktops service tenant were to ever be unreachable for any reason).

During normal runtime, any Cloud Connector in any RL/zone can enumerate any application/desktop in any RL/zone (enumeration is site-wide as we discussed before). Any Cloud Connector in any RL/zone can also broker a session to any VDA in any RL/zone. In LHC mode, however, enumeration remains site-wide, but session brokering becomes RL/zone-specific, as shown below.

This brings us back to a statement I made earlier: “one entry for the Citrix Virtual Apps and Desktops site with all Cloud Connectors contained within it.” If you only list a subset of Cloud Connectors in StoreFront, such as those from one RL/zone, all applications and desktops across all RLs/zones will be displayed to users always. However, session launches to resources in RLs/zones whose Cloud Connectors are not listed in StoreFront will fail in LHC mode. This, obviously, isn’t what you want.

The solution? Any Cloud Connector that brokers VDAs that users need to access from a given StoreFront store must be defined within the Manage Delivery Controllers section of that Store to minimize the risk of session launch failure in LHC mode. Note that “Cloud Connector that brokers VDAs” is an important distinction because some customers may have Cloud Connectors that are only providing access to user domains and do not have VDAs registered against them. For customers with many RLs, the number of Cloud Connectors could start to stack up, in which case defining RL-specific load balanced VIPs and listing the VIPs within StoreFront may become more manageable. (I hope the pieces are starting to come together now as to why I said earlier that we tend to recommend that configuration 😊.)

One final setting that is critical to LHC functionality is enabling the advanced health check within StoreFront, which is a config file edit, shown below. This configuration is important because StoreFront receives additional information in the XML response such as health of the machine and zone membership of the Connector.

Want More?

To summarize some of the key points I’ve covered here:

  • Migrating Citrix Virtual Apps and Desktops service generally means consolidating multiple sites to multiple zones.
  • In most cases, StoreFront should mimic the site architecture, resulting in all Cloud Connectors for a given tenant listed within the same overall Citrix Virtual Apps and Desktops service “Delivery Controller” configuration.
  • Optimal HDX Routing will need to be updated to reference zones instead of sites.
  • All Cloud Connectors that broker connections to VDAs that can be accessed from a Store must be added to the “Delivery Controller” configuration for that Store for optimal LHC functionality.
  • Enable advanced health check.

I hope this post covers most of the cases you’ll encounter. If you want to learn more about these topics, check out the great references below. Thanks for reading!