StoreFront 3.5 through 3.12 – Configuration for NetScaler Gateway

Last Modified: Oct 16, 2017 @ 6:00 pm

Navigation

This article applies to StoreFront versions 3.5, 3.6, 3.7, 3.8, 3.9, 3.11, and 3.12.

StoreFront Configuration for NetScaler Gateway

See the NetScaler pages for instructions on creating a NetScaler Gateway Virtual Server for ICA Proxy and StoreFront. You then must configure StoreFront to enable the Gateway.

  1. In the StoreFront Console, in the middle, right-click your Store, and click Manage Authentication Methods.
  2. Ensure Pass-through from NetScaler Gateway is selected, and click OK.
  3. In the StoreFront Console, right-click the Stores node, and click Manage NetScaler Gateways.
  4. If StoreFront 3.6 or newer, notice the imported from file link on top. This is a new feature of NetScaler 11.1 and newer. An example configuration that uses this feature can be found in the StoreFrontAuth page.

  5. If you’re not using the Gateway config file from NetScaler 11.1 and newer, click Add.

    1. In the General Settings page, enter a display name. This name appears in Citrix Receiver, so make it descriptive.
    2. In the NetScaler Gateway URL field, enter the NetScaler Gateway Public URL that resolves to the NetScaler Gateway VIP. This can be a GSLB-enabled DNS name. Click Next.
    3. In the Secure Ticket Authority page, click Add.
    4. Enter the URL to a XenDesktop Controller. This can be http or https. Click OK.
    5. Continue adding Secure Ticket Authorities (XenDesktop Controllers). Whatever Secure Ticket Authorities you add here must also be added to the NetScaler Gateway Virtual Server on the NetScaler appliance. Click Next.
    6. In the Authentication Settings page, the vServer IP Address field is typically left blank. You only use this field if you have multiple Gateways (on separate appliance pairs) connecting to one StoreFront server. See below for details.
    7. If you need SmartAccess, then enter the Callback URL.
      • The Callback URL must resolve to any NetScaler Gateway VIP on the same appliance that authenticated the user.
      • If you are configuring Single FQDN, then the Callback URL must be different than the Single FQDN.
      • Edit the HOSTS file on the StoreFront server so the Callback URL resolves to NetScaler appliances in the same datacenter.
      • The Gateway Virtual Server that the Callback URL resolves to must have a trusted and valid (matches the FQDN) certificate.
      • The Gateway Virtual Server that the Callback URL resolves to must not have client certificates set to Mandatory.
    8. If you don’t need SmartAccess, then leave the Callback URL field empty.
    9. If you enabled two-factor authentication (LDAP and RADIUS) on your NetScaler, change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
    10. Click Create.
    11. Then click Finish.
  6. You can add more Gateways depending on your design. Multiple datacenters typically requires multiple Gateways. Click Close when done.
  7. To enable the store to use NetScaler Gateway, in the middle, right-click your store, and click Configure Remote Access Settings.

    1. Check the box next to Enable Remote Access.
    2. Leave it set to No VPN tunnel.
      1. Note: if you want Receiver to automatically launch a VPN tunnel, then see CTX200664 How to Configure Receiver for Seamless Experience Through NetScaler Gateway.
    3. Check the box next to the NetScaler Gateway object you just created. This binds the Gateway to the Store.
    4. If you have multiple Gateways, select one of them as the Default appliance.
      • Note: when you point Receiver to a NetScaler Gateway URL for Discovery, after Discovery is complete, the Default appliance selected here is the Gateway that Receiver uses. In other words, Receiver ignores the Gateway you entered during discovery.
    5. Click OK to close the Configure Remote Access Settings dialog box.
  8. In the StoreFront Console, right-click the Stores node, and click Manage Beacons.
  9. In the top half of the window, make sure the Internal beacon is set to a URL that is only reachable internally.
    1. If you are configuring Single FQDN, then the Internal beacon must be different than the Single FQDN.
    2. Service URL = the StoreFront Base URL. If you’re not configuring Single FQDN, then the Base URL is usually not accessible externally.
    3. The Internal beacon must never go down. If it’s down, then internal native Receivers will stop working.
    4. Click OK when done.
  10. Right-click the Server Group node, and click Propagate Changes.

NetScaler Gateway Logon Page Theme

To make the NetScaler Gateway logon page look like Receiver 3.0 and newer, see one of the following:

Single FQDN

Overview

Links:

You can either define separate FQDNs for StoreFront Load Balancing (internal) and NetScaler Gateway (external). Or, you can define a Single FQDN for both.

Single FQDN has the following requirements:

  • Receivers:
    • Receiver for Windows 4.2 or newer
    • Receiver for Mac 11.9 or newer
    • Mobile Receivers
    • It doesn’t seem to work with Linux Receiver
  • StoreFront 2.6 or newer
  • Split DNS – different DNS resolution for internal vs external
    • Internal DNS should resolve the Single FQDN to the StoreFront Load Balancing VIP
    • External DNS should resolve the Single FQDN to the NetScaler Gateway VIP (public IP)
  • NetScaler 10.1 or newer
  • The FQDN for Internal Beacon must be different than the Single FQDN.
    • The Internal Beacon URL must not be externally resolvable or accessible.
    • If Internal Beacon is down, then internal Receiver Self-Service clients will not function correctly.
    • Internal Beacon URL can be http instead of https.
    • If Internal Beacon URL is https, then the machine hosting the IP address for the Internal Beacon must have a certificate that matches the Internal Beacon FQDN.
  • The FQDN for NetScaler Gateway Callback must be a different FQDN than the Single FQDN. Callback is only needed for SmartAccess and SAML.
    • Callback FQDN can resolve tot he same Gateway VIP used by external users. Or, you can create a new Gateway VIP on the same appliance that authenticated the users.
    • The Gateway Virtual Server for Callback must have a certificate that matches the Callback FQDN.

DNS caching interferes with Single FQDN – Note: if you have laptops that move from internal to external and back again, then DNS caching will interfere with Single FQDN. The DNS response for Single FQDN needs to change whenever the device moves from internal to external and back again. However, Receiver uses the same DNS cache as Internet Explorer, which caches DNS responses for 30 minutes. To clear the DNS cache, you have to close Receiver and re-open it. The DNS response you see when you ping the Single FQDN does not necessarily match the DNS response used by Internet Explorer and Receiver.

Configure Single FQDN without email-based discovery

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). Internally, the DNS name resolves to the 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). Externally, the DNS name resolves to a public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler. Set the NetScaler Gateway object in StoreFront to this FQDN.

  3. If you need SmartAccess, then the Callback URL = any DNS name (e.g. callback.corp.com) that resolves to a NetScaler Gateway VIP on the same DMZ NetScaler appliance that authenticated the user. The Callback URL cannot be the Single FQDN.

    • Callback URL can be omitted if you don’t need SmartAccess features, or SAML authentication.
    • The callback DNS name must be different than the Single FQDN.
    • The callback DNS name must resolve to a NetScaler Gateway VIP on the same appliance that authenticated the user. This could be the same DMZ Gateway VIP used by external users. Or you can create a separate internal Gateway VIP on the same appliance.
    • The NetScaler Gateway vServer for callback must have a certificate that matches the Callback DNS name.
  4. Internal Beacon = any internal website URL that is not externally accessible. You can’t use the Single FQDN as the Internal Beacon. Note: if the internal beacon is down, then internal Receiver Self-service will not work correctly.

    • Make sure the Internal Beacon is not resolvable externally.
    • The Internal Beacon URL cannot be the Single FQDN. It must be different.
    • Ideally, the Internal Beacon should be a new DNS name that resolves to a StoreFront Load Balancing VIP.
    • If the internal beacon is https, then the certificate must match the internal beacon DNS name. However, http URLs also work.
    • See CTX218708 How to Configure Internal Beacon for Single FQDN on StoreFront.
  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 on NetScaler for the Single FQDN.

  6. In the NetScaler Gateway Session Profiles, on the Published Applications tab, set the Web Interface Address, and the Account Services Address to the Single FQDN.


  7. That’s all you need to implement Single FQDN. If you made changes to an existing StoreFront deployment, then you might have to remove accounts from Receiver, and re-add the account.

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

