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 https://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 gateway 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? https://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. 
Phil
March 1, 2017Great stuff, very useful.. Thanks for writing it up
George Spiers
March 1, 2017Most welcome!
JP
March 6, 2017Great stuff! what happens when you have optimal gateway routing enabled and you have one of the sites go down? For example Chicago Farm and new york Farm (separate farms/sites)… Chicago has an vdi Chicago & New YOrk presented to the user… New York has an vdi new york & chicago presented to them. We have two separate netscalers gw in each location Chicago and new york configured with GSLB (ACTIVE/ACTIVE). What happens when the netscaler in Chicago is down? With GSLB the main page they try to hit is redirected to new york. Now i get redirected to New YOrk (gslb configured) and i launch the chicago vdi and unable to access it because of the optimal gateway is no longer available, but the citrix xddc is up? What can i do avoid not having access to the chicago vdi if the netscaler is down? Am i missing something? thank you for any feedback at all!!!!!
George Spiers
March 6, 2017Edit your StoreFront store Optimal HDX Routing settings, remove Chicago farm Delivery Controller(s) from the Chicago NetScaler Gateway. Now Chicago resources will route through New York gateway. When Chicago gateway is back online, assign the Delivery Controller(s) back to the Chicago gateway under Optimal Routing.
Jp
March 6, 2017Thank you! I will give that a shot! So there is no backup method huh? Manual process? Thank you very much again!!! And for the quick reply!!!
George Spiers
March 7, 2017No problem and I’m not aware of any way to automate this at present.
WillFulmer
March 7, 2017We are currently testing the same scenario and experiencing the same behavior – looking for a way to automate this failover/redirection of Optimal HDX Routing.
Jp
March 7, 2017Just tested successfully! Thank you!!!!!! Working as expected :)))). I don’t like the manual process but this should work during an outage. Btw I’m running 7.12 and latest Netscalers with 11.1 51.26
Aman
January 16, 2023hi JP were you able to automate this ?
Or still manual shift .
Thanks
James S
August 4, 2017Hi Mate, this is a great article – many thanks for taking the effort to write it up. Well done.
Remco Bosveld
August 30, 2017hi George
we are currently deploying a new single citrix site in an active active scenario spanning 2 datacenters. we did configure each user with a home zone preference and configured zoning for certain applications. each data center has its won netscaler gateway which are setup with glsb.
each data center has 2 DC and 2 SF servers. SF servers are in one single storefront server group.
is spanning a single storefront group over 2 datacenters supported by citrix nowadays?
thanks
remco
George Spiers
August 30, 2017Hi Remco, providing there is acceptable latency they would support it fine 🙂
Remco Bosveld
August 30, 2017George
thanks for the quick reply. latency between our 2 datacenters is between 15-35 ms. would this be considered acceptable latency?
remco
George Spiers
August 30, 2017Yes absolutely!
Scott
October 6, 2017George,
Great article, one question on the gateway side/NetScaler when the selected apps is in another location and are redirected to the other gateway how does it handle the authentication to that gateway? Are the original credentials passed along, I am assuming something keeps the second gateway from doing authentication challenge again.
George Spiers
October 6, 2017Not completely sure of the internal workings but believe there is a secure ticket passed to the optimal gateway to allow the launch to happen. But yes, the user is not asked for any more credentials. I think WireShark and a rainy day would give us some info on what is happening under the hood 🙂
Pingback: A Citrix Active/Active Deployment – Part 4 – Vertical Age Technologies, LLC
R
February 23, 2018Am I missing something here or are all these things only possible when using Netscalers?
What about small business customers who can’t afford extortionate GSLB and Netscaler high bandwidth VPX licenses and simply use internal Storefront IIS site address without traversing a Netscaler Gateway? or a small load balancer for Storefront LB. Not NS GW at all.
George Spiers
February 23, 2018No just the optimal gateway routing piece requires NetScaler.
If you need Load Balancing, Citrix offer a free VPX Express edition. It is low bandwidth (20Mbps) but might suit your needs.
Mayur
March 27, 2018Hi George,
I am trying to setup a lab configuration of being able to simulate 2 scenarios and could do with your input on whether I going about it the right way.
First scenario is a single 7.15 LTSR site, Primary Zone (HQ) and Secondary Zone (DR), Second scenario is to configure 2 independent Citrix XD sites.
To start I have configured a single Site with the below configuration:
Primary Site (HQ)
————————-
Storefront URL = storefront.lab.local
Store is mapped with
HQ Site = DDC1 and DDC2
DR Site = DDC3 and DDC4
2 x SF -SF01, SF02 (are ONLY joined together as a pair)
2 x DDC -DDC1, DDC2 (are also joined to DDC3 and DDC4)
1 x Win7 VDA
1 x WS2016 VDA
Secondary Zone (DR)
Storefront URL = storefront.lab.local
HQ Site = DDC1 and DDC2
DR Site = DDC3 and DDC4
2 x SF -SF03, SF04 (are ONLY joined together as a pair)
2 x DDC -DDC3, DDC4 (are also joined to DDC1 and DDC2)
1 x Win7 VDA
1 x WS2016 VDA
I am resolving all 4 SF servers using one url storefront.lab.local. Not sure if each sites SF machines should have a unique URL ?
Before I proceed further I just wanted to run it past you – The aim is to first configure a multi-site HA configuration without using GSLB. I will add it later once I have a better understanding of the operation. Is the above the correct way of configuring the Stores and DDCs?
Thanks,
Mayur
George Spiers
March 27, 2018If latency is low between both zones then looks OK to me. GSLB will help when you implement it by directing users to the closest or available datacentre.
You could go with one server group to save on management again depending on latency but two server groups won’t do any harm, hopefully behind a load balancer 🙂
Mayur
March 27, 2018One thing i seem to be confused about is in my design since i have a single site/farm but with two zones. One Primary and Seconday. I have joined all 4 (2 per zone) delivery controllers together but i am not sure if the same has to be done for the 4 Storefronts also?
George Spiers
March 27, 2018There is no requirement for them to be, they sit outside of the Zone configuration. If all StoreFront servers will share the same stores, and configuration etc. and there is decent latency between each location then I see no reason not to put them all under the one Server Group just to keep things simpler.
Mayur
March 27, 2018Thanks, ye sit makes sense to put all the SFs under one server group.
Next, I need to get my head around how to configure the machine catalog(s) and delivery group(s). Basically what I would like to achieve is a user should be be able to launch a VDI or App when say both the DDCs in Primary Zone, Storefront servers and Hosting were to fail on one of the zones. I get the all the resources being named the same bit and the new Aggregation and load balanced etc. In my lab below are the resources I have.
Primary (HQ) and Secondary (DR) will each have – 1 x Win7 VDA and 1 x WS2016 VDA resources and they are on different network subnets also but I the resources will be named the same.
From what I can gather in order to set this up, I have to create 2 x machine catalogs and 2 x Delivery Controllers.
(1) HQ VDI MC and HQ VDI DG
(2) DR VDI MC and DR VDI DG
Is this correct?
And without aggregation I should have two Icons displayed in Storefront i.e Desktop(1) and Desktop(2) and when I aggregate the delivery controllers of both the zone, the icons will be de-duplicated into a single icon as Desktop. Is this what I should see?
George Spiers
March 27, 2018Aggregation is used when you have multiple Sites or Farms. You have one Site so aggregation is not needed. You add all four Delivery Controllers from both zones in to your StoreFront configured Store. Ideally these DDCs would be placed behind a Load Balancer so that if one fails broker requests do not route there. If primary zone DDCs fail then VDAs from the secondary zone will be registered with the secondary zone DDCs, and StoreFront will contact these DDCs during brokering and users will be placed on secondary zone VDAs. StoreFront will always show the one resource.
You can create two Machine Catalogs so they can be placed in their respective zones, and VDA registration and brokering happen within the same zone. You only need to create one Delivery Group though.
Mayur
March 27, 2018Thank you so much for clarifying when to use Aggregation. Yes I have noted the point you made about the importance of having a load balancer, to keep simple in my lab I am just using the DNS. Okay for my first lab testing I will do as you have suggested as the whole purpose of setting this up is to get a hands on understanding of the behaviour of the Storefront HA fail over. Then it is my intention to test the multi-farm (nothing shared) scenario. I will report back on how I got on with my config.
Thanks again!
Mayur
March 28, 2018I created 2 machines catalogs containing 1 x Win7 VDI VM for both zones and a single DG and added both VMs to it, As for assigning the site affinity AD user groups, am I right to assume I add the user groups to the Storefront User Mapping or is it to each of the Zones?
I created 2 user groups one for each site and added each to their respective zone. But when I logon to Storefront I seem to be getting 2 Desktop icons one from each zone. Is this the expected behaviour or I am doing something wrong?
Mayur
March 28, 2018Please ignore my earlier message. I figured out the problem, it was because I had created 2 separate pair entries of the DDC for each zone in Storefront so it was duplicating the resource icon.
Mayur
March 29, 2018I am so pleased to inform you that I managed to simulate the launching of a VDI session in a 2 zone configuration. I created two Site Affinity User groups with a different user in each and was able to launch a session from the two locations using the two different users.
I then went on to test the failing of the 2 DDCs and SF servers in HQ site and was able to launch a session from the DR zone. I observed a couple of things during this failover that I wasn’t sure if it is the right behaviour.
With DDC01 and DDC02 both down in HQ zone, I tried to connect to the DDC03 and DDC04 in the DR zone individually using Studio but it kept on failing. Is this normal because the Master (DDC01) was down or is it because I have no load balancing in my setup?
Secondly, what I noticed was because both the DDCs in the HQ zone were down the VDA could not register with any of the DDCs in the DR zone. I figured out this was because when I installed the VDAs in each zone I had only provided the fqdn for the pair of DDCs at each zone.
Am I right to think in a multi-zone scenario the VDAs should be configured with all the DDCs in the site?
George Spiers
March 29, 2018Hi Mayur
If SQL was available in the primary zone then launching Studio should have worked on DDC03 and 04.
VDAs from the primary zone will not attempt to register with DDCs in a secondary zone.
Yes that would generally be the idea. Auto-update is enabled by default which updates the VDA with all controller addresses in your Site. This will allow VDAs in a secondary zone to register with DDCs in a primary zone if the DDCs in secondary zone fail.
Mayur
March 29, 2018Yes, the SQL server is in the primary zone and was online and accessible to the DDCs in the secondary zone but twice I tested the studio could not connect to anyone of the two controllers. When I brought back the Primary DDCs back online I was able to connect to all four controllers individually.
I will have to do some checking and also figure out why the VDA is not registering with the delivery controllers in the available zone. I know I had manually entered only 2 controllers addresses per site in each of the VDA.
Happy Easter!
George Spiers
March 29, 2018Even if you only specified two, those secondary VDAs should be able to register with other DDCs in the secondary zone and DDCs from the primary zone (fallback). Happy Easter!
chand
April 26, 2018Wonderful Explanation. Thank you George.
Steve
January 9, 2019This was fantastic. The best and easiest to understand StoreFront/ADC/Optimal Routing I have read.
Christopher
July 31, 2019George,
So in the scenario above, do your users have both URLs? or do you have a Public “https://GS_CitrixSite.com” and then you do something so Storefront sees the different URL? The confusion is because in Storefront we have:
DataCenter 1 https://OurCitrix.com
DataCenter 2 https://OurCitrix.com
DataCenter 3 https://OurCitrix.com
How can Storefront tell the difference?
George Spiers
July 31, 2019Hey what scenario are you referring to? What is your requirements
Anonymous
July 31, 2019Apologies, I’ve spent so much time staring at “Optimal HDX NetScaler routing at a zone level”, that I forgot how much you covered above.. I may have dug it out – Callback URLs… ?
We need to differentiate between the 3 Netscaler pairs for the Optimal routing, but we use the same external URL for our GSLB, so I was stumped on how Storefront could tell the difference.
Christopher
July 31, 2019Apologies, I’ve spent so much time staring at “Optimal HDX NetScaler routing at a zone level”, that I forgot how much you covered above.. I may have dug it out – Callback URLs… ?
We need to differentiate between the 3 Netscaler pairs for the Optimal routing, but we use the same external URL for our GSLB, so I was stumped on how Storefront could tell the difference.
Dirk
January 17, 2020Thanks Mr Spiers, can you tell me how the load balancing happens with aggregation enabled with load blancing? Is it straight round robin? There’s no weight or metrics involved with available resources?
George Spiers
February 17, 2020Correct, launches are distributed evenly across the available controllers.