Some information on the different StoreFront high availability, aggregation and optimal routing capabilities that exist today using StoreFront from 3.5 up to version 3.8 which was released alongside XenApp and XenDesktop 7.12.
♣ Synchronize StoreFront Store Subscriptions
♣ Route internal HDX connections through NetScaler Gateway
♣ Optimal HDX NetScaler routing at farm level
♣ Optimal HDX NetScaler routing at zone level
♣ StoreFront icon aggregation
♣ Delivery Controller User Mapping
Citrix Store Subscription Synchronization
When users browse Receiver for Web or Receiver Client, they can use self-service to subscribe to applications of their choice. This means that, a user may have the authority to access 20 different applications, when using subscriptions applications will only appear in the middle pane of Receiver Client or Receiver for Web for easier future access. To subscribe to an application, you simply find an application, click on it and then it will appear in the middle of the GUI. If you have a secondary store for failover purposes, you can synchronize the user subscriptions between stores so that in the event of a need to failover, the list of user subscriptions will be there.
When using the RfWeb UI, the favorites tab contains the list of subscribed applications. To subscribe to an application click on the Details link.
As shown below I have subscribed to three different applications. 
When logging on to a separate store, the applications do not appear as the subscriptions have not been synchronised over. 
To set up a pull subscription, firstly you need to make sure both the store name and configured Delivery Controllers for each store match. On the server you want to synchronize subscriptions to, open PowerShell as an Administrator.
Run command Import-Module -Name “C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\UtilsModule.psm1”, “C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\SubscriptionSyncModule.psm1” – Your install directory for StoreFront may be different so adjust the command as suits.
Now run command Add-DSSubscriptionsRemoteSyncCluster -clusterName -clusterAddress where clusterName is a descriptive name you choose to identify a synchronization job and clusterAddress is the single or load balanced address of the StoreFront server you want to pull the subscriptions from. 
Run command Add-DSSubscriptionsRemoteSyncStore -clusterName -storeName where clusterName is the descriptive name you configured above and storeName is the name of the Citrix store you want to pull subscriptions from. Remember that the store name must match on both the sending and receiving StoreFront servers.
Finally you need to create a schedule. We can create a reoccuring schedule using command Add-DSSubscriptionsSyncReoccuringSchedule -scheduleName -startTime -repeatMinutes where scheduleName is a descriptive name, startTime is the time you want synchronization to start and repeatMinutes is how often you want the synchronization to occur. 
On the sending StoreFront server, add the receiving members computer name to the CitrixSubscriptionsSyncUsers local group. This will allow in my case StoreFront2 to pull subscriptions from the StoreFront machine XenDesktop.
On the receiving StoreFront member(s) run command Restart-DSSubscriptionsStoreSubscriptionService to restart the Citrix Subscriptions Store. 
Alternatively you can restart the service via services.msc. 
On the receiving StoreFront member, open eventvwr -> Windows Logs -> Applications. You should see events being logged from the Citrix Subscriptions Store service. Event 22 shows the synchronization with remote StoreFront started. 
And Event 23 shows the synchronization completed. Notice also the text Citrix: 3. This indicates that 3 subscription items have been synchronized. At this stage when you log on to the second store, all subscriptions should be present.
To remove subscriptions run commands Remove-DSSubscriptionsAllSchedules and Remove-DSSubscriptionsRemoteSyncCluster. To remove a single schedule, run command Remove-DSSubscriptionsSchedule -scheduleName where scheduleName is the name of a currently configured schedule.
Optimal HDX routing
Zones were introduced to FMA in XenApp and XenDesktop 7.7. Zones are useful when you have a Citrix site which spans multiple datacentres and geographical locations. Using zones, Delivery Controllers, Hypervisor connections and and VDA’s are localised as such that when a VDA registers with a DDC, it picks a DDC if possible from the same zone. If not possible then the VDA has the capability to fallback to the primary zone to regsiter. Likewise then brokering user connections for example, Delivery Controllers will prefer VDA’s in the same zone. This is an optimal setup. For more information on zones see http://www.jgspiers.com/citrix-zones/
Before StoreFront 3.5, you could only map an optimal gateway to a farm or farms. Now HDX optimal routing gives you the ability to point NetScaler Gateway connections to zones. This ensures the Gateway picks the zone it typically has the best connection too as defined by the administrator. Using a technology such as GSLB will also route the user to the optimal NetScaler Gateway based on their location, and that Gateway would be connected to a zone for complete optimal routing.
Routing internal direct HDX connections through NetScaler Gateway:
Why? You may want to make use of HDX Insight and have all internal HDX connection statistics and metrics to be logged to NetScaler MAS.
What is NetScaler MAS? http://www.jgspiers.com/citrix-netscaler-management-analytics-system/
Make sure NetScaler Gateway nodes are added using the StoreFront console.
Select a store that you want users who connect to, to route through NetScaler internally. Click Configure Store Settings. Notice that the LondonStore I am using is set for internal network connections only. There is no need to configure the store for remote access to get this working.
Click Optimal HDX Routing. Select the NetScaler Gateway node that users will be routed through internally. Ideally this will be a NetScaler that is local to the store resources. Click Manage Delivery Controllers and select the Delivery Controllers that serve this store. Since Delivery Controllers map to a farm all internal HDX connections to the farm will be routed through NetScaler Gateway. Lastly make sure External only is unticked. Click OK.
Now when users directly connect to StoreFront and the LondonStore, their HDX connections are routed through NetScaler Gateway. 
Optimal HDX NetScaler routing at a farm level:
Take the following scenario. I have one StoreFront deployment, including one store. I however have two separate XenDesktop farms. DDC1.jgspiers.com serves farm 1 and DDC2.jgspiers.com serves farm 2. Both farms reside within their own dedicated datacentres.
When users connect through NetScaler Gateway, users are proxied on to StoreFront and the single site that is in place. Applications and desktops are enumerated from both farms as normal. If a user clicks on Farm 2 Desktop, they are brokered on to a farm 2 VDA (VDA2). The NetScaler now proxies the HDX connection between user on the outside world and VDA2. What if the user went through Farm 1 NetScaler which is in the same datcentre as Farm 1 and thus not the best placed gateway to serve the connection? There is a perfectly normal working NetScaler in Farm 2 that ideally should be used to connect to Farm 2 resources
In this case, we can make use of HDX Optimal Routing at a farm level to force HDX connections over Farm 2 NetScaler instead, which resides in the same datacentre as VDA2. When users connect to the farm 1 NetScaler, you can be sure their connection will be optimally routed. This type of re-routing of the HDX connection was previously only configurable by editing StoreFront’s web.config file.
Below, I have a Citrix store which is connected to two sets of Delivery Controllers.
Each Delivery Controller is connected to a separate XenDesktop farm. 
I also have two NetScaler Gateway appliances. One for each farm. 
Each NetScaler Gateway is configured for remote access against the Citrix site. 
To configure the farm for optimal routing. Click on the Citrix store and click Configure Store Settings.
Click on Optimal HDX Routing. Click on Farm 1 NetScaler -> Manage Delivery Controllers.
We want HDX connections brokered by Farm1 Controller to be routed through Farm 1 NetScaler. Select this controller followed by OK. 
Likewise we want brokered connections from Farm2 Controller to route through Farm 2 NetScaler. Also, check the box for External only. If you don’t, internal connections will also be routed through NetScaler.
This setup now states that if connections are brokered by Farm1 Controller in Farm 1, the Optimal Gateway is Farm 1 NetScaler. If connections are brokered by Farm2 Controller in Farm 2, the Optimal Gateway is Farm 2 NetScaler. Click OK.
Logging on to the Farm 1 NetScaler, desktops from both sites are enumerated.
Connecting to Farm 2 Desktop, you would now normally believe that Farm 1 NetScaler is serving the HDX connection.
However there are no active HDX connections on the Farm 1 NetScaler. 
Over on Farm 2 NetScaler, the HDX connection appears. The HDX connection was optimally routed to this NetScaler. 
Optimal HDX NetScaler routing at a zone level:
Like optimal routing at a farm level, you can get more granular and configure routing at a zone level. This is great for single Citrix sites that span multiple datacentres. Zones were introduced to FMA in XenApp/XenDesktop 7.7. The main reason for zones is to allow Citrix sites to span multiple locations whilst sharing most of the same infrastructure. In my scenario, I have one XenDesktop farm which spans two datacentres, one in London and one in New York. They share the same Delivery Controllers and zones are created as follows:
Secondary Zone (London) – ddc1.jgspiers.com and Machine Catalog London Machine Catalog. Hosted in London datacentre.
Secondary Zone (New York) – ddc2.jgspiers.com and Machine Catalog New York Machine Catalog. Hosted in New York datacentre.
A Delivery Group containing VDA1 and a second Delivery Group containing VDA2 exist. VDA 1 is in London, VDA2 is in New York. 
A single store called Citrix exists. Delivery Controllers from both datacentre’s are connecte to the site.
Two NetScaler’s are also connected to the site. A London and New York NetScaler Gateway. Click on Configure Store Settings.
Click Optimal HDX Routing. Highlight the NetScaler in your first datacentre and click on Manage Zones. 
Click Add. 
Enter the zone name exactly as it is named in Studio. In my case, London. Click OK.
Click OK. 
Perform the same for the second datacentre. Check the External only boxes. If you don’t, internal connections will be routed through NetScaler Gateway. Click OK.
In this example, I am connecting to NetScaler Gateway nsg.jgspiers.com. This NetScaler is located in the New York datacentre. I will now click and launch London Desktop.
Connection to London Desktop is successful and being proxied by NetScaler, but which NetScaler?
Optimal Routing forces the connection over the London NetScaler instead, unifiedgateway.jgspiers.com. 
The New York NetScaler which we connected to in the first place, nsg.jgspiers.com, shows no HDX connection. 
Looking at the launch.ica file which was downloaded by the client, Optimal Gateway configured the file, changing the SSLProxyHost entry from nsg.jgspiers.com to unifiedgateway.jgspiers.com 
StoreFront Aggregation and Delivery Controller user mapping
When you have multiple Delivery Controllers configured against a single StoreFront store that publish the same resources, you log on and receive duplicate icons as shown below. Using aggregation allows you to merge multiple icons of the same type and name in to a single icon.
To configure aggregation open your StoreFront console and highlight a store then click on Manage Delivery Controllers. 
In the example I am showing you, I have two separate farms configured against a single StoreFront store. The farms are named Farm 1 and Farm 2. Delivery Controller ddc1.jgspiers.com is connected to Farm 1 and ddc2.jgspiers.com is connected to Farm 2. When you have multiple sets of Delivery Controllers configured against a store the Configure button under User Mapping and Multi-Site Aggregation Configuration appears. Click this button. 
Click Aggregate resources. 
Select the controllers you want to aggregate the resources of and click Aggregate.
You have a further two options for selection:
Controllers publish identical resources – Check this if each farm has identical resources published. This will improve the responsiveness of logons and resource enumeration however you must make sure identical resources are published on both farms. A scenario would be an exact replica farm created for failover. If the farms do publish different resources then leave this unchecked.
Load balance resources across controllers – If this is checked, resources are evenly load balanced between each controller. If this is left unchecked, the controller first in the list under user mappings is selected and the second controller in my case is used only when the first controller is unavailable. User mapping creation is mandatory and we will walk through that next. Click OK.
Click Map users to controllers. This step is mandatory. Mapping users to controllers simply defines which groups of users can use which defined Delivery Controller(s). 
For now I will leave Everyone selected. Click Next. 
Click Add. 
Select the Delivery Controllers that will be mapped to everyone. Click OK.
Click Create. You can adjust the priority of Delivery Controllers by using the up and down arrows. In this case, Farm 1 Controller is contacted first and only when it fails will Farm 2 Controller be considered. 
Click OK. 
Click OK. 
Log on to StoreFront. The duplicate desktop icon is now de-duplicated.
Delivery Controller User Mapping
Note: Enabling aggregation causes existing subscriptions to be lost because the record format is changed. You should manually export the subscription database, replace all records for resources that will be aggregated with the proper format and then re-import the database once aggregation has been enabled for your selected resources.
Since Farm 1 Delivery Controller was first in the mapping list, it is used to broker a connection on to Farm 1 VDA1. Everytime I click on the desktop resource I will be brokered on to Farm 1, unless the Delivery Controller’s are unavailable. 
So what happens when we turn of DDC1.jgspiers.com In theory, all connections should be brokered on to Farm 2 now. 
As expected the preceding connections have been brokered on to VDA2 located in Farm 2. 
I previously mapped both farm Delivery Controller’s to all users however you can assign Delivery Controller’s to groups of users. Those groups are either defined by SID or Active Directory User Group name. You could use specific user group mapping to control who has access to a farm. In my example, Farm 1 Users have access to Farm 1 and Farm 2 Users have access to Farm 2.
My user account is currently a member of the Farm 1 Users group. 
When I log on to StoreFront, no desktops are available. That is because I have deliberately turned off DDC.jgspiers.com (Farm 1 Controller).
Next I’ll add my user account to the Farm 2 Users group and remove the account from Farm 1 Users.
When logging on to StoreFront, a desktop is enumerated this time. This proved Farm 2 ddc2.jgspiers.com was contacted.
And sure enough I have been brokered on to VDA2 residing in Farm 2. 