DNS:

  • Sample DNS names:
    • Single FQDN = storefront.corp.com
    • Callback FQDN = callback.corp.com
    • Internal Beacon FQDN = internalbeacon.corp.com
  • External DNS:
    • storefront.corp.com resolves to a public IP, which is NAT’d to a NetScaler Gateway VIP on a DMZ NetScaler.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to StoreFront.corp.com. Create this SRV record in every email suffix DNS zone.
  • Internal DNS:
    • storefront.corp.com resolves to the Load Balancing VIP for StoreFront
    • callback.corp.com resolves to a NetScaler Gateway VIP on the same NetScaler that authenticated the user. Usually only needed for SmartAccess and/or SAML.
    • 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. Create this SRV record in every email suffix DNS zone.

Certificates:

  • External, publicly-signed certificate for NetScaler Gateway:
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com. If you more than one email suffix, then wildcard will not work.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • Callback.corp.com – for callback URL. Only accessed from internal.
        • Or you can create a separate internally-facing Gateway vServer for callback with a separate certificate.
      • If email-based discovery, discoverReceiver.email.suffix for each email suffix. If you have multiple email suffixes, you’ll need multiple SAN Names.
  • Internal certificate for StoreFront Load Balancing:
    • Publicly-signed certificate is recommended, especially for mobile devices and thin clients.
    • Since you have the same DNS name for internal and external, you can use the external certificate for internal StoreFront.
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com. If you have more than one email suffix, then wildcard will not work.
    • Another option is the following Subject Alternative Names:
      • Storefront.corp.com
      • If email-based discovery, discoverReceiver.email.suffix for every email suffix. If you have multiple email suffixes, then you will have multiple SAN names.

StoreFront Configuration:

  • Base URL = https://storefront.corp.com
  • Internal beacon = https://internalbeacon.corp.com. Make sure it’s not resolvable externally.
  • Gateway object:
    • Gateway URL = https://storefront.corp.com
    • Callback URL = https://callback.corp.com

Receiver for Web session policy:

  • Policy expression = REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver
  • Client Experience tab:
    • Clientless Access = Allow or Off
    • Plug-in Type = Java
    • 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
    • Single Sign-on Domain = Corp

Receiver Self-Service session policy:

  • Policy expression = REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver
  • Client Experience tab:
    • Clientless Access = Allow or Off
    • Plug-in Type = Java
    • 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
    • Single Sign-on Domain = Corp
    • Account Services address = https://storefront.corp.com

Multiple Datacenters / Farms

Multi-datacenter NetScaler Gateway and StoreFront Design

HTTP vs ICA

There are two connections from every Citrix client:

  • HTTP (SSL required) – goes to StoreFront
    • HTTP is usually proxied through NetScaler load balancing
    • If external, HTTP is proxied through NetScaler Gateway, which proxies it through NetScaler load balancing.
    • HTTP traffic is initiated by either a web browser, or by Receiver Self-Service
  • ICA (SSL optional) – goes to Virtual Delivery Agent
    • ICA can go direct (internal) to a VDA
    • Or ICA can be proxied through NetScaler Gateway ICA Proxy
    • ICA traffic is handled by Receiver’s ICA engine – either locally installed Receiver, or HTML5 Receiver

The FQDN for the HTTP connection can be the same or different than the FQDN for the ICA connection.

The HTTP connection is easily handled by GSLB, HTTP/SSL load balancing, etc.

  1. DNS name – Users connect to a DNS name that resolves to StoreFront and/or NetScaler Gateway.
    1. StoreFront is usually proxied through NetScaler Load Balancing.
    2. If NetScaler Gateway, the HTTP connection is proxied to StoreFront, usually through Load Balancing.
  2. Separate VIP per datacenter – For multiple datacenters, each datacenter has its own StoreFront and/or NetScaler Gateway VIP.
  3. GSLB resolves the DNS name to one of the datacenter VIPs.
    1. This can be active/active, or active/passive.
  4. Proximity and persistence – For active/active, since StoreFront traffic (HTTP) is so minimal, it usually doesn’t matter which datacenter is selected. But you can optionally enable one of the Proximity GSLB load balancing algorithms so the closest datacenter is selected.
    1. Enable one of the GSLB Service cookie-based persistence methods. Connection Proxy is the easiest to configure.

The ICA connection is dictated by StoreFront.

  1. .ica file – When a user clicks an icon in StoreFront, StoreFront generates an .ica file containing an address.
    1. If the user is internal, then the .ica file usually contains the private IP address of the Virtual Delivery Agent. Receiver connects directly to the VDA’s private IP.
    2. If the user is connecting through NetScaler Gateway, or if HDX Optimal Routing is enabled, then the .ica file usually contains the FQDN of a NetScaler Gateway that can proxy the ICA connection.
  2. Receiver engine for ICA protocol – The StoreFront provided .ica file is given to a Receiver engine. Receiver engine (locally installed Receiver, or HTML5 Receiver), uses ICA protocol to connect to the address contained inside the .ica file.
  3. One public IP – For external users, an advantage of NetScaler Gateway is that you only have to expose one public IP address per datacenter no matter how many VDAs you have.
  4. FQDN for Gateway – For NetScaler Gateway, StoreFront inserts a FQDN into the .ica file. This FQDN can be one of the following:
    1. Active/active GSLB
    2. Datacenter-specific – If you have two datacenters, each datacenter has a unique FQDN that resolves to a specific NetScaler Gateway VIP in a specific datacenter. GSLB active/passive handles failover if the datacenter-specific VIP is down.
  5. ICA Routing – ICA traffic is heavier and more latency sensitive than StoreFront. Thus you typically want to control which datacenter is used for the ICA connection. There are two common designs:
    1. Proxy ICA traffic through a NetScaler Gateway that’s in the same datacenter as the VDA.
    2. Proxy ICA traffic through the NetScaler Gateway that’s closest to the user. The idea here is that back haul WAN connections are faster than Internet connection to a remote datacenter.
  6. HDX Optimal Routing – For proxying ICA through NetScaler Gateway in the same datacenter as the VDA, StoreFront has two methods for identifying the NetScaler Gateway that’s closest to the VDA:
    1. Different XenDesktop site/farm in each datacenter. If a VDA is launched from a particular site/farm, then provide the NetScaler Gateway FQDN that is associated with that site/farm. This is configured using HDX Optimal Routing.
    2. Different XenDesktop zone per datacenter. If the VDA is launched from a particular zone, then provide the NetScaler Gateway FQDN that is associated with that zone. This is configured using HDX Optimal Routing.
  7. Proximity and Persistence – For proxying ICA through a NetScaler Gateway that is closest to the user, StoreFront returns an FQDN that is GSLB Active/Active load balanced using a Proximity load balancing algorithm.
    1. ICA is usually a long-lived TCP connection to the NetScaler Gateway VIP.
    2. You can enable Source IP persistence on the active/active GSLB Virtual Server.
    3. Another method of proximity load balancing ICA is to configure NetScaler to insert a header to StoreFront indicating the XenDesktop zone the user is connecting from. See the GSLB Powered Zone Preference whitepaper.

Internal NetScaler Gateway ICA Proxy? – Internal users typically have direct connectivity to VDA Private IP addresses, so you usually don’t need to use NetScaler Gateway ICA Proxy internally. However, an advantage of using NetScaler Gateway ICA Proxy internally is that now all ICA traffic is going through a NetScaler, which makes it easy to enable AppFlow (HDX Insight) reporting to NetScaler MAS.

  • ICA Proxy through NetScaler Gateway wraps ICA traffic in SSL, increasing the packet size.
  • SSL-Encrypted ICA packets cannot be optimized by normal WAN optimization products.

