StoreFront Multi-Site Settings: Some Examples

The purpose of this article is to dive a little into the StoreFront multi-site settings as another item that has changed a lot coming from Web Interface.  Within the Citrix Consulting organization, many of our customers are starting to make the transition to StoreFront from Web Interface, especially as our XenApp 6.5 customers are looking at migrations to 7.5 and 7.6.  We are seeing a lot more questions about these settings as the number of farms (Sites per new 7.x terminology and to clarify now, any reference to “Site” in the remainder of this post should be considered a XenApp/XenDesktop 7.x Site not a StoreFront website) being enumerated tends to increase going from XenApp 6.5 zone-based architectures to datacenter-based XenApp/XenDesktop 7.x pods.  In this article, we will look at what these settings are, why they are important, and some examples of how we have used them in the field.

To set context for these settings, the closest built-in Web Interface equivalent is the Farm<n>Groups parameter in the conf file that restricted which user groups could enumerate a given farm/site.  We frequently used this in cases where a large number of farms were being aggregated by a Web Interface site but not all users required access to all sites, so this was a way of reducing Web Interface logon times because you could limit the number of enumeration requests.  The parallel resource enumeration enhancement introduced with StoreFront 2.5 has helped address this case outside of any multi-site settings, but the settings can take it a step further to restrict/control which sites/farms users have access to under a set of conditions.

In this way, the closest custom parallel is the Web Interface “high availability and load balancing” code published by Dan Allen used by some of our large XenDesktop customers.  I make no promises that StoreFront can match everything done by that code, but the overarching goal is the same: taking what Web Interface can do to filter which resources users see by default a step further.  Although these settings can be used with XenApp 6.5, in the field we are using them by far the most with XenDesktop / XenApp 7.x because we generally have more Sites to enumerate from following a Site-per-datacenter guideline than we had with XenApp 6.5 and farms that could span multiple datacenters.

So without further ado, we will get into some examples.  The StoreFront multi-site settings are as of version 2.5, exclusively config-file-based and are documented in eDocs here.  I have copied a sample structure below for reference.

<resourcesWingConfigurations>

<resourcesWingConfiguration name=”Default” wingName=”Default”>

<userFarmMappings>

<clear />

<userFarmMapping name=”user_mapping”>

<groups>

<group name=”domain\usergroup” sid=”securityidentifier” />

<group … />

…

</groups>

<equivalentFarmSets>

<equivalentFarmSet name=”setname” loadBalanceMode=”{LoadBalanced | Failover}”

aggregationGroup=”aggregationgroupname“>

<primaryFarmRefs>

<farm name=”primaryfarmname” />

<farm … />

…

</primaryFarmRefs>

<backupFarmRefs>

<farm name=”backupfarmname” />

<farm … />

…

</backupFarmRefs>

</equivalentFarmSet>

</equivalentFarmSets>

</userFarmMapping>

</userFarmMappings>

</resourcesWingConfiguration>

</resourcesWingConfigurations>

To define our terms, the primary tags that we have been using the field and will cover in the below examples are:

• userFarmMapping: Used to assign a group of users to a selection of Sites.  Closest direct equivalent to the Web Interface Farm<n>Groups parameter.
• equivalentFarmSet: A set of Sites (those within the “primaryFarmRefs” tag) that are considered identical.  An enumeration request is sent to only one of the Sites in the set based on the load balancing mechanism specified (either the first in the list if “failover” is specified or one at random if “load balance” is specified).  The “backupFarmRefs” Sites are only queried if all the primary Sites are down.
• aggregationGroup: A set of Sites across different equivalent farm sets from which identical resources are aggregated into a single icon (but single-Site resources are shown from all Sites).  So if “My Desktop” is published in both Sites to all users, users only see one icon instead of two.  But, if “Word” is only available in Site A and “Excel” is only available in Site B, both are also displayed.

Now that we have an understanding of the parameters, below are some examples for how we have used these settings in the field.  These are by no means designed to encompass every possible scenario, but hopefully give an idea of how these settings can be used and give an idea of how settings can be combined if your requirements match a combination of the listed scenarios.

• Scenario 1:  Identical, active/active Sites in the same datacenter (multiple XenDesktop pods split out due to scale, for example) or LAN-speed connected datacenters.
  • Desired User Experience:  Users are distributed round robin between the Sites.
  • Possible Configuration:  All Sites in the “primaryFarmRefs” section of the same “equivalentFarmSet” set with “LoadBalanced” as the load balancing mode.  The aggregation group tag is not important if only one equivalent farm set is specified.

• Scenario 2:  Two identical, active/passive Sites either in the same or different datacenters.
  • Desired User Experience:  Users are sent to the primary Site and only sent to the passive Site in case of Disaster Recovery.
  • Possible Configuration:  Same “equivalentFarmSet” set with “Failover” as the load balancing mode.

• Scenario 3:  Identical, active/active Sites (or sets of Sites) in the different datacenters with resources that should be aggregated.
  • Desired User Experience:  Users are directed to the “local” Site for new connections (but reconnected regardless of Site as needed), not randomly load balanced.
  • Possible Configuration:  Different “equivalentFarmSet” sets with the same “aggregationGroup” tag.  The order of the “equivalentFarmSet” list operates as a preference.  So the StoreFront servers co-located with Site1 would look like the following and the StoreFront servers co-located with Site2 would have the order of the Sites reversed.

• Scenario 4:  Multiple heterogenous Sites with some identical resources, which should be aggregated, and some unique resources.
  • Desired User Experience:  Users should see unique resources from all Sites but only one icon for identical resources.  If they launch a unique app/desktop, then a launch of an aggregated resource should stay in the same Site.
  • Possible Configuration:  Different “equivalentFarmSet” sets with the same “aggregationGroup” tag.

• Scenario 5:  Entirely unique Sites.
  • Desired User Experience:  Users should see resources from all Sites in which they have published resources.
  • Possible Configuration:  This is a bit of a trick scenario: if we have entirely unique Sites then no multi-site settings are required – StoreFront (and Web Interface) aggregate resources from all enumerated Sites natively.  However, as the number of unique Sites increases, enumeration time tends to also increase, which can lead to login delays.  This is greatly improved with parallel enumeration, as referenced earlier, but we encourage testing and measuring enumeration time and for optimal performance users should be mapped only to the Sites to which they need access.

Update September 2016: As of StoreFront 3.6, a new parameter, “identical={true|false},” was added to the multi-site settings falling after the “loadBalanceMode” parameter within the equivalentFarmSet settings.  This should be added automatically if upgrading from a previous version, but if using this as a guide to manually edit the multi-site settings in 3.6 or later, please note that this parameter must be added to the above examples.  You can refer to https://citrixblogs.wpengine.com/2016/09/07/storefront-multi-site-settings-part-2/ for more information.