StoreFront Config for NetScaler Gateway

Last Modified: Mar 13, 2016 @ 6:49 pm


Contained on this page are the following topics:

StoreFront Config

  1. See the NetScaler 10.5 page or NetScaler 11 page for instructions on configuring NetScaler Gateway for StoreFront.
  2. In the StoreFront Console, click Authentication on the left. On the right, click Add/Remove Methods.
  3. Check the box next to Pass-through from NetScaler Gateway and click OK.
  4. If you can’t resolve the NetScaler Gateway FQDN from the StoreFront server, edit the C:\Windows\System32\drivers\etc\hosts file and add an entry for the NetScaler Gateway FQDN.

    After configuring the HOSTS file, on the StoreFront server, open a browser and navigate to the DNS name. Make sure the Gateway vServer logon page appears.
  5. In the StoreFront Console, right-click NetScaler Gateway and click Add NetScaler Gateway Appliance.
  6. In the Gateway Settings page, enter a display name. This name appears in Citrix Receiver to make it descriptive. If you have multiple sites, include a geographical name.
  7. Enter the NetScaler Gateway Public URL. The NetScaler Gateway FQDN must be different than the FQDN used for load balancing of StoreFront (unless you are configuring single FQDN). This can be a GSLB-enabled DNS name.
  8. A Subnet IP address is not needed for NetScaler Gateway 10 and newer. However, if the NetScaler Gateway URL is GSLB-enabled then you’ll need to enter the VIP of the NetScaler Gateway Virtual Server so StoreFront can differentiate one NetScaler Gateway from another.
  9. Enter the Callback URL.
    1. In StoreFront 2.6 and newer, the Callback URL is optional. However, SmartAccess requires the Callback URL to be configured.
    2. The callback URL must resolve to any NetScaler Gateway VIP on the same appliance that authenticated the user. For multi-datacenter, edit the HOSTS file on the StoreFront server so it resolves to NetScaler appliances in the same datacenter.
    3. The Callback URL must have a trusted and valid (matches the FQDN) certificate.
    4. The Callback URL must not have client certificates set to Mandatory.
  10. If you have two-factor authentication (LDAP and RADIUS), change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
  11. Click Next.
  12. In the Secure Ticket Authority page, click Add.
  13. Add both of your Controllers. Use http:// or https:// depending on the certificates installed on the Controllers. You can also enter a Load Balancing VIP here. However, you cannot use a Load Balancing VIP when configuring Secure Ticket Authorities on your NetScaler Gateway Virtual Server.
  14. Click Create when done.
  15. Then click Finish.
  16. Click Stores on the left. On the right, click Enable Remote Access.
  17. Select No VPN tunnel.
  18. Check the box next to the NetScaler Gateway object you just created and then click OK.
  19. Then in the StoreFront console, right-click Server Group and click Propagate Changes.

Single FQDN – Create a single Fully Qualified Domain Name (FQDN) to access a store internally and externally

Traditionally Receiver required separate FQDNs for StoreFront Load Balancing (internal) and NetScaler Gateway (external). Recently Citrix made some code changes to accept a single FQDN for both. This assumes that external users resolve the single FQDN to NetScaler Gateway and internal users resolve the same FQDN to StoreFront Load Balancing.

Single FQDN is fairly new and thus has the following requirements:

  • Receiver for Windows 4.2 or newer
  • Receiver for Mac 11.9 or newer
  • StoreFront 2.6 or newer
  • Split DNS – different DNS resolution for internal vs external
  • NetScaler 10.1 or newer

This section assumes NetScaler Gateway is in ICA Proxy mode. Different instructions are needed for when ICA Proxy is off. See for more information.

If you don’t care about email-based discovery then the configuration of Single FQDN is fairly simple. Sample DNS names are used below. Make sure the certificates match the DNS names.

  1. Internal DNS name = the Single FQDN (e.g. Resolves to internal Load Balancing VIP for StoreFront. Set the StoreFront Base URL to this address.
  2. External DNS name = the Single FQDN (e.g. Resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler. Set the NetScaler Gateway object in StoreFront to this FQDN.
  3. Auth Callback = any internal DNS name (e.g. that resolves to a NetScaler Gateway VIP on the same DMZ NetScaler appliance that authenticated the user.

    • Auth callback is optional if you don’t need SmartAccess features.
    • The callback DNS name must be different than the Single FQDN.
    • Your external NetScaler Gateway certificate could match both the Single FQDN and the Callback FQDN. Or you can create separate NetScaler Gateway Virtual Servers on the same appliance with separate certificates that match these FQDNs.
  4. Internal Beacon = any internal website URL that is not externally accessible. You can’t use the Single FQDN as the Internal Beacon.

    • If are using Receiver for iOS internally then be aware that Receiver for iOS handles the Internal Beacon differently than Receiver for Windows. Receiver for iOS will append /Citrix/Store/discovery to the Internal Beacon and thus it only works if the Internal Beacon DNS name resolves to the StoreFront server. Since you can’t use the StoreFront Base URL as the Internal Beacon you’ll need a different DNS name that resolves to the StoreFront servers and matches the StoreFront certificate. Note: if you are not allowing internal iOS devices then this isn’t needed.
  5. Make sure the DMZ NetScaler resolves the Single FQDN to the internal StoreFront Load Balancing VIP. You typically add internal DNS servers to the NetScaler. Or you can create a local address record for the Single FQDN.
  6. In the NetScaler Gateway Session Profile, set the Web Interface Address and the Account Services Address to the Single FQDN.

If you need email-based discovery then here’s an example configuration for ICA Proxy NetScaler Gateway:

  • External DNS:
    • resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler.
    • If email-based discovery, SRV record for points to
  • External publicly-signed certificate for NetScaler Gateway:
    • One option is wildcard for * Assumes email suffix is also
    • Another option is the following Subject Alternative Names:
      • – for callback URL. Only accessed from internal.
        • Or you can create a separate Gateway vServer for callback with a separate certificate.
      • If email-based discovery,
  • Internal DNS:
    • resolves to Load Balancing VIP for StoreFront
    • – resolves to NetScaler Gateway VIP on DMZ NetScaler. For authentication callback.
    • For the internal beacon, FQDN of any internal web server. Make sure this name is not resolvable externally.
    • If email-based discovery, SRV record for points to
  • Internal certificate for StoreFront Load Balancing: publicly-signed recommended, especially for mobile devices and thin clients. Also can use the external certificate.
    • One option is wildcard for * Assumes email suffix is also
    • Another option is the following Subject Alternative Names:
      • If email-based discovery,

StoreFront Configuration:

  • Base URL =
  • Internal beacon = FQDN of internal web server. Make sure it’s not resolvable externally.
  • Gateway object:
    • Gateway URL =
    • Callback URL =

Receiver for Web session policy (basic mode or ICA Only is checked):

  • Policy expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver
  • Client Experience tab:
    • Home page =
    • Session Timeout = 60 minutes
    • Clientless Access = Off
    • Clientless Access URL Encoding = Clear
    • Clientless Access Persistent Cookie = Deny
    • Plug-in Type = Windows/Mac OS X
    • Single Sign-on to Web Applications = checked
  • Security tab:
    • Default authorization = ALLOW
  • Published Applications tab:
    • ICA Proxy = On
    • Web Interface address =
    • Web Interface Portal Mode = Normal
    • Single Sign-on Domain = Corp

Receiver Self-Service session policy (basic mode or ICA Only is checked):

      • Policy expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
      • Client Experience tab:
        • Session Timeout = 60 minutes
        • Clientless Access = Off
        • Clientless Access URL Encoding = Clear
        • Clientless Access Persistent Cookie = Deny
        • Plug-in Type = Java
      • Security tab:
        • Default authorization = ALLOW
      • Published Applications tab:
        • ICA Proxy = On
        • Web Interface address =
        • Web Interface Portal Mode = Normal
        • Single Sign-on Domain = Corp
        • Account Services address =

Multiple Datacenters / Farms

If you have StoreFront (and NetScaler Gateway) in multiple datacenters, GSLB is typically used for the initial user connection but GSLB doesn’t provide much control over which datacenter a user initially reaches. So the ultimate datacenter routing logic must be performed by StoreFront. Once the user is connected to StoreFront in any datacenter, StoreFront looks up the user’s Active Directory group membership and gives the user icons from multiple farms in multiple datacenters and can aggregate identical icons based on farm priority order. When the user clicks on one of the icons, Optimal Gateway directs the ICA connection through the NetScaler Gateway that is closest to the destination VDA. Optimal Gateway requires datacenter-specific DNS names for NetScaler Gateway. Set up highly available multi-site store configurations explains configuring XML files on StoreFront to aggregate identical icons from multiple farms/sites. Identical Icons are aggregated in farm priority order or load balanced across multiple farms. To specify a user’s “home” datacenter, configure different farm priority orders for different Active Directory user groups.

Shaun Ritchie Citrix StoreFront High Availability and Aggregation – A dual site Active Active design has a sample multi-site configuration using XML Notepad and explains how to use the Primary and Secondary keywords to override farm priority order.

Citrix Blogs StoreFront Multi-Site Settings: Some Examples has example XML configurations for various multi-datacenter Load Balancing and failover scenarios.

When Citrix Receiver switches between StoreFront servers in multiple datacenters, it’s possible for each datacenter to be treated as a separate Receiver site. This can be prevented by doing the following. From Juan Zevallos at Citrix Discussions: To have multiple StoreFront deployments across a GSLB deployment, here are the StoreFront requirements:

  • Match the SRID – in StoreFront, if you use the same BaseURL in the 2 separate installations, then the SRID should end up being identical. If the BaseURL is changed after the initial setup, the SRID doesn’t change. The SRID can be safely edited in the \inetpub\wwwroot\Citrix\Roaming\web.config file. It will be replicated into the discovery servicerecord entry in the Store web.config which can be edited as well or refreshed from the admin console by going into Remote Access setup for the store and hitting OK. Make sure to propagate changes to other servers in the group.
  • Match the BaseURL
  • Match the Delivery Controller names under “Manage Delivery Controllers” – The XML brokers can be different, but the actual name of the Delivery Controller/Farm must be identical. Here’s the exact setting I’m referring to:

If you are running XenApp / XenDesktop in multiple datacenters, you must design roaming profiles and home directories correctly.

Optimal Gateway

The Optimal Gateway feature lets you override the NetScaler Gateway used for ICA connections. Here are some scenarios where this would be useful:

  • The NetScaler Gateway Virtual Server requires user certificates. If ICA traffic goes through this Virtual Server then each application launch will result in a certificate prompt. Use Optimal Gateway to force ICA connections through a different NetScaler Gateway Virtual Server that doesn’t have certificate authentication enabled. Note: Callback URL also cannot use a NetScaler Gateway Virtual Server where client certificates are set to Mandatory.
  • Multi-site Load Balancing. If the icon selected by the user is published from XenApp/XenDesktop in Datacenter A, then you probably want the ICA connection to go through a NetScaler Gateway Virtual Server in Datacenter A. This requires separate NetScaler Gateway DNS names for each datacenter. Also, Optimal Gateway is applied at the farm/site level so if you are stretching a farm across datacenters then Optimal Gateway won’t help you.
  • NetScaler Gateway for internal connections (AppFlow). If you want to force internal users to go through NetScaler Gateway so AppFlow data can be sent to Citrix Insight Center then you can do that using Optimal Gateway even if the user originally connected directly to the StoreFront server. See How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront for more information.

Optimal Gateway is configured by editing the StoreFront Store’s web.config file. See To configure optimal NetScaler Gateway routing for a store. For an example configuration see Examples of highly available multi-site store configurations.

Optimal Gateway works great if you have separate XenDesktop sites/farms in each datacenter. However, for those of you with a central XenDesktop site running globally dispersed VDAs and a NetScaler Gateway in each location, or a single globally distributed XenApp farm (which I know an awful lot of you still have), see the Citrix blog post – How to direct remote XenApp/XenDesktop users based on active directory group membership:

    1. On a Load Balancing NetScaler, create multiple StoreFront load balancers. Each has a unique Net Profile with a unique SNIP.
    2. On StoreFront, create multiple Gateway objects, each with a SNIP that matches the Net Profiles created on the load balancer. Each Gateway object has a datacenter-specific Gateway FQDN.
    3. On each NetScaler Gateway:
      1. Configuration LDAP group extraction.
      2. Create a session policy for each datacenter pointing to the one of the StoreFront Load Balancers.
      3. Create AAA groups and bind the session policies.

Gateway in Closest Datacenter

Citrix Blog post ‘Accurately’ Direct XenApp/XenDesktop Users to a Correct Location Based Datacenter:

  • An unsupported extension to StoreFront
  • Read’s the client’s IP and looks it up in a location database (GeoLite2) to determine the user’s closest datacenter
  • Adjusts the Gateway FQDN in the rendered .ica file to direct users to the closest datacenter.
  • Requires datacenter-specific or region-specific Gateway DNS names.
  • Every NetScaler Gateway should know about every potential Secure Ticket Authority server.

Multiple Gateways to One StoreFront

If you have multiple NetScaler Gateways connecting to one StoreFront Server Group, and if each of the NetScaler Gateways uses the same DNS name (GSLB), then you will need some other method of distinguishing one appliance from the other so the callback goes to the correct appliance.

  • In the StoreFront console, create multiple NetScaler Gateway appliances, one for each datacenter. Give each of them unique names.
  • Enter the same NetScaler Gateway URL in all of the gateway appliances. Since all of the appliances use the same DNS name, you cannot use the DNS name to distinguish them.
  • Each appliance has a different NetScaler Gateway VIP. This VIP can be entered in the Subnet IP field. StoreFront will use this VIP to distinguish one appliance from another. The field label is SNIP but we actually need to enter a VIP.
  • The callback URL must be unique for each Gateway appliance. The callback URL must resolve to a NetScaler Gateway VIP on the same appliance that authenticated the user. Create new datacenter-specific DNS names. For example: and
  • The datacenter-specific DNS name must match the certificate on the NetScaler Gateway Virtual Server. Here are some options to handle the certificate requirement:
    • On the main NetScaler Gateway Virtual Server, assign a wildcard certificate that matches both the GSLB name and the datacenter-specific name.
    • On the main NetScaler Gateway Virtual Server, assign an SSL certificate with Subject Alternative Names for both the GSLB name and the datacenter-specific name.
    • Create an additional NetScaler Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific name.
  • Configure name resolution for the datacenter-specific NetScaler Gateway DNS names. Either edit the HOSTS file on the StoreFront servers or add DNS records to your DNS servers.
  • When enabling Remote Access on the store, select both Gateway appliances. Select one as the default appliance.

Related Pages

Additional StoreFront Configuration

NetScaler 10.5

Email this to someonePrint this pageTweet about this on TwitterShare on LinkedInShare on FacebookPin on PinterestShare on RedditShare on StumbleUpon

111 thoughts on “StoreFront Config for NetScaler Gateway”

  1. Hello,

    Need urgent help because I am pulling my hair out. I have a netscaler that was load balancing 2 Storefront 3.5 servers. Suddenly sf1 crashed and now the load balancing via netscaler always reports sf1 as down. SF2 is working fine. Strangely enough users can launch storefront page via internal ip on sf1 and launch apps. Just the netscaler loadbalance of storefront always reports sf1 as down

    I have built a new storefront server sf3 and I am seeing the same issues!!! Please help .


    1. What is your load balancing monitor? If the StoreFront monitor, try unchecking the boxes on the Advanced Parameters tab.

  2. Hi Carl!

    I have set up our environment exactly as per your instructions here. 🙂 Xenapp 7.11, newest StoreFront and Netscaler 11.1. (Single FQDN) All working as it should when accessing it from the inside, connections go through the Netscaler and apps start. BUT, when i access the Netscaler from anywhere outside of work, its not working because in the ICA file Storefront always gives me the private address of the XA server? That is of course not accessible.

    I have certs with FQDN and SAN on both NS and SF. SF has base URL to the FQDN. Profiles and policies on NS set up exactly as this blog states.

    Newest Receiver with .cr file imported after changing beacons. Beacons inside is a DNS alias (not resolvable outside) for FQDN, resolves to the StoreFront server (have only one). Outside beacon is the FQDN and

    All working (from inside), directly via the SF server, and via the Netscaler..

    Can you point me in the right direction as to why i always get the XA servers private address directly in the ICA file downloaded? It works the same both via web and via native receiver by the way.

    And thank you for the greatest Xen resource online! 🙂

    1. Beacons only apply to Receiver, not to web.

      In StoreFront, did you create a Gateway object? Did you Enable Remote Access on your store?

      You are actually connecting to Gateway? Gateway should be added a header to HTTP before it talks to StoreFront. And StoreFront will log if the header is present but there’s no matching Gateway configured in the StoreFront console.

      Make sure your browser address bar points to FQDN and not IP.

      1. Yes, Gateway created and remote access enabled. Yes, i know i’m connecting to it, I can see the session beeing created in NS console, and i also tested it from home to be sure. From home, i can log in, see the apps, but not start them since launch.ica has the private server address.

        Address bar of course points to FQDN. This is getting me grey hair! And thats good, as i have almost no hair.. 😉

        Just saw that in StoreFront console, when i look at the store, it says “internal network only”. Right below in the details, it says “Remote Access: enabled (No VPN)”. Details of Gateway is then listed under this.

        More grey hair… yay!

          1. Ok, thank you. Its working now. Had to rebuild the hole thing. Same settings though…

            A final question. Is it safe to assume that if the receiver cant resolve the internal beacon, the launch.ica should contain the encrypted address and connect through the NS, and if it CAN resolve the internal beacon, the launch.ica should contain the private, non-encrypted and direct server address?

          2. Kind of.

            If can’t connect to internal beacon, Receiver connects to Gateway (in the .cr file), authenticates, and Gateway connects to StoreFront. StoreFront sees the connection coming from Gateway and configures the SSLProxyHost.

  3. Hi Carl!
    Thanks a lot for great article

    Can you advice how to configure proper beacons on SF if we want to restrict access from any LAN,WAN devices only through NSGW ? Does it enough to fill internal beacon as special unresolved URL if all internal devices can access SF address?

    Thanks in advance

  4. Hi Carl. Your site has been a boon to my knowledge ramp up on all things Citrix, especially the NetScaler.

    I’ve enabled 2nd factor using RADIUS and all is working as expected. Now I need to find a way to redirect users who fail to authenticate via RADIUS to a website where they can register for 2nd factor.

    My question: Is it possible to have the NetScaler redirect users who failed 2nd factor authentication to a website on internal network via SNIP?

    1. There are logon error messages in resources/en.xml you might be able to edit to included a web link.

      Or nFactor has web-based authentication. You might be able to use that to redirect to a webpage but I haven’t tried it.

  5. Hi Carl,

    It is great to have some tweaks on StoreFont from your site, but I found that “localStorage[“showFtu”] = false;” will crash Citrix Receiver 4.4.1 Self Service. For your information, my XenApp is 7.9 with StoreFront 3.6.

  6. Hello Carl,

    Question on the Singly URL, I have split DNS and external public IP’s that are not accessible from the internal network. So I would like our external Gateway to point to the primary Storefront first. But I am a little confused on the post, what should I put in the host file? The call back URL for my primary and DR site? Should I put the External IP address in the SNIP part of gateway in the storefront?

    1. Callback URL is only needed for SmartAccess, smart cards, and SAML. If not using them then callback is optional.

      If you want Callback, then it needs to resolve to a Gateway VIP on the same appliance that authenticated the user. If your existing Gateway VIPs aren’t reachable, then create another Gateway VIP on the same appliance and point to that instead.

      The SNIP field is only needed if you have two Gateways (separate appliances) talking to one StoreFront. In that case you enter whatever Gateway VIP is configured on the appliance. Reachablity is not needed.

  7. Just wanted to be sure. thank you for the prompt reply! I was only curious as I’m getting the error described in this KB article and I’m not sure why.

    when I auth to NSGW I get the error mentioned in the article. Have you run into this issue before? If not I can contact citrix support, but it says in the article that single FQDN isn’t supported and this KB was created March of this year.

    1. You can do it several ways. If you want one Cert to match the Single FQDN, the callback FQDN, and the Internal Beacon then either a wildcard or a SAN (UCC) Cert would work. Or you can split them into different certs on different VIPs. If you need email-based discovery, then the Cert needs to match the email suffixes too.

  8. Hi Carl,

    Thanks for the great information as usual.

    Do you know if the single FQDN approach will work for mobile users when there are different authentication policies configured for NetScaler Gateway? E.g, we need to apply two factor authentication (LDAP + RADIUS) via NetScaler Gateway when a user is external to the network, which will hit a specific StoreFront store, but only one factor of authentication (LDAP) when the user is internal, which will also hit a separate store. Will the user still be able to roam inside and outside of the network without having to re-configure their iOS/Android Receiver client? The devices do not use any kind of VPN, just mobile data/personal WiFi externally and corporate WiFi internally (that allows access to StoreFront).

    Just trying to figure out where the smarts come in that tell Receiver whether or not it needs to provide for the RADIUS configuration – assume it is via the beacons.

    If this does work, do you have to use the .CR configuration file for this to be seamless – presumably via beacons? Or can users still manually configure the connection once (either internally or externally) and still have it all work seamlessly?

    Thanks mate. Rhys.

    1. Internal Beacon determines if Receiver needs to connect to Gateway or not. The .cr file contains the authentication that Gateway is expecting.

      When you first launch Receiver and enter a DNS name or email address, Receiver downloads the .cr file and configures itself. The .cr file contains beacons and Gateway config.

  9. I have configure NS Unified Gateway, and setup Storefront/XenDesktop as an application accessible through the UG. I can login to the UG, and launch applications from XenDesktop jst fine. I also have the following line added to the UG content switching policy: is_vpn_url || HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/Citrix/Portal”) || HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver”)
    When I try to use a native receiver client on IOS device, I get an error stating the address given did not provide a valid app list. Session policies look correct, and I believe the expression in the content switching policy is correct. Have you done much with the UG?

  10. Hi Carl,

    First off, great site – lots of very useful information on here, and thanks for maintaing it. You should include somewhere that people can make donations..

    We are setting up single FQDN site with a NetScaler and XA7.8, we have 2 controllers which are also hosting Storefront in a group.

    We have internal and external SSL certificates configured in IIS on the controllers, IIS is configured to require Server Name Indication for the internal and external DNS records – and that part is working fine. We can connect directly to the StoreFront Servers OK, and launch applications.

    On the NetScaler though, the XD_WISF_SVCGRP for the NetScaler Gateway site is saying down, and I cannot get it to come online. The wizard requests for the IP addresses of the Storefront servers, and we need it to use SSL….

    We have tried creating new server objects to add into the XD_WISF_SVCGRP and set the servername accordingly (to the internal name of the StoreFront servers, not the single FQDN) – but cannot get them to come online either

    Any idea what we are missing?

    Thanks, Paul

      1. OK, thanks for the swift response – we weren’t aware of that, and will split out the storefront role from the controllers

        Thanks, Paul

  11. Hi Carl, I have configured a single FQDN for external and internal access. I have setup a load balance VIP for storefront and that is working and I can log in fine but when I try to login via Netscaler I receive “cannot complete your request” in storefront and event id’s 10 & 7 in the event log under Citrix delivery services.

    event id 7 – CitrixAGBasic single sign-on failed because the credentials failed verification with reason: Failed.

    event id 10 – A CitrixAGBasic Login request has failed.
    Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticatorException, Citrix.DeliveryServicesClients.Authentication, Version=, Culture=neutral, PublicKeyToken=null
    Authenticate encountered an exception.
    at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)
    at Citrix.Web.AuthControllers.Controllers.GatewayAuthController.Login()

    System.Net.WebException, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
    The remote server returned an error: (403) Forbidden.
    ExceptionStatus: ProtocolError
    ResponseStatus: Forbidden
    at System.Net.HttpWebRequest.GetResponse()
    at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(HttpWebRequest req)
    at Citrix.DeliveryServicesClients.Authentication.TokenIssuingClient.RequestToken(String url, RequestToken requestToken, String primaryToken, String languages, CookieContainer cookieContainer, IEnumerable`1 acceptedResponseTypes, IDictionary`2 additionalHeaders)
    at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)

    1. Do you have callback configured? Is TLS 1.0 enabled on the callback vServer?

      Is loopback set to OnUsingHttp?

        1. Loopback is different from callback. Your events show Setting it to OnUsingHttp will change it to

          Is your NetScaler session policy supplying a domain name? Does that domain name match what’s configured in “Configure Trusted Domains”?

          1. I can see that it is enabled in webconfig on storefront server, is this what you mean?

            My session policy is supplying a domain name and that does match what I have set in storefront.

  12. Hi Carl,

    Great article.

    With the new release of 7.8, is there a way to configure a fail-over delivery group for published desktops, like what can be done for published apps.

    – a single XD/XA 7.8 site spanning multiple data centers (2 zones),
    – Site A / Site B delivery groups
    – Apps are published primarily from Site A delivery group, with Site B delivery group configured as a different priority (so apps can fail over if Site A delivery group is unavailable)
    – 2 * Storefront 3.5 in a single server group, one server at each site

    Please let me know if you would like information.

    Much appreciated

    1. NetScaler 11.0 build 65 is supposed to have a new GSLB/zones feature. Then you can use GSLB to handle the failover. This requires StoreFront 3.5.

  13. Hey Carl,

    Making some decent progress with Storefront multi site aggregation. I’ve managed to get 4 sites aggregated and set up 2 as load balanced and 2 as failover. This is all working as expected with users connecting to their homesite apps through the various storefront server groups. However I have a new requirement now whereby in the active/passive site configured as failover some apps have to be run only from the failover site. This is more to do with when the design evolves as it will no longer be strict active/passive. The problem i’m having is setting the keywords. I have the primary site and failover site so all apps are launched from the primary but I have tried setting one app in the failover as KEYWORDS:Primary and the same identical app in the primary as KEYWORDS:Secondary.

    However this setting seems to be getting completely ignored. I am still see launches to the app from the Primary site and only launched from the failover site if the primary site is down. I expected this particular app to launch from the failover site and only from the primary site if the failover site had a problem.

    This is with StoreFront 3.01 and XenApp/Desktop 7.7.

    Is this how it is meant to work and if there is no other config required possibly something has broken with keywords since some changes have been made in this area in the latest release?


    1. Are both farms in the same equivalentFarmSet? If so, they need to be split out and use Aggregation attribute to aggregate them.

      1. hi Carl,

        Thanks for your speedy reply. This is the current configuration I have and on the failover farmset, I have two farmsets as you can see below. The nafarm is the one where I am configuring the keywords on certain applications to make the backup/failover site the KEYWORDS:Primary on some applications. Is there any obvious mistakes?


        1. resourcesWingConfigurations
          resourcesWingConfiguration name=”Default” wingName=”Default”
          clear /
          userFarmMapping name=”nafarm”
          group name=”corp\domain users” sid=”S-1-5-21-xxxxxxxxxxxxxxxxxxxx” /
          equivalentFarmSet name=”nafarm” loadBalanceMode=”Failover” aggregationGroup=”aggregation1″
          farm name=”Houston Site” /
          farm name=”Dallas Site” /
          equivalentFarmSet name=”eufarm” loadBalanceMode=”LoadBalanced” aggregationGroup=”aggregation1″
          farm name=”LondonSite” /
          farm name=”HenleySite” /
          backupFarmRefs /

          1. In which farms are the keywords? The config you posted only enumerates icons from two farms at a time: Houston, and either London or Henley (but not both). The other farms are only enumerated if the primaries are down.

            If you want to enumerate both Houston and Dallas then they need to be in separate equivalentFarmSets. Order them so Houston is first, Dallas is second.

          2. Hi Carl,

            The keywords are In Houston and Dallas. The Dallas site is the DR site which is why it’s configured as a Failover, so applications would only be launch from this site if Houston failed, however certain applications will eventually need to be launched from just dallas which is why I was trying to use the keywords as I thought those overwrote any HAA config in Storefront and would take preference to launch an app providing it’s keyword was Primary.

            So in order to use the Keywords on the apps I’d need to create another equivalent farm set for Dallas? but list it in Storefront after Houston farmset?


          3. That would be my guess, yes. If it’s not enumerating the other farm then it can’t see the keywords. See 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.

          4. Hi Carl,

            I’ve tried splitting out the sites into seperate farmsets and made Houston the first one and Dallas second. It still doesnt work and seems to completely ignore the keywords. I can check both sites can be enumerated by removing one farmsets from the config. For example removing the Houston farmsets I still see all the app icons but launched then occur on Dallas.


          5. Hi Carl,

            I see, that makes sense in logical way if the apps are not being enumerated then it will only be seeing the secondary keyword and I guess then it just connects to that as it doesn’t see any primary one. I’ll give it a go tomorrow and let you know how it goes. Thanks again!


  14. hey Carl,

    I’ve been configuring StoreFront 3.0.1 for Multi-site and resource aggregation across 3 sites running XenApp 7.7. The config is given below. This all seems to work and I get aggregated single icons for apps and desktops. The failover also works. However what I am finding is reconnect to disconnected sessions is not working. If I connect to one of the UK load balanced resources which is a desktop and then disconnect it. If i then log in and click the icon again it might launch me a new session on the other uksite. So I end up with a lost disconnected session which I might never be able to reconnect back to. Also I found auto reconnect to disconnected sessions after logging in to Storefront does not seem to work. I have turned off user subscriptions.

    Any idea what might be wrong and why reconnect to disconnected sessions is not working in the multi site config?


    1. resourcesCommon
      resourcesWingConfiguration name=”Default” wingName=”Default”
      clear /
      userFarmMapping name=”allusers”
      group name=”corp\domain users” sid=”S-1-5-21-xxxxxxxx
      equivalentFarmSet name=”eufarmprimary” loadBalanceMode=”LoadBalanced” aggregationGroup=”aggregation1″
      farm name=”uksite1″ /
      farm name=”uksite2″ /
      farm name=”ussite1″ /
      equivalentFarmSet name=”usfarmprimary” loadBalanceMode=”Failover” aggregationGroup=”aggregation1″
      farm name=”ussite1″ /
      farm name=”uksite1″ /

      1. managed to get apps to auto reconnect on logon but the desktop sessions don’t. The desktop session seems to be the one when set to load balanced in storefront sometimes it creates a new session from another site rather than reconnecting to the disconnected one. My delivery group type is apps and desktops for Windows 2K12.

          1. yeah the desktops all have the same name but only 1 icon in storefront. I can test to make sure it works by putting the delivery groups in to maintenance mode at each site. I removed the backup farm refs from the above just leaving the two primary ones, the first has the 2 UK sites which should take priority and the second the US site. I put one of the UK delivery groups in to maintenance mode and launched the desktop expecting it to launch from the other UK site and it launched from the US one? what the heck! but then when I put the US one in to maintenance mode and just leave the single UK one then it launches from that.

            Maybe storefront doesn’t like desktops with resource aggregation 🙁

    2. See Scenario 3 at Here’s somebody else struggling with reconnect:

      Maybe the backupFarmRefs are interfering with the reconnect? For identical icons available in all three sites, the two UK sites will be used first, then US last, because that’s the order of the equivalentFarmSets. Thus you probably don’t need the backupFarmRefs.

  15. Hi Carl,

    Awesome site by the way, loads of useful information. I will be bookmarking it forever:)

    I am working on one Xenapp 7.6/7.7 design at the moment where the company want to replace an existing XenApp5.0 and XenApp6.0 global farms. They have a number of global farm set ups which span various locations. They use load balancers to direct users to their local farm based on IP. They connect in through Storefront and have some F5 LBs between storefront and XenApp XML farm to get this to work.

    They also use the XenApp worker groups and zones with priorities based on users/location in each farm.

    Some farms are active/active, some active/passive.

    For Xenapp 7.6/7.7 obviously zones/priorities/load balancing works differently.

    I am thinking about using powershell to publish apps in sites across multiple delivery groups, to use similar to worker groups and set priorities for failover. I can also use Storefronts at each datacentre to set primary and backupfarm refs based on user groups.

    However one bit I’m struggling with is some users in farm B lets say in the US still require certain applications from farm A in the UK. So those users will connect in and be sent to farm B, in Xenapp because they have global farms they also have worker groups configured in the UK on them and publish the apps for the UK that way.

    If I have separate XenApp 7.6/7.7 sites I can’t really add a UK catalog to it and publish the apps. What I was thinking is if I add all Xenapp7.6/7.7 sites to each Storefront in each location and then on the UK site set the app limit visibility options to only enumerate particular apps for certain users in the US as not all US users need access to the UK apps.

    Effectively the design is multi site, local users to their own local site/apps but sometimes need access to apps in other sites.

    Do you think this is the best way to achieve it or is there some other options I should look in to?


    1. Citrix does not have a good multi-datacenter solution yet. Today I would do different farms in each datacenter and use App Visibility Limits, or KEYWORDS:Primary or StoreFront UserFarmMappings to control access.

      7.7 has a first release of zones that will eventually help but failover is currently an limitation.

      1. HI Carl,

        Thanks for the reply. A bit more info is there are 3 physical locations, lets say UK, US, APAC. A travelling user from US is in the UK and wants to launch Word. As work is common the StoreFront in UK would contain UK, US and APAC sites and perform resource aggregation on all 3 sites (is this even possible, most designs talk about two sites only) to show a single icon for Word. In StoreFront UK the UK site would be Primary so the user from the US would launch Word from the UK site. Can you have one site as Primary and the other two sites in Storefront as Secondary, how does it work with 3 sites?

        Also the same user would require access to certain applications only available in the US and APAC so they could be enumerated as normal in StoreFront based on who has permissions to them and the apps would launch from their respective regions.

        So at the moment I’m not sure how I would configure the 3 sites in Storefront to ensure users launch apps from the nearest site based on location (unless you can set sites in storefront with priorities like 0,1,2 so UK would be 0, US would be 1 and APAC would be 2 in the above scenario for when common applications are available in each region. Basically they don’t want a US user in UK to launch his Word app from the US.


          1. HI Carl, thanks for this link I hadn’t seen this page before so it should help. I think in the end for active/passive we are going to opt for publishing apps to multiple delivery groups across the site based on delivery group priorities having the backup/DR as the fail-over group. This should keep the admin down although has a powershell cost.

            For active/active i think we’ll go for multi site as trying to configure desktop groups with machines from multiple catalogs eg, catalog in London and Edinburgh for active active in case of a site failure and then having to create all the access policies/app entitlement policies through powershell at the moment is just going to be too much overhead as there are around 70 app silo’s on xenapp 6 and over 1000 apps…so having two separate sites and using Storefront to load balance seems to be the best option.

            I’ll let you know how we get on and if we hit any issues with the Storefront config.

  16. Carl,
    Under the “Single FQDN”, items #1 and #2 use same example (“”), first stating this should resolve to internal VIP and later stating it should be external IP. From StoreFront server, what should the base URL resolve to?
    I am struggling with configuring Receiver for Windows, read lots of posts from you on Citrix forums but still not couldn’t solve it. Can you provide us a copy of the “Receiver_.log” generated on your PC when connecting from an external location?

    1. You need split DNS. The same FQDN should resolve to different IPs for internal vs external. Internal resolves to StoreFront (load balancing VIP). External resolves to NetScaler Gateway VIP.

      The Base URL should be the single FQDN.

      In Receiver, Beacons are critical. Make sure the internal beacon is not resolvable/accessible externally.

  17. Carl for single fqdn case, i’m still not clear. I was planning to get an san cert with fqdn and add i’m not gonna use email based discovery. So for single fqdn, is this cert request ok?

    1. What is for?

      Callback is optional. You can skip it if you don’t need SmartAccess.

      Email-based discovery is optional.

      If you have internal iOS/Android devices then the Internal Beacon needs to resolve to the StoreFront server and thus you’ll need a SAN Name for the Beacon. If you don’t have internal iOS devices then the Internal Beacon can be anything internal.

  18. Hi Carl.

    I have a multiple Gateways to storefornt lb setup, and the two Gateways have different authentication Methods (both are two-factor though). But after we have logged on to the Gateway that is not set as default, and have selected the store, we are prompted With authentication from the Gateway that is set as default in storefront.

    Do you have any idea how we can log on only one authntication?

    1. Non-default Gateways have to be selected at the client side after discovery is complete. Receiver for Windows has a drop-down for selecting the Gateway.

  19. Hi Carl. I have SF 3, NS 10.5 and XA6.5 setup using the single fqdn. Works perfectly. The only thing it doesn’t do (by design according to CTX134123) is allow me to use HTML5 internally. it works externally and full receiver client work internally and externally. I would need to point internal users to the NS Gateway VIP instead of the Storefront LB VIP but I cant find any docs on this at all. When I simply change the DNS of internal storefront to the Gateway VIP it works but other things break. Any thoughts?

      1. hi Carl, this new gateway will be on internal load balanced netscaler or a second new gateway on external netscaler where 2FA authentication has been configured?

        1. New gateway? For Internet users, the gateway is on the DMZ appliance. If you need AppFlow reporting for internal users then gateway is on the internal appliance.

  20. Hi Carl, I want to see you, if I have two servers store.front (SF1 and SF2), each server has different applications. for internet access from each server must have a profile session or you can select which server to connect

    1. Is each SF server pointing to different farms?

      One option is different DNS names for each SF server.

      Or you can use AD group membership to select the server for the user.

      Or if you create multiple Stores on the same SF server then users can choose between Stores.

        1. When using Receiver Self-service to connect to StoreFront, it should list all stores and let the user choose.

          Browsers only go to one Store unless you change the URL.

          1. hello Carl, I have my storefront site A and site B, I want to access from the Internet through the NetScaler to the site you select (site A or site B), as I do ??

  21. Hi Carl, when I access from the external IP address, I first earned the NetScaler, I then authenticate on page Citrix Receiver, but not entry and stay in the authentication page Citrix Receiver and does not leave any errors, think we have the same error.
    some solution ?, thank you very much

  22. Hello, I step by step, but I have the following error:

    A request was sent to service ‘Authentication Service’ that was detected as passing through a gateway. This service is configured with the gateways [xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx], but none of these matched the request. Request details:
    X-Citrix-Via-VIP: xx.xx.xx.xx
    Remote Address: ::1
    X-Forwarded-For: xx.xx.xx.xx,xx.x.xx.xx

    can you help me?

    1. Does whatever you entered in your browser’s address bar match one of the Gateways you configured in StoreFront? Don’t enter an IP address. It must be a FQDN.

      1. Hi Carl, I think the mistake is that the storefront does not trust the server certificate Gateway NetScaler., can you help me?

        1. Are you using https for your Base URL? Can your Gateway resolve (DNS) the Base URL into an IP address? Any errors in the StoreFront server > Event Viewer > Applications and Services > Citrix Delivery Services?

          1. Thanks for answering,
            Yes I am using https based URL, the NS solves the base URL to an IP address and in the event viewer shows:

            A request was sent to service ‘Authentication Service’ that was detected as passing through a gateway. This service is configured with the gateways [2dg86ec6-9d57-4c9d-b403-0b507e32819b], but none of these matched the request. Request details:
            Remote Address: ::1

          2. In StoreFront, did you create a Gateway object that matches After creating it, did you bind it to the store?

          3. Hi Carl, did not understand how to create gateway object, this is part of my settings:

   = VIP
   = NSIP
   = SNIP

            Storefront config
            Storefront ->Base URL: https://storefront00.dominio.local
            Storefront ->Netscaler Gateway URL:

            A request was sent to service ‘Authentication Service’ that was detected as passing through a gateway. This service is configured with the gateways [2dg86ec6-9d57-4c9d-b403-0b507e32819b], but none of these matched the request. Request details:
            Remote Address: ::1

            I think the storefront, not me validating the SSL certificate installed on the NetScaler.

            thank you

          4. Storefront ->Netscaler Gateway URL-> Change General Settings. Set the FQDN to instead of Also makes sure the Subnet IP field is blank.

  23. Getting following error on Delivery controller for most of the users and users are getting “Can’t start app” or “Remote desktop Services busy”

    Event ID 1101: The Citrix Broker Service failed to broker a connection for user ‘domain\username’ to resource ‘Global Expense’. The Citrix Broker Service cannot find any available virtual machines.

    Please add more virtual machines to the site. If the problem is due to existing virtual machines not becoming available, see Citrix Knowledge Base article CTX126992.

  24. Can I use netscaler to SSL-offload storefront? I want to have the storefront server using http but use the netscaler as a fronted for storefront and have the certificate there. Will receiver accept this, if I point the Ag-options storefront and account url against the load balanced ssl server which points to http storefront?

    Also would it be possible to use frame hawk this way?

    1. What exactly is not working? To disable auth at the Gateway, open the Gateway vServer, in the Basic Settings section click the pencil icon, click More, and uncheck Enable Authentication.

  25. Hi Carl, If i wish to use a single FQDN externally and internally in a multisite configuration
    with only one HA pair per site (no internal netscaler tier) I think I will need to implement DNS views to distinguish the internal users so that they will be given the storefront vip by the policy bound to the GSLB service and not the gateway VIP. I will have both an external and internal ADNS listener. I will be using the method of using a cname to a gslb subdomain which is delegated from the parent domain. In this configuration I need an external and internal DNS gslb subdomain or will one glsb subdomain suffice (ie one gslb service for both internal and external with dns view)?

    i hope this makes sense

    1. DNS View will work. Keep in mind that NetScaler has only a single table of DNS records so if you have internal-only GSLB DNS names then they could be resolved through the external ADNS listener.

      1. Hi Carl

        I have internal GSLB Active / Active but not external (yet). When connecting to the external site using the internal single FQDN I am receiving the can not complete your request. If I disable one of the GSLB LB VIPs the error is gone. Is this not a possible configuration or am I missing something. I don’t want to break the GSLB config internal so I could set the DNS on the netscaler to one site for the storefront vip.

        Thanks for any advice you have.

        1. Does “external” mean through a Gateway? If so, do you have callback URL configired?

          Is DSLoopback enabled on your StoreFront servers?

          1. Yes via gateway, no callback as I thought this was optional unless using smart access. Yes loop back via http is enabled. Was going to try a callback but it works well with one GSLB internal VIP disabled. Just to be clear the FQDN configured on the gatway points to an internal GSLB (two HA pairs in diffrent sites). Internally it works great!

  26. In the Citrix edocs they use the beacon url as the accounts service address in the NS gateway receiver session profile and then they edit the in the web.config on the storefront server. I assume this is why they need to add the additonal SAN to the certificate with the DNS name of the internal beacon.

    1. There are two different sets of instructions for the Single FQDN: one set is for SmartAccess Mode (ICA Only unchecked) and the other is for Basic Mode (ICA Only checked). The Basic Mode instructions do not use the Accounts URL in the Account Services address.

  27. Hi Carl, thnx for sharing your knowledge. I have a question about the Single FQDN on storefront 2.6. We use two factor authentication to authenticate our users from outside and internal users should be authenticating with domain only credentials. Is Single FQDN still possible with this kind of configuraiton? Can we configure Single FQDN that all users who are connecting form internal network only gets domain credentials?

    Also what are the dns records i need to create? So far i understand i dont make any DNS record for the Callback urls. Is that true?

    Thanks a lot for your time.


    1. When Receiver connects directly to StoreFront then two-factor is not an option. This should fulfill your requirements. Internal users should resolve the StoreFront FQDN to the load balanced VIP and not to the Gateway VIP.

      Callback is only used between the StoreFront servers and the Gateway VIPs so if you can edit the HOSTS file on the StoreFront server then there’s no need to add it to DNS.

  28. Hi Carl,

    Just a note on the call backs for the single FQDN. Another option is to use the same external dns entry with a different port number. Where by then, you do not need to spend extra on SAN certs if wildcard certs are not an option.


    1. Interesting idea. If the HOSTS file on StoreFront resolves the single FQDN to the StoreFront SSL load balancing VIP then you might be able to create a callback Gateway vServer on the same VIP but a different port and thus use the same DNS name for both. There would be a different Gateway VIP for external users so it can listen on 443.

      Another option is to create a separate Gateway VIP with a different DNS name but use an internal cert. This avoids the public SAN cert cost.

  29. Hi Carl, do you know what changes on the netscaler LB configuration with or without the certificates installed on the frontend servers? does the configuration change on the web interface address under “pubblished applications” only fron http to https or more?


    1. Receiver requires StoreFront to be SSL encrypted so you need to do SSL at the load balancer. The address should always be https.

Leave a Reply