Over the past 12-18 months, we have seen a dramatic shift with the number of deployments using Web Interface versus StoreFront to the point that StoreFront is the de facto standard in new environment builds and migrations that we are seeing within Citrix Consulting.

The majority of these deployments are also leveraging advanced multi-site settings in some way: either Optimal Gateway Routing to enable the use of HDX Insight for internal (non-Gateway users), user farm mapping to assign different groups of users to different farm sets, or aggregating resources from multiple farms/sites to collapse duplicate applications and/or desktops behind a single icon (if you are not familiar with these terms, please review http://docs.citrix.com/en-us/storefront/3-6/sf-configure-ha.html or https://www.citrix.com/blogs/2014/10/13/storefront-multi-site-settings-some-examples/ before continuing). 

This has led to a lot of lessons learned, the most important of which I’ll attempt to highlight here today.

Starting with the basics, anytime we have more than one site/farm in an equivalent farm set, we need to specify an aggregation group name for the load balancing or failover function to work (note that the console-based settings we added in 3.5 do this by default).


Aggregation groups influence launch requests. If we leave the aggregation group field blank, even if we define all other aspects of the equivalent farm set, StoreFront will use the equivalent farm set definitions to perform resource enumeration, but if the primary site is unavailable, StoreFront will not query the remaining sites for the launch request and therefore no resources will launch. So, whether you are aggregating homogeneous or heterogeneous sites/farms, always specify an aggregation group name.

Another key lesson is that aggregation groups impact subscriptions. If you have ever exported the local subscription database to a CSV file and opened it up, you will see that by default, subscription records are stored in the format <SiteName>.<DisplayName>.  All very logical because by default, StoreFront, like Web Interface, will enumerate resources from all XenApp/XenDesktop sites and display them individually – if two resources happen to be published with the same name in different sites, they should be displayed twice. Therefore, we need some kind of site tag to differentiate those subscriptions.

Enter aggregation groups, where we do not want identical resources across sites to be displayed individually, but aggregated behind the same subscription shortcut. The site tag is no longer meaningful because we want a single subscription record to cover the same resource from multiple sites – the whole point is that the display of the application/desktop is somewhat abstracted from the underlying sites. Therefore, when aggregation groups are configured, the subscription records for aggregated resources are stored in the format <AggregationGroup>.<DisplayPath>\<DisplayName>.

Why should you care?

If your StoreFront environment went live without aggregation groups (but with subscriptions enabled) and you subsequently decide to configure aggregation groups, all user subscriptions for aggregated resources will disappear because of the change in subscription record format. A workaround for this is to export the subscription database, replace all records for resources that will be aggregated with the proper format, and re-import the subscription database after the configuration of aggregation groups. Depending on the number of unique resources, this may be a very easy or a very onerous task, but it is a required task nonetheless unless you want all users to re-subscribe to their apps.

Lastly, user farm mappings. It is possible for a user to be part of multiple user farm mappings. We should actually expect this in the case of Citrix administrators, who typically have access to all applications/desktops and are members of multiple user groups to be able to test and reproduce reported user issues. In this case, each user farm mapping is evaluated individually and the sum of all the farm mappings is displayed. The advanced twist to this is when those user farm mappings include some of the same sites configured aggregation groups.

Consider the common example of having two identical XenDesktop pods and you want to divide your users into two groups: user group 1 should primarily use XenDesktop Site A and failover to Site B and vice versa for user group 2 – this requires two user farm mappings, each configured with aggregation of Site A and Site B, but with different failover orders.

However, your admins will likely belong to both user groups and in the context of an individual user, a site can only belong to one aggregation group or an error will be displayed.  This is resolved by naming the aggregation groups the same between the user farm mappings. This will have no effect on users who only belong to one group, but will allow users belonging to both groups to also function.

Therefore, if you have multiple user farm mappings, those mappings contain some of the same sites configured in aggregation groups, and some users will span multiple mappings, the aggregation groups must be named the same.

That’s it … for now. Hope our lessons learned save the rest of you some time.