StoreFront and Multiple Sites/Farms

A XenDesktop Site/Farm is a collection of XenDesktop Controllers that share a single Site SQL Database. Multiple XenDesktop Sites/Farms implies multiple Site SQL databases, each configured separately. Note: farm is the old name for XenDesktop Site.

  • If you stretch a single XenDesktop Site/Farm across datacenters, then you have to deal with replication and recovery of the single SQL database.
  • XenDesktop Zones and Local Host Cache make it more feasible to stretch a farm. See XenDesktop Site Failover – how do you do it? at CUGC for an excellent discussion on multi-datacenter zone design.
  • VDAs can only register with one XenDesktop Site.

Multiple XenDesktop Sites/Farms – StoreFront can enumerate icons from multiple XenDesktop Sites/Farms. If there are identical icons in multiple farms, then the icons can be aggregated so that only a single icon is displayed to the user. When the user clicks the icon, StoreFront then needs to select a site/farm.

  • Sites/Farms can be prioritized (active/passive) for different Active Directory groups. This allows you to specify a “home” site for specific users. Typically you set the preferred site/farm to be in the same datacenter that contains the user’s home directory and roaming profile.
  • Or sites/farms can be active/active load balanced. This works best for applications that have synchronized active/active back-end data.

Icon aggregation – There are two methods of configuring icon aggregation in StoreFront:

  • StoreFront Console GUI – The most common multi-site/farm configurations can be done in the StoreFront Console GUI, including configuration of “Home Sites” (different AD groups prioritizing different sites/farms).
  • XML files – for more complex multi-site configurations. See Citrix Docs – Set up highly available multi-site store configurations

Note: if you have existing subscriptions/favorites, then enabling icon aggregation will cause the existing subscriptions to be ignored. You can migrate the existing subscriptions by exporting, modifying, and importing. See Subscriptions Missing after Enabling Aggregation at Citrix Discussions.

StoreFront in Multiple Datacenters

Stretching – Citrix does not support stretching a single StoreFront Server Group across multiple datacenters. Each datacenter is expected be a different StoreFront Server Group.

  • Citrix provides scaling guidance for up to 6 servers in a single StoreFront Server Group.

Management – Each StoreFront Server Group is managed separately.

  • Subscriptions/Favorites can be replicated between the two StoreFront Sever Groups.

Receiver Roaming – When Citrix Receiver switches between different StoreFront Server Groups in multiple datacenters, it’s possible for each datacenter to be treated as a separate Store, causing multiple Store entries in Receiver. This can be prevented by ensuring the following configurations are identical in both datacenters. Source = Juan Zevallos at Citrix Discussions:

  • Match the SRID – in StoreFront, if you use the same Base URL in the 2 separate installations, then the SRID should end up being identical. If the Base URL 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 Base URL
  • Match the Delivery Controller names under “Manage Delivery Controllers” – The XML brokers can be different, but the actual name of the Delivery Controller/Farms must be identical.

Typical Multi-Datacenter Configuration

Here’s a typical active/active XenApp/XenDesktop configuration using separate sites/farms in each datacenter. Another option is zones.

  • XenDesktop Sites/Farms: Separate XenApp/XenDesktop sites/farms in each datacenter.
    • The Controllers for each site/farm point to a SQL database in the local datacenter. There usually is no need to enable SQL failover across datacenters.
    • Each datacenter is managed separately. But Citrix Policies in a GPO can apply to both sites/farms.
    • An advantage of separate sites/farms is that you can upgrade one datacenter before upgrading the other.
  • StoreFront Server Groups: Separate StoreFront Server Groups in each datacenter.
    • Citrix doesn’t support stretching a single StoreFront Server Group across a WAN link.
    • Each Server Group is configured identically. You can export the config from one Server Group, and import it to the other. Or configure each of them separately, but identically. Identical means: same Base URL, same farms (Manage Delivery Controllers), same SRID, same Gateways, and same Beacons.
    • If subscriptions/favorites are enabled, use PowerShell commands to configure subscription replication between the two Server Groups.
  • StoreFront Load Balancing: Separate StoreFront load balancing VIP in each datacenter
    • Each Load Balancing VIP can be active/passive. Active = the StoreFront servers in the local datacenter. Passive = the StoreFront servers in the remote datacenter.
      • Create two Load Balancing vServers: one for local StoreFront, one for remote StoreFront. In the Active (local) Load Balancing vServer, add the Protection section, and configure the Backup (remote) vServer.
      • When the active StoreFront is down, NetScaler Gateway will use StoreFront in the remote datacenter. However, the remote datacenter has its own NetScaler Gateway, thus there will be two different NetScaler Gateways connecting to one StoreFront Server Group. If you use SmartAccess or SAML and need the Callback URL, then you’ll need a special StoreFront configuration to handle the Callback URL from multiple Gateway appliances.
  • Icon aggregation: Configure StoreFront to aggregate icons from the two farms.
    • Use AD groups to specify a user’s home datacenter, which contains the user’s roaming profile and home directory.
    • Configure farm priority based on AD groups. For an aggregated icon, the AD group and farm priority determines which farm the icon is launched from.
  • External NetScaler Gateways: Externally-accessible NetScaler Gateway ICA Proxy VIPs in both datacenters.
    • The main NetScaler Gateway DNS name is active/active GSLB. For example: citrix.company.com)
    • Each datacenter has a datacenter-specific GSLB active/passive DNS name for NetScaler Gateway. For example: citrix-a.company.com, and citrix-b.company.com
    • The Gateway SSL certificate needs to match all three DNS names: the main active/active DNS name, and the two datacenter-specific active/passive DNS names.
  • Internal NetScaler Gateways: Internally-accessible NetScaler Gateway ICA Proxy VIPs in both datacenters for AppFlow reporting.
    • For AppFlow/Insight reporting, NetScaler Gateway ICA Proxy is typically used internally too. If you don’t need AppFlow, then you don’t need internal NetScaler Gateway.
    • To handle Single Sign-on from Receiver, internal Receivers will connect HTTP directly to StoreFront Load Balancing instead of proxied through NetScaler Gateway.
      • This implies that you have separate DNS names for StoreFront and NetScaler Gateway.
    • HDX Optimal Routing will force the ICA connection to go through NetScaler Gateway instead of directly to the VDA.
    • HDX Optimal Routing is a global setting that applies to both internal and external users. The DNS name used by HDX Optimal Routing must be valid for both internal and external. If this is not the case, then you can deploy separate StoreFront servers for internal and external.
    • DNS:
      • The main NetScaler Gateway DNS name is active/active GSLB. For example: citrix.company.com.
      • Each datacenter has a datacenter-specific GSLB active/passive DNS name for NetScaler Gateway. For example: citrix-a.company.com, and citrix-b.company.com
      • The Gateway SSL certificate needs to match all three DNS names – the main active/active DNS name, and the two datacenter-specific active/passive DNS names.
  • Main StoreFront and Gateway FQDNs: separate FQDNs for StoreFront and NetScaler Gateway.
    • Externally,  citrix.company.com resolves to a NetScaler Gateway VIP.
    • Internally,  storefront.company.com resolves to a StoreFront Load balancing VIP.
    • Single FQDN usually causes more problems than it’s worth. If you don’t do Single FQDN, then you can hide the StoreFront DNS name by pushing the store configuration to Receiver using Group Policy. Browser users would only need to know the NetScaler Gateway DNS name.
  • DNS Delegation for GSLB: multiple DNS names are delegated from internal DNS and public DNS to NetScaler ADNS (internal and external) for GSLB.
    • Internal GSLB and public GSLB need to resolve citrix.company.com differently. Public GSLB should resolve it to public IPs. Internal GSLB should resolve it to internal IPs.
    • Combining internal and public GSLB on the same NetScaler is not recommended. Public GSLB should be handled by DMZ NetScaler appliances. Internal GSLB should be handled by Internal NetScaler appliances.
    • If you only have one NetScaler appliance for both internal and public, then see One appliance resolving a single DNS name differently for internal and public at GSLB Planning.
    • citrix.company.com is configured as Active/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
    • citrix-a.company.com is configured as Active/Passive GSLB with Datacenter A as the Active service.
    • citrix-b.company.com is configured as Active/Passive GSLB with Datacenter B as the Active service.
    • storefront.company.com is configured as Active/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
  • HDX Optimal Routing: Use HDX Optimal Routing to route ICA traffic through the NetScaler Gateway that is closest to the destination farm. This requires datacenter-specific DNS names (e.g. citrix-a.company.com, citrix-b.company.com)
    • You can use one of these DNS names to connect to StoreFront in a specific datacenter, which is helpful for testing.
  • STAs: each StoreFront Server Group uses STAs in the local datacenter. Since ICA Traffic could end up on either NetScaler, all STAs must be added to all NetScaler Gateways.
  • Beacons: the internal beacon is critical. If the internal beacon is down then Receiver Self-service won’t be able to determine if the client device is internal or not. GSLB can be used for the internal beacon DNS name.
  • Roaming Profiles: If you are running XenApp / XenDesktop in multiple datacenters, you must design roaming profiles and home directories correctly.

Icon Aggregation and Home Sites

To configure icon aggregation using the StoreFront Console:

  1. In StoreFront Console, go to Stores.
  2. In the middle, right-click your Store, and click Manage Delivery Controllers.
  3. Add multiple sites/farms. Typically, each datacenter is a separate farm.
  4. After adding multiple farms, the Configure button becomes available. Click it.
  5. If you are publishing identical resources from multiple farms, click the link to Aggregate resources.
  6. In the Aggregate Resources dialog box, do the following:
    1. Select the farms with identical resources that you want to aggregate.
    2. Notice the checkboxes on the bottom. If your goal is to configure home sites, then make sure you uncheck Load balance resources across controllers.
    3. Click the Aggregate button to move them up to the Aggregated section.
    4. Note: if you have existing subscriptions/favorites, then enabling icon aggregation will cause the existing subscriptions to be ignored. You can migrate the existing subscriptions/favorites by exporting, modifying, and importing. See Subscriptions Missing after Enabling Aggregation at Citrix Discussions.
    5. Click OK when done.
  7. Back in the Configure User Mapping and Multi-Site Aggregation window, click Map users to controllers.
  8. In the Create User Mapping wizard, do the following:
    1. If you want the same farm failover order (active/passive) or farm load balancing settings for everyone, then leave the User Groups page set to Everyone. Or if you intend to have different home sites for different users, add a user group that contains the users that will be homed to a particular datacenter. You can run this wizard multiple times to specify different home sites for different user groups. Click Next.
    2. In the Controllers page, click Add.
    3. Select the farms that these users will have access to, and click OK.
    4. If you configured farm aggregation without load balancing, then use the up and down arrow buttons to put the active site/farm for this group of users on top. The lower priority sites will only be accessed if the primary site is down. You can run this wizard multiple times to specify different active sites for different users.
    5. If farm aggregation is configured for load balancing, then there are no arrows to prioritize the farms.
    6. Click Create.
  9. You can click Add to add more user mappings. If you add multiple user groups, you can assign different primary sites/farms to each Active Directory group. This is how you configure “home sites”. Click OK twice when done.

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.

HDX Optimal Routing

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

  • 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.
    • If the main DNS name for accessing NetScaler Gateway is GSLB load balanced across datacenters, then you need additional datacenter-specific DNS names so you can control which datacenter the ICA connection goes through.
    • Note: Optimal Gateway is configured at the farm/site level, or zone level.
  • NetScaler Gateway for internal connections (AppFlow). If you want to force internal ICA connections to go through NetScaler Gateway so AppFlow data can be sent to NetScaler MAS, then you can do that using HDX Optimal Gateway, even if the user originally connected directly to the StoreFront server. See CTX200129 How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront for more information.
  • The NetScaler Gateway Virtual Server requires user certificates. If ICA traffic goes through a NetScaler Gateway Virtual Server that requires user certificates (e.g. Smart Card), then each session launch will result in a PIN prompt. To prevent these extra prompts, build a separate NetScaler Gateway Virtual Server that doesn’t have user certificates as Mandatory. Use Optimal Gateway to force ICA connections through the other NetScaler Gateway Virtual Server. Note: SmartAccess Callback URL also cannot use a NetScaler Gateway Virtual Server where client certificates are set to Mandatory, so the extra NetScaler Gateway Virtual Server would be useful for that scenario too.

HDX Optimal Gateway can be configured in the StoreFront Console:

  1. Right-click the Stores node, and click Manage NetScaler Gateways.
  2. Add more NetScaler Gateways: one for each datacenter.
  3. When adding a Gateway, you can designate a Usage or role.
    1. The Gateway accessed through the active/active GSLB DNS name must be set to Authentication and HDX routing.
    2. The Gateways for Optimal Routing could be set to HDX routing only. Or if test users will use these datacenter-specific DNS names to connect to Gateways in specific datacenters, leave them set to Authentication and HDX routing. There’s no harm in leaving all of the Gateways set to Authentication and HDX routing.
  4. Go to Stores, right-click your store in the middle pane, and click Configure Store Settings.
  5. Go to the Optimal HDX Routing page.
  6. Highlight one of the datacenter-specific Gateways, and click Manage Delivery Controllers.
  7. Select the farms that should use this gateway, and click OK.
  8. Repeat for the other datacenter-specific Gateways.
  9. The Gateway for the active/active GSLB-enabled DNS name doesn’t need any farms associated with it.
  10. If you want to use NetScaler Gateway internally for AppFlow reporting, then uncheck the External only checkbox.

    1. Another option for Optimal Gateway selection is zones. In XenApp/XenDesktop 7.7 and newer, you can stretch a farm across datacenters (zones), and use a different Gateway for each zone. Highlight a Gateway. Click Manage Zones, and add the zone name. This assumes the zone name has also been specified in the Manage Delivery Controllers dialog box > Advanced Settings.
  11. Click OK when done.
  12. In summary, users will connect to the active/active GSLB-enabled Gateway and login. After clicking an icon, HDX will be routed through one of the datacenter-specific Gateways based on the farm the icon was launched from.

Multiple Gateways (GSLB) to One StoreFront Server Group

This section applies to SmartAccess, or SAML, and the Callback URL. If you don’t need the Callback URL for SmartAccess or SAML, then skip this section.

The Callback URL must go to the same NetScaler appliance that authenticated the user. If you have multiple NetScaler appliance pairs communicating with a single StoreFront server, then StoreFront needs to identify which NetScaler appliance pair the request came from, so it can perform a callback to that particular appliance pair.

If each of the NetScaler Gateways uses the same DNS name (GSLB), then you can’t use the DNS name to distinguish one appliance from the other. Instead, StoreFront can use the Gateway VIP to distinguish appliances so the callback goes to the correct appliance.

  1. Create datacenter-specific callback DNS names. For example: callback-a.corp.com and callback-b.corp.com.
  2. The datacenter-specific callback DNS name must match the certificate on the NetScaler Gateway Virtual Server that is handling the callback. 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 callback 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 callback name.
    • Create an additional NetScaler Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific callback name.
  3. In the StoreFront console, create multiple NetScaler Gateway appliances, one for each datacenter.
  4. Give each of the gateway objects unique Display names. You can’t have two Gateway objects with the same display name.
  5. Enter the same NetScaler Gateway URL in all of the gateway appliances.

  6. In the Authentication Settings page, in the VServer IP address field, enter the Gateway VIP for this particular appliance pair. StoreFront will use this VIP to distinguish one NetScaler appliance from another.
    • When users use HTTP to connect to a NetScaler Gateway for authentication and icon enumeration, when NetScaler Gateway communicates with StoreFront, NetScaler Gateway inserts its VIP into a HTTP Header field named X-Citrix-Via-VIP. StoreFront reads this VIP header, and compares it to the Gateway objects bound to the Store. If there’s a match, StoreFront uses the Callback URL configured for that Gateway object.
  7. The callback URL must be unique for each NetScaler appliance pair (e.g. callback-a.corp.com). The callback URL must resolve to a NetScaler Gateway VIP on the same appliance pair that authenticated the user.

  8. When enabling Remote Access on the store, select both Gateway appliances. Select one as the default appliance. It shouldn’t matter which one is default.

Related Pages

95 thoughts on “StoreFront 3.5 through 3.12 – Configuration for NetScaler Gateway”

  1. Hi Carl

    I am planning to update the storefront version 3.9 to 3.12 my supporting environment. What are precaution need to take.
    My environment having 4 servers .While updating the storefront version during that time will sf page will be available for the user?
    your reply much awaited

    Thanks
    S.Hegde

  2. HI Carl,
    This should be simple. Hopefully ..
    We have a small deployment group for Gateway VPN access through our Netscaler 11.1. So we’re not worried about simple end user first time setup.
    For a test user I have the GW working by binding a session policy to a AAA group. LDAP is all setup and working.
    Membership in the selected group makes the connection just fine. Simple full VPN for connection to (non-ica) internal resources.
    Here’s the wrinkle. On occasion (like when the users has left their corporate laptop home, or it’s died on a trip) that user would like to connect through to a Xendesktop session. Now they could call our help desk and we just remove them from the AD (AAA) group and they’re in. I suspect in all the possible configurations it would be possible to either test that they’re using a computer that does not have the Gateway client. Or some way to fail the AAA group bound policy (like a test for the GW client) and connect through the main Storefront policy bound to the virtual server. Or stack a higher priority policy on the AAA group’s session policies.

    1. You can create a Session Policy with an expression that looks for normal non-windows User-Agents (e.g. iOS, Mac, Android), etc.

  3. Hello Carl,

    In the Multiple Data Centres / Farms section you have the following statement:

    ‘NetScaler Gateways: For AppFlow reporting, NetScaler Gateway ICA Proxy is typically used both externally and internally. Externally it is required. Internally it is used to generate AppFlow data.’

    But then a little later you mention this:

    ‘Internally, citrix.company.com resolves to a StoreFront Load balancing VIP. This allows pass-through authentication. If the internal DNS name resolved to a NetScaler Gateway VIP then pass-through authentication would not work.’

    This is confusing me a little – did you mean that internal users should go straight to the SF VIP? Or should it be to a NSG? I guess you could do either but I wanted your view on which you think best.

    Regards

    1. If you need SSON (pass-through auth), then HTTP traffic must go directly to StoreFront, and not through Gateway. But you can use HDX Optimal Routing to send ICA traffic through NetScaler Gateway, even internally. Remember, there’s always two connections from every Citrix client: HTTP and ICA.

      1. Thanks Carl.

        I would typically have an NSG in the DMZ for remote users and a NS internally for load-balancing. Would you route the internal users to the NSG in the DMZ or would you add gateway functionality to the internal NS?

        Regards

        1. Add Gateway with internal VIP. This is optional. But it allows you get easily get AppFlow for internal users. There are other options like PBR, routing, SOCKS proxy, but Gateway is the easiest to implement.

  4. Carl,

    Good morning. I have an architecture question for you. I’ve setup a datacenter in WestDC(WestCoast DC) with a Netscaler that is only used internally. Its for both Loadbalancing and a “VPN Gateway” for ICA proxy.

    The SQL for this farm is in an “ALWAYS ON” cluster between SQL servers in the EastDC(EastCoast DC).

    We’re beginning the build out of the EastDC Citrix environment that’s to be used for Disaster Recovery of the WestDC environment and we’ll be running applications out of it part of the year every year while we update the passive datacenter. So an active/passive EastDC/WestDC if you will.

    The plan is Netscalers in each DC that share a DNS FQDN (CNAME) that will change on “rotation” to point to the active DataCenter (Netscaler VIP). Each DataCenter has two storefront servers and the base url points to a DNS FQDN (CNAME) that would also change on “rotation” to point to the active DataCenter (Netscaler VIP). The thought is to have the Storefront servers in each DC only use the Delivery Controllers from their DC. The Netscalers would also only use the STAs (on the Delivery controllers) from their local DC.
    So we have Netscaler Loadbalancing Virtual Servers and VPN Virtual Servers running on separate VIPs at each DC that we’ll use for our failover.

    There is only one Citrix Farm/Site currently. And the plan was to keep it that way.

    So you have a recommendation for the Storefronts:
    1. Should it have a UNIQUE base url like STORENAME_EASTDC and STORENAME_WESTDC or should it be shared.
    2. Should the store fronts be in the same Server Group or should we use different server groups for each DataCenter?

    Suggestions? Your documentation has been a bible for us over the past 6 months. Do you do any consulting at all for configuration reviews and such?

    Respectfully…

    John

    1. If you are using native Receiver, then I would have same Base URL, same store name, and same SRID, in both datacenters. This allows Receiver to switch between them. Otherwise, you’d have to inform users to start using a different Store.

      Citrix does not support stretching a StoreFront Server Group across large distances (metro clusters are fine).

      I definitely do Citrix consulting through my employer Sirius Computer Solutions.

      1. Thanks Carl for the quick reply!

        Is it ok to use the same Gateway URL and just redirect on failover or should we setup different zones and use different gateway URLs and optimal routing.

        Thanks again

        John

        1. If you need to login to a specific datacenter, then you’d want separate names. Especially if active/active. But if you don’t need to access the passive site at any time, then you can leave it with only one DNS name.

  5. hi Carl,

    Currently, I have one store, users come in externally thru Netscaler citrixapps.corp.com. Internally, they go to storefront directly via Receiver SSO citrix.domain.com

    citrix.domain.com is my base URL for storefront.

    We have a requirement to add netscaler internally to be able to do 2 factor auth.

    Should I create the internal netscaler VIP the same as my base URL citrix.domain.com so that users don’t have to update the receiver settings?

    Since its on the same domain netscaler and storefront, do I use the same IP and DNS name (citrix.domain.com) for the set up on storefront and netscaler? would that work?

    1. It will probably work. This is known as Single FQDN since you’re using the same FQDN for StoreFront and NetScaler Gateway. The DNS name needs to resolve to the Gateway. The StoreFront servers need Loopback enabled and set to OnUsingHttp. The Internal Beacon address must be something different than the Single FQDN. Add the Single FQDN into StoreFront as another Gateway object and bind it to the store. Note: your Store will have two Gateways – one for citrix.domain.com, and another for citrixapps.corp.com. But only one of them can be the default (probably citrix.doman.com). Since you’re adding a Gateway, which modifies the provisioning file, you’ll probably need to remove accounts from Receiver and re-add.

      1. thank you carl

        Right now if I add to my receiver the external address, citrixapps.corp.com, it will connect thru netscaler at first when when I check the account settings it has the internal base URL on the receiver settings – citrix.doman.com/citrix/store/discovery….

        is this because of the internal beacon pointing to the base URL?

        Is there a way to turn off access to the storefront directly, forcing users to come thru netscaler?

          1. Good information.

            Alternatively to accomplish what I want to do by having my internal users all go thru the netscaler and be prompted for 2 factor everytime they launch the receiver , without having to update the receiver settings.

            I was thinking about changing the base URL to something else:

            base URL: base.domain,com
            external netscaler: citrixapps.corp.com
            internal netscaler: citrix.domain.com (which is what their current receiver is pointing to so I don’t have to change this)

            although, after reading the article its says that the: “Gateway will connect to its configured Account Services address, and download the Provisioning File from StoreFront” and “The actual connection process is controlled by the contents of the Provisioning File, not the Discovery address.”

            does this mean that it will send users to base.domain.com and after the initial pull they will not longer be prompted to enter 2 factor auth? essentially going to the storefront directly base.domain.com

          2. Yep. If the Internal Beacon is reachable, then Receiver will connect directly to the Base URL. When you entered for Discovery has no effect on how Receiver actually connects.

  6. BIG Thanks Carl for your work! Im studying citrix and have a one question:
    “How can I set up authentication with a token and a domain account ? That is, external users (third party users) must log in through the token (the usb key with the certificate issued in my organization), and the users from my organization under the domain account. Which way to look to set it up?”
    I have one netscaler, one storefront and one store
    Thanks for any help!

    1. Internal users authenticate directly with StoreFront, which is domain only.

      External users authentication with NetScaler Gateway, which has both configured.

      If you want organization PCs to skip two-factor when external, then one option is nFactor for Gateway.

      1. I probably didn’t write correctly. I mean, internal users are users from my organization who work remotly
        over internet (not used any vpn). They have domain account and want connect citrix use domain auth . External users are users not from my organization and we give them tokens. Can they both (internal and external users) connect to store though Netscaller ?

          1. In fact, in any case, a domain account will be used independently by an internal or external employee. There are differentiation at the policy level. One user can access by token, another by login / password. And if possible, divide it in authorization groups.

          2. How do you distinguish one vs the other? What does “policy level” mean? Are you saying that internal users are in one OU but external users are in a different OU?

  7. Carl,

    I have a client that is wanting external traffic to route through a netscaler in the DMZ and internal traffic to route through a different netscaler in the secure network. Just when I thought I had something working, I ran in to another issue. Currently, I reach storefront from both netscalers, but receiver continously says Connection in progress on the internal Netscaler. External authenticates and delivers applications without issue. Any help would be greatly appreciated.

    1. Same DNS name for internal and external?

      Has it ever worked internally?

      Is ICA Only checked on the internal Gateway?

      1. Same DNS name for both internal and external.

        Internal worked prior to getting external to work. If I move the DDCs to each gateway in HDX Routing, I can get either one to work at any given time but never both at the same time.

        ICA only is checked on both right now.

          1. I have two because I was under the impression that in order to get both external and internal to work with SSO, I needed to have a callback for both going to each netscalers NG VIP. Correct me if I am wrong.

          2. Callback is not needed for SSO. Callback is needed for SmartAccess and FAS, but not SSO. If you don’t need Callback, then remove it, remove the second gateway object, and see if that works.

          3. Also, I figured I would mention, when I get it to work internally, what I am seeing externally is this.

            10.200.83.165:14443 10.10.9.129:1494 SYN_SENT

            It is treating external connections as though they are in internal connection. What would cause this to not perform the SSL offload.

  8. Carl is possible to deploy a provisional file .CR with SCCM because I need configure 100 accounts with receiver and one store configure with second factor on NS.

    1. It looks like you can run “C:\Program Files (x86)\Citrix\ICA Client\Receiver\SRProxy.exe” “PathToCRFile”. However, I’m not sure if this can be run silently.

      A better option is to use group policy to delivery the Store address to Receiver.

  9. Good article, nice details. It got me about 98% success. The one thing that I had to do that wasn’t mentioned is that the Certificate used on both the Netscalers and Storefront servers has to have the Callback URL listed as a SAN on it. Without the URL on the Certs I continued to get “Cannot complete your request” errors

    1. The certificate on the Callback URL destination has to be valid: name matches, not expired, trusted. Name matches could include subject alternative names. Or you can have a different Gateway VIP with a different regular certificate.

  10. Hi Carl, I had some questions regarding designing a global Citrix XenDesktop/XenApp with a single FQDN URL to be used across 3 regions (North America, Europe, & Asia Pacific) that are 3 POD sites (some with zones). The details:

    NA is POD site 1 and is the primary zone. This is where the SQL database exists. It also has a secondary satellite zone. Each zone will have their own controllers, storefronts, & VDAs.

    EU is POD site 2 and is the primary zone. This is where the SQL database exists. It also has a secondary satellite zone. Again each zone will have their own controllers, storefronts, & VDAs.

    AP is POD site 3 and is the primary zone by default and no other zones will exist. So here the SQL database exists, controllers, storefronts, VDAs, etc.

    Each zones across the regions have NetScaler presence (whether virtual or physical).

    My questions are:

    What would be the best way to have all these zones\sites use 1 single FQDN URL?

    For internal users they should be able to connect to their local SF VIP?

    For external user, not so sure, but am thinking maybe to implement a NS gateway at the primary zones only?

    But then how would it distinguish the public IP for the single URL all the way back to the translated NS gateway IP?

    Are there any things I can do with Unified GW back at POD 1 which is the headquarters?

    Any help would be appreciated.

    1. It depends on what you want to do. One option is GSLB for both public and internal names, with dynamic or static proximity. Once a datacenter is chosen, use HDX Optimal Gateway to send the ICA traffic through a Gateway in the same datacenter as the VDA, or a Gateway that’s closest to the user, depending on which has better connectivity. You would need datacenter-specific DNS names for Optimal Gateway. For closest Gateway, regular GSLB proximity should work.

      But this design could require quite a bit of discussion, so it’s best if you work with a Citrix Partner or Citrix Consulting.

  11. Carl, I’m trying to set up a single FQDN, but I’m having some trouble. I have a small customer who has only one StoreFront box. For the internal DNS entry, is that supposed to be pointed at the NetScaler Gateway VIP? Or, is that supposed to be pointed directly to StoreFront? I have it pointed to the VIP currently, but the firewall is showing resets when trying to connect. Any help would be greatly appreciated.

    1. For Single FQDN, the internal name resolves to the StoreFront servers (load balancing VIP). External resolves to the public Gateway VIP. If you need Callback URL, then you need a separate DNS name. And the Internal Beacon cannot be the Single FQDN.

  12. Hi Carl,
    Could you explain more about you sentence “Citrix doesn’t support stretching a single StoreFront Server Group across a WAN link” What about in the case that we are using a high speed WAN link ?
    Thanks in advance

    1. Like a Metro Cluster? That’s probably OK.

      Otherwise you can call support to get their official support statement on your configuration.

  13. Dear Carl
    Could you exlain more your above sentence “doesnt support a single storefront group across a wan link” What in the case that we are using a high speed wan link?

  14. Hi Carl,

    I have configured with different port no 8445 VIP -10.0.0.5 in load balancing for two storefront servers(port 443) and configured browser policy http://10.0.0.5:8445/citrix/storeweb for netscaler access gateway.

    When i am login with username and password for external access gateway URL. I am getting error page HTTP service is unavailable.

    Is it work with different port 8445 load balancing VIP(10.0.0.5) in browser policy.

  15. HI Carl,

    Can you please help me with a problem i’m having with my Storefront 3.6 Server firstly here’s my setup.

    Main Site – 2xDCs (load Balanced), 2xSFs (load Balanced), Multiple VDAs being used as Server OS all connecting via Netscaler. on this Site everything is working fine without any problems.

    Now I’m setting up a second site which is Geographically dispersed (in another State) – I created a second Zone .

    Sattelite Site – 1xDC, 1xSF, Mulitple VDAs also being used as Server OS all connecting via a Netscaler (they have their own internet connection).

    Now the problem i’m having is that I can logon fine to the Storefront Website address however I don’t get any Apps or Desktops and I noticed this error message
    in the logs.

    “An error occurred while attempting to connect to the server xxx.xxx.local on port 80. Verify that the Citrix XML Service is running and is using the correct port.
    If the XML Service is configured to share ports with Microsoft Internet Information Services (IIS), verify that IIS is running. This message was reported from the XML Service at address
    http://xxx.xxx.local/scripts/wpnbr.dll. The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.”

    When I run a BrokerSerivce this is what I get.
    C:\Program Files\Citrix\Broker\Service>BrokerService.exe /show
    SDK Port: 80
    VDA Port: 80
    StoreFront Port: 80
    StoreFront TLS Port: 443
    Log File:

    I’ve checked the Delivery Group and there is a Desktop Published which I have access to I’ve even add my name in directly from AD.

    Any thoughts on what I’ve done wrong here.

    Thanks
    Dex

    1. Any firewalls between StoreFront and Controller? Can you telnet from StoreFront to Controller?

      Any traffic inspection (e.g. IPS)?

      Any security software on the Controller that might be interfering?

  16. Dear Carl,

    our Storefront works now very well in combination with our double hop Netscaler and without CVPN.
    But have you got an idea to implement Storefront specially with CVPN (Clientless VPN) on an Unified Gateway configuration?
    I’m struggling around with the I-Frame error, Storefront is not accessible within the CVPN portal.

    Best Regards,

    Carsten

      1. Thanks Carl, yeah, that works, but the 11.1.48.10 is quite buggy, I had many logout in the Admin GUI while configuring the portal theme. It seems, that I have to wait for the next release, and hope, that the “Known Bugs” would not grow again and again 🙂

  17. Dear Carl,
    I’m struggling a little bit with the authentication on my Citrix Receiver.
    We have 2-factor auth on the external Netscaler (UG, NS 11.0.66), 1st LDAP, 2nd Radius. The browser based authentication works fine, but the Citrix Receiver would like to have the input vice versa, that means password 1 is Radius, and password 2 is LDAP. Is there a requirement, that Radius needs to be the first option?

    Until NS 10.5, we had Radius as the 1st, and LDAP as the 2nd option, but we have changed the HTML code, so that the webpage shows LDAP as the first, and Radius as the 2nd option. This is due to the better user expierience, because Radius is a one time code and it is easier to enter first the LDAP password, and then the one time code (due to the lifetime of the code). With NS 11 we love to use the portal theme, but we had to changed the auth order. As I wrote before, web-based authentication works fine, but the receiver would like to use Radius 1st….

    This all came up, because we would like to move the productive system from Webinterface and 10.5 to Unified Gateway with Storefront. Within my tests I came to this point, where password1/2 gives us a little show stopper.

    Did it mean by the end of the day, that I need a different UG, where only Receiver traffic will arrive, and I can use Radius as the 1st, and LDAP as the 2nd option?

    Best Regards,

    Carsten

  18. Hi Carl,

    Great post thank you. I have built a PoC on Azure and looking for options to make the 2 regions highly available (Active/Active). Have you had any experience with deploying NetScalers between 2 Azure regions load balancing StoreFront servers at each location? I am stuck between using NetScaler vs. Azure Load Balancer vs. Application Gateway vs. Traffic Manager. Each has its own features and disadvantages and I was hoping you could share your past experiences.
    There’s not much out there !

    1. If you only care about StoreFront and aren’t worried about ICA traffic, then any load balancer will probably work. However, if there’s any NAT, then only NetScaler Gateway can handle the ICA traffic.

  19. Hi Carl,

    We’re having a difficult time getting Receiver for Android 3.9.x to work through Netscaler 11.1/Storefront 3.6 with XenApps 7.9 on the backend. The environment works fine for Receiver for Windows and within Android receiver, when you first add the site, the “Type” is set to “Storefront Web UI” and works fine, but I want it to work through the “Access Gateway” type instead. I keep getting “An error has occurred while connecting. Check your server address and data connection.”

    I’ve been working with citrix support for just over a week now without resolve. I originally built the test site using the wizard on the NS, but as one of the troubleshooting options, I was asked to rebuild the site on NS manually instead. So I did and the error persists.

    At one point, I had a CNAME Storefront.company.com redirecting to apps.company.com which support thought that might be an issue, so that is also removed. Error persisted.

    I should note that in iPhone or iPad, it works fine, as well as on Macs/Windows workstations. Just Android that’s driving me nuts! I gave Citrix support a test account for them to try on their Android device, they would get the same error.

    Android test: Samsung Note 5 running current os from Verizon.

    I’ve searched and reviewed all I could find on this issue to no avail. Any additional thoughts or experience you could share with me to help resolve this would be forever greatly appreciated.

    Regards,
    Richard M.

  20. I kept getting “http/1.1 Service unavailable” no matter how I configured the policies and the Unified Gateway.

    The Unified Gateway wizard (which I didn’t use for this customer implementation for configuration, I just copied the relevant parts manually) uses the expression “is_vpn_url” for the non-addressed NS GW in the content Switching policies. Apparently this had something to do with my problem, since when I changed the expression to “http.req.hostname.eq(“{myportalfqdn}”)”, it started working.

    Could I go wrong here with something else?

    I’m running NS 11.0 build 66.11.

    I also noticed I could leave the ICA Proxy ON and still use RDP Proxy on the same GW, with same session policy.

    I also have some challenges with publishing reverse proxy stuff via UGW (https://discussions.citrix.com/topic/367904-aaa-form-based-error-43550/?p=1935127), but this doesn’t fit under the StoreFront topic.

    1. If you’re trying to access StoreFront, then change the CSW expression to: is_vpn_url || HTTP.REQ.URL.STARTSWITH("/Citrix")

  21. Carl, you state that ” Receiver for iOS will append /Citrix/Store/discovery to the Internal Beacon ” what about coming in through Netscaler Gateway 11 to Storefront 3.5? I am getting this:

    The address given did not provide a valid App list.

    Thanks.

    1. If you look in the Receiver logs, does it detect your connection as OUTSIDE? If so, does your Gateway FQDN resolve to the Gateway VIP? Otherwise, make sure the session policies are configured correctly (Java instead of Windows/Mac OS X).

  22. Carl,

    I have not been able to get an answer from Citrix on this so I thought I would ask you.

    We have a pair of Netscalers on our DMZ that communicate back to our internal Storefront servers (2 running SF 3.5)

    Sometimes when users authenticate via the NetScaler and then get sent over to StoreFront to enumerate the applications the users will see an error of:

    ‘cannot start session. wait a few minutes and try to logon again. if you still experience problems, contact your help desk.’

    Then when they click ‘logoff’ they sometimes get:

    ‘Logoff error : If any apps are still running, please exit them manually. Please close your browser to log off.’

    I have verified the XML request are trusted, and on the netscaler Persistance is set on the service group for SSLSESSION.

    Have any idea of what it could be?

    1. When you say “NetScalers on DMZ”, do you mean NetScaler Gateway vServer?

      Are the DMZ NetScalers directly load balancing StoreFront? There’s no intermediary load balancing device?

      Best option for persistence is Cookie Insert, assuming no Androids. Otherwise, Source IP.

      What errors are you seeing in Event Viewer on StoreFront?

      Are you able to reproduce? If so, can you get a network trace?

      Are the browsers using any proxy server?

  23. Carl, do you know if it’s possible to have 2 NetScaler Gateway using the same Storefront?
    Scenario: 1 appliance, with 1 VS on port 8080 and another on 8443 (network restrictions). Added both of them to the Storefront 3.6. They are both showing on the “Configure Remote Access Settings”. If I launch an application, the ICA comes with the SSLProxyHost of the Netscaler on the top of the list (8080 in my case), even if the other is chosen as Default Appliance. It only works on 8443 if I deselect the NG on 8080 on that GUI.

    1. Are you using browser? If so, the default Gateway is chosesn.

      Are you using Recevier? If so, there’s a place to change the Gateway being used.

      Do you have HDX Optimal Gateway configured?

      In cases like this, I sometimes build separate StoreFront servers.

      Or maybe you found a bug.

      1. Using a browser, didn’t try the Receiver.
        HDX Optimal Gateway was not configured. I found out that configuring it allows me to set which is the SSLProxyHost indeed. Seems that the “Default Appliance” option is not being respected on 3.5 or 3.6 (I just upgraded to test, and still the same). Sounds like a bug to me…
        I guess I will create a second Store for that. Same servers just a different Store. Should do the trick…

  24. Hi Carl, I have a specific requirements and actual possibilities with SF and NS 11 makes me crazy.

    The status:
    – SF 3.6
    – XD 7.9
    – NS 11

    Target:
    – SAML external auth as PRIMARY auth on vserver – the logon to external saml is with different
    – after passed SAML auth NS will forward user to SF without SSO
    – user will use AD LDAP auth to SF directly

    Issue:
    – within NS session policy disabled SSO
    – configured web.config file for STORE settings within SF to resourcesGateways requireTokenConsistency=”false”
    – when disabled SSO from Netscaler within Manage Authentication Methods it will remove NS GW from Store settings

    After this when I will try to authetnicate into SF there is looping error A request was sent to service that was detected as passing through a gateway. However no gateways are configured for this service…

    Do you have any advise?

    Thanks,
    marek

  25. When using a single FQDN for both NetScaller 11 and StoreFront 3.6, I have notice that the Citrix Receiver must be fully exited after swiching from internal to external access (and vise versa). A log off and on does not work. Is this the normal behaviour or a misconfiguration somewhere?

  26. in step 9 of your optimal gateway config. The additional gateways you create have unique URL ex gatwayhq.corp.com and gatewaydr.corp.com are those supposed to resolve to anything specific?

    Yes, resolve to the Gateway VIP in the respective datacenter. The main Gateway FQDN is active/active so there’s no control over datacenter selection. GatewayHQ should resolve to the Gateway VIP in HQ. If HQ is down, then GSLB should failover the DNS name to the Gateway VIP in the other datacenter. The same applies to GatewayDR, except in reverse order.

    Carl I’m replying here to get some clarification.

    so if the gateway urls resolve to the VIPs at each datacenter what should the base URL resolve to?

    1. The Base URL is usually a GSLB-enabled DNS name. One DNS name that is load balanced across datacenters.

  27. in step 9 of your optimal gateway config. The additional gateways you create have unique URL ex gatwayhq.corp.com and gatewaydr.corp.com

    are those supposed to resolve to anything specific?

    1. Yes, resolve to the Gateway VIP in the respective datacenter. The main Gateway FQDN is active/active so there’s no control over datacenter selection. GatewayHQ should resolve to the Gateway VIP in HQ. If HQ is down, then GSLB should failover the DNS name to the Gateway VIP in the other datacenter. The same applies to GatewayDR, except in reverse order.

    1. The Gateway FQDNs? Receiver needs to resolve the FQDN to the Gateway that ICA traffic will flow through. And the Gateway certificate needs to match the DNS name.

  28. There’s two bugs with Storefront 3.5 that I’ve found.

    1. Possible management console failure when configuring Optimal HDX routing

    While using the StoreFront management console to configure Optimal HDX routing using a gateway that has been configured for HDX routing only, the management console might fail. [#624077]

    Work around:

    Configure a NetScaler Gateway with the Authentication and HDX routing usage type and provide default values for the authentication settings.
    Configure Optimal HDX routing using this new gateway.

    2. The netscaler storefront monitor fails on certain builds of netscaler (I’m currently using 10.5 56.22nc) I’ve seen some people workaround by using an https monitor or by upgrading to the latest netscaler build.

    I also have a question for you Carl.

    When setting up the gateways for HDX routing should we define the respected STA’s for that site? Also what should the URL’s for these resolve to if anything at all?

    Thank you for your time and effort with all this documentation and helping us with!

    1. 1. should be fixed in the next release.

      The only requirement for STA is that both StoreFront and NetScaler Gateway need to use the same STAs. There’s no relationship between STAs and farms.

  29. Hi Carl I configured SF 3.5 load balancing using the XD wizard in the Netscaler but am having trouble getting it to come up. The vserver is down and the service groups are effective state down. Both service group members probes are failing. I am using SSL / 443 and do having IIS binding to SSL cert. Wondering what could be the issue?

    1. If you go to Traffic Mgmt > LB > Monitors, is there a StoreFront monitor? If so, edit it and on the Special Parameters tab, uncheck the boxes.

        1. Quick update, in 3.5 ctirix documentation I removed the default service monitor and replaced it with one that uses HTTPs and port 443 (see powershell below), propagated SF, then in NS for the StoreFront monitor on the Special Parameters tab, I checked both boxes for “Storefront account service” and “Check backend services” and now the Service Group is effective state is partial-up. The SF server still down is one that is giving me a “cannot complete your request” message. So I am thinking once I figure that out I should be good. Your thoughts?

          # Import StoreFront API Modules
          & “$Env:PROGRAMFILES\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1”
          $ServiceURL = “https://localhost:443/StorefrontMonitor”

          Remove-DSServiceMonitorFeature

          Install-DSServiceMonitorFeature -ServiceUrl $ServiceURL

          1. I wouldn’t be surprised if there’s a bug in 3.5. Usually unchecking the boxes fixes it.

            Is your Base URL = https? If so, did you enable loopback OnUsingHttp on your StoreFront servers?

            Make sure there’s no host header configured in your IIS bindings.

          2. Hi Carl, one of the SF servers was cloned so it corrupted IIS, therefore is why I was receiving the “cannot complete your request” message. After recreating the SF servers and then following same process of removing the default service monitor and replacing it with one that uses HTTPs and port 443 via powershell is again how I was able to get the Service Group in Netscaler working. The Base URL is https, OnUsingHttp is enabled on the SF servers, and there is no header configured in the IIS bindings.

  30. Hi Carl, your documentation has been extremely useful in our configuration. Thanks so much.

    I am running into one issue however trying to do Single FQDN. Whenever I set it up we get a ../cgi/setclient?wica endless loading page after authenticating to the NS. I’ve triple checked all the necessary parameters and am at a loss. We are using a NS 11.0 65.31.nc and XenApp 7.8 with just a single Storefront server (no Netscaler in front of it internally) and a wildcard certificate. Appreciate any insight you can provide, thanks!

    1. Have you tried setting the session policy to the StoreFront IP address instead of the FQDN?

      You can do a network trace on the NetScaler to see what’s happening. There’s a handy decrypt option during tracing.

      1. Strange – that worked briefly, but after I got one successful test done it just stopped working and hangs on wica again. I had previously verified the Netscaler could resolve the FQDN to the Storefront IP — is there another reason to put the IP in instead of the FQDN?

        Not sure about the specifics of what is going on but I see the following sequence repeated over and over in the packet trace:
        NS > SF – SYN
        SF > NS – SYN, ACK
        NS > SF – FIN, ACK
        SF > NS – RST, ACK

        Will keep digging, thank you.

  31. Hey Carl,

    Great post!!!

    Can you have a third-party IDP using SAML with the Netscaler, StoreFront, and XenDesktop 7.6->7.8? Since StoreFront doesn’t support SAML natively with XenDesktop, is there a way around this with Netscaler and a third-party IDP?

      1. In which case should be used “Authentication only” role in Add Netscaler Gateway Wizard?
        Could we do Authentication on Netscaler but tell Storefront do not route connection throuth Netscaler gateway when we logon on via browser?

        1. In StoreFront 3.5, there’s an HDX Optimal Routing page where you can select Direct for your farms. I haven’t tried the Direct option yet.

Leave a Reply