StoreFront 3.0 and older Config for NetScaler Gateway

Last Modified: Nov 7, 2020 @ 6:35 am

Navigation

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

Docs.citrix.com – 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 docs.citrix.com 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. storefront.corp.com). 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. storefront.corp.com). 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. storefrontcb.corp.com) 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. Ideally, the Internal Beacon should be a new DNS name that resolves to the StoreFront Load Balancing VIP. However, this requires the StoreFront Load Balancing Virtual Server to have a certificate that matches both the Single FQDN and the Internal Beacon. See CTX218708 How to Configure Internal Beacon for Single FQDN on StoreFront.  💡

    • 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:
    • Storefront.corp.com resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com.
  • External publicly-signed certificate for NetScaler Gateway:
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • StorefrontCB.corp.com – 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, discoverReceiver.email.suffix
  • Internal DNS:
    • Storefront.corp.com resolves to Load Balancing VIP for StoreFront
    • StoreFrontCB.corp.com – 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 _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com.
  • 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 *.corp.com. Assumes email suffix is also corp.com.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • If email-based discovery, discoverReceiver.email.suffix

StoreFront Configuration:

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

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 = https://storefront.corp.com/Citrix/StoreWeb
    • 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 = https://storefront.corp.com/Citrix/StoreWeb
    • 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 = https://storefront.corp.com
        • Web Interface Portal Mode = Normal
        • Single Sign-on Domain = Corp
        • Account Services address = https://storefront.corp.com

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.

Docs.citrix.com 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: https://citrix.sharefile.com/d/sa562ba140be4462b

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 Docs.citrix.com: To configure optimal NetScaler Gateway routing for a store. For an example configuration see Docs.citrix.com: 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: gateway-prod.corp.com and gateway-dr.corp.com.
  • 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

195 thoughts on “StoreFront 3.0 and older Config for NetScaler Gateway”

  1. Hi Carl,

    We have configured NetScaler Gateway URL and configured Internal Beacons. When we log in from our laptop it works fine and can see apps with one time authentication.
    When we log in from Dell Wyse Thin clients using Gateway URL, we need to authenticate twice with the credentials. First prompt as usual from NetScaler Gateway. Once entered the credentials and clicks on Logon it will prompt another window with the same user name and password fields with a message “INFO: Waiting for Credentials to Login Workspace” This happens only with the Gateway URL but not with internal storefront URL. Please help to fix the issue

  2. Hi Carl,
    Many thanks for EVERYTHING!….

    One quick question, If we have SF 3.5 and above, is there a requirement for callback url?
    We are using basic LDAP and RADIUS auth on the gateway. Although SmartAccess is enabled on the Gateway vServer. No EPA being used on the gateway.

    Thanks in advance.

      1. Thanks for the reply Carl…

        So if I have SmartAccess enabled (“ICA only” turned off) on the gateway, do I need the callback url?

        I am not using SAML authentication or Smart Cards.

        1. No. SmartAccess means Access Control or Access Policy on your Citrix Policy Filters or Delivery Groups.

          1. Interestingly Citrix support just came back with:

            “Callback URL is needed if you configure smart access on the gateway”

            Hmmm… ?

  3. The link “See CTX218708 How to Configure Internal Beacon for Single FQDN on StoreFront. 💡” no longer works – says 403 no access….maybe it is top secret? 🙂

  4. Error: “Cannot Complete Your Request”

    Failed to run discovery
    Citrix.Web.DeliveryServicesProxy.ConfigLoader.DiscoveryServiceException, ReceiverWebConfigLoader, Version=2.6.0.0, Culture=neutral, PublicKeyToken=null
    An error occured while contacting the Discovery Service
    at Citrix.Web.DeliveryServicesProxy.ConfigLoader.Discovery.AppendConfigurationFromDiscoveryService(WebReceiverConfigSection section)
    at Citrix.Web.DeliveryServicesProxy.ConfigLoader.Discovery.RunDiscovery(WebReceiverConfigSection configSection)
    at Citrix.Web.Proxy.Filters.DiscoveryComplete.OnAuthorization(AuthorizationContext filterContext)

  5. Hi Carl, I can only access my website if I remove the S from the http, in the url base, this happens because some certificate expired?

    1. Receiver is picky about the certificate. Make sure the certificate is valid: matches the FQDN, isn’t expired, trusted, not revoked, etc.

      1. Hi Carl, I have the doubt which of the certificates is affecting me, the implementation is done a couple of years ago, the certificate is not found in the storefront

    1. For multiple Gateway URLs, in StoreFront Console, add multiple Gateway objects and bind all of them to the Store.

      For multiple StoreFront URLs, edit c:\inetpub\wwwroot\citrix\roaming\web.config and search for allowedAudiences. You might have to add it in other web.config files too.

  6. Carl. I am in the replacing a CSG with a ADC13. The client has a single DDC that has a StoreFront version 2.6 and Studio Version 7.6. Will I be able to integrate the new ADC 13 at the current version levels, with the intention of upgrading Storefront and Studio after I deprecate the CSG?

  7. Hi Carl,

    We notice a very high amount of traffic from the VPN users (10000 packets/sec/user). That seems to cause some latency on the network.

    Can you please advise me how to troubleshoot?
    Please let me know if you want more info.

    Thank you

    08:43:12.033962 IP 10.1.111.23.138 > 10.1.111.255.138: NBT UDP PACKET(138)

  8. We have 2 netscaler appliances and iis load balanced through another netscaler LB. Now we need to configure call back url in storefront. In published application URL on both netscaler VIP is same store URL.

    how we can achieve to use same store for both netscaler appliance callback URl. on the poublished applictaion URL on both netscaler VIP is same store URL.

    This is required to use smart access feature in DDC.

  9. hi Carl. i am deploying xenmobile where in i have two Netscaler Gateways one for DMZ and One for LAN users and both the Gateways have same FQDN’s. so my use case is Two Netscaler Gateways with same FQDN and one storefront server. How will the call back happen as in storefront we can only have one DNS resolution happening either to DMZ VIP or LAN VIP? can you please help me understand

      1. Thanks Carl, for your response.

        The Gateways are on different Appliances. Any other way that we can achieve this use case other than GSLB?

        1. I only mentioned GSLB because it commonly leads to multiple appliances taking to one StoreFront. Otherwise, add two Gateways to StoreFront with the same DNS name but each Gateway has a different VIP and different Callback URL as detailed in that section.

          1. Hi Carl, but my both NetScaler Gateways have same FQDN’s (one Gateway for DMZ traffic and one Gateway for LAN traffic) but the virtual server IP are different.

            Lets Say for Example:-

            DMZ CallBack URL = https://mamgateway.corp.com
            DMZ Gateway VIP = 10.x.x.x.

            LAN CallBack URL = https://mamgateway.corp.com
            LAN Gateway VIP = 192.x.x.x

            So I need to create two Netscaler Gateway in StoreFront one for DMZ and One for LAN. As both the Gateways have different VIP that should be fine but how about CallBack URL as both the Gateway FQDN’s are same? to which Gateway VIP do we need to create DNS record DMZ VIP or LAN VIP, as we can only have one DNS record created in DNS Server?

            As I mentioned earlier this configuration is for Citrix Endpoint management (XenMobile).

            Thanks a lot for your help on this. Really appreciate it.

          2. Create new callback DNS names, one for each appliance. You need certificates that match the new callback DNS names. You either create a new Gateway on each appliance with the new certificate, or you ensure your existing Gateway on each appliance has a certificate that matches both DNS names. The callback can go to any Gateway on the same appliance that authenticated the user.

          3. Thanks a lot Carl, for you response.

            In my scenario I have same FQDN for both NetScaler Gateway’s (DMZ Gateway and LAN Gateway). So to confirm for example:

            DMZ Gateway FQDN = “mamgateway.corp.com” , DMZ VIP = 10.x.x.x

            LAN Gateway FQDN = “mamgateway.corp.com” , LAN VIP = 192.x.x.x

            So on Storefront I should be creating Two NetScaler Gateway Appliances

            1. DMZ NetScaler Gateway Appliance on Storefront

            NetScaler Gateway URL = https://mamgateway.corp.com

            Vserver IP = 10.x.x.x

            Callback URL = https://DMZ-mamgateway.corp.com and create local DNS record on Storefront with this FQDN pointing to above Vserver IP.

            2. LAN NetScaler Gateway Appliance on Storefront

            NetScaler Gateway URL = https://mamgateway.corp.com

            Vserver IP = 192.x.x.x

            Callback URL = https://LAN-mamgateway.corp.com and create local DNS record on Storefront with this FQDN pointing to above Vserver IP.

            Question 1: Is the above configuration correct?

            Question 2: As my MAM Gateway FQDN and Callback URL FQDN’s are different, do we see any challenge with this or will this work?

            JFYI, This configuration is for Citrix Endpoint Management (XenMobile) deployment.

            Thanks in ADVANCE for your help. Really Appreciate.

          4. The callback can resolve to any Gateway VIP on the same appliance. It doesn’t have to resolve to the original VIP.

            If it resolves to the original VIP, then that VIP’s certificate must match both the MAM DNS name and the Callback DNS name.

          5. Hi Carl, the Two Netscaler Gateway’s (DMZ and LAN Gateway) are on two different NetScaler Appliances and we will be using wildcard certificate for both the NetScaler Gateway’s.

  10. Hi Carl,

    Hope your are doing good!!

    We are running with the problem from last one month in XenDesktop CU6. when users login into storefront server there are getting issues like “There are no apps or desktops available to you at this time” we checked users are already member of their delivery groups. we are resolving this issue by restarting the DDC. we having configuration the port 80 between storefront and DDC. Please suggest what are the troubleshooting we can perform to resolve this issue.

    Please reply I am waiting for your reply.

    1. What errors are you seeing in StoreFront event log and Broker event log?

      Have you contacted Citrix? If a reboot fixes it, then either not enough resources for Controller, or there’s a bug somewhere.

Leave a Reply

Your email address will not be published. Required fields are marked *