StoreFront 2407 – Configuration for Citrix Gateway

Last Modified: Jul 31, 2024 @ 2:13 pm

278 Comments

Navigation

This article applies to StoreFront versions 2407, 2402 LTSR, 2203 LTSR, 1912 LTSR CU8 and all other versions 3.5 and newer.

Changelog

StoreFront Configuration for Citrix Gateway

See the Citrix Gateway ICA Proxy for instructions to create a Citrix 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 Citrix Gateway is selected and click OK.
  3. In the StoreFront Console, right-click the Stores node, and click Manage Citrix 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 or Citrix Workspace app, so make it descriptive.
    2. In the Citrix Gateway URL field, enter the Citrix Gateway Public URL that resolves to the Citrix Gateway VIP.
      • The URL entered here must match what users enter into their browser address bars.
      • This URL can be a GSLB-enabled DNS name.
      • The Gateway URL usually does not need to be reachable from StoreFront unless you need the Callback for SmartAccess or non-password authentication (e.g. Smart Cards or Citrix Federated Authentication Service).
    3. Click Next.
    4. In the Secure Ticket Authority page, click Add.
    5. Enter the URL to a Delivery Controller. This can be http or https.
      • STA is installed automatically on Delivery Controllers.
      • There is no relationship between STA and CVAD farms. Any CVAD farm can use any STA server.
      • StoreFront chooses the STA server. Citrix Gateway must be configured to use the same STA servers that StoreFront chose.
    6. Click OK.
    7. Continue adding Secure Ticket Authorities (Delivery Controllers). Whatever Secure Ticket Authorities you add here must also be added to the Citrix Gateway Virtual Server on the Citrix ADC appliance. Click Next.
    8. 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.
    9. If you need SmartAccess or non-password authentication (e.g. Smart Cards or Citrix Federated Authentication Service), then enter the Callback URL.
      • The Callback URL must resolve to any Citrix Gateway VIP on the same appliance that authenticated the user. Edit the HOSTS file on the StoreFront server so the Callback URL resolves correctly.
      • If you are configuring Single FQDN, then the Callback URL must be different than the Single FQDN.
      • The Gateway Virtual Server that the Callback URL resolves to must have a trusted and valid certificate that matches the FQDN you are entering here.
      • The Gateway Virtual Server that the Callback URL resolves to must not have client certificates set to Mandatory.
      • See CTX399424 Gateway Callback and / or XML Communication fails after upgrade to Storefront 2203 for a workaround.
    10. If you don’t need SmartAccess or non-password authentication, then leave the Callback URL field empty.
    11. If you enabled two-factor authentication (LDAP and RADIUS) on your Citrix Gateway, change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
    12. Click Create.
    13. 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 Citrix 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.
    3. Check the box next to the Citrix 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 Citrix 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 and is acceptable as an Internal Beacon.
    3. The Internal beacon must never go down. If it’s down, then internal native Receivers will stop working. One option is to configure a Citrix ADC Responder HTML page as detailed at Julian Mooren Citrix ADC – How to create a High Available Beacon Point for Citrix StoreFront. 💡
    4. Click OK when done.
  10. Right-click the Server Group node, and click Propagate Changes.

Citrix Gateway Logon Page Theme

To make the Citrix Gateway logon page look like Receiver 3.0 and newer, see Citrix Gateway 12 Portal Theme. The Citrix Gateway X1 theme has the fewest issues and the most readily available documentation for customization. The Citrix Gateway RfWebUI theme has less documentation for customizations.

Single FQDN

Overview

Links:

You can either define separate FQDNs for StoreFront Load Balancing (internal) and Citrix 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. Or upgrade to Workspace app.
    • Receiver for Mac 11.9 or newer. Or upgrade to Workspace app.
    • Mobile Receivers
  • 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 Citrix 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 Citrix 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 Citrix Gateway VIP on DMZ Citrix ADC. Set the Citrix 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 Citrix Gateway VIP on the same DMZ Citrix ADC 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 Citrix 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 Citrix 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 Citrix ADC resolves the Single FQDN to the internal StoreFront Load Balancing VIP. You typically add internal DNS servers to the Citrix ADC. Or you can create a local Address Record on Citrix ADC for the Single FQDN.

  6. In the Citrix 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 Citrix Gateway

DNS:

  • Sample DNS names:
    • Single FQDN = citrix.corp.com
    • Callback FQDN = callback.corp.com
    • Internal Beacon FQDN = internalbeacon.corp.com
  • External DNS:
    • citrix.corp.com resolves to a public IP, which is NAT’d to a Citrix Gateway VIP on a DMZ Citrix ADC.
    • If email-based discovery, SRV record for _citrixreceiver._tcp.email.suffix points to citrix.corp.com. Create this SRV record in every email suffix DNS zone.
  • Internal DNS:
    • citrix.corp.com resolves to the Load Balancing VIP for StoreFront
    • callback.corp.com resolves to a Citrix Gateway VIP on the same Citrix ADC 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 citrix.corp.com. Create this SRV record in every email suffix DNS zone.

Certificates:

  • External, publicly-signed certificate for Citrix 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:
      • citrix.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:
      • citrix.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://citrix.corp.com
  • Internal beacon = https://internalbeacon.corp.com. Make sure it’s not resolvable externally.
  • Gateway object:
    • Gateway URL = https://citrix.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://citrix.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://citrix.corp.com
    • Single Sign-on Domain = Corp
    • Account Services address = https://citrix.corp.com

Multiple Datacenters / Farms

Multi-datacenter Citrix 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 Citrix ADC load balancing
    • If external, HTTP is proxied through Citrix Gateway, which proxies it through Citrix ADC 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 Citrix Gateway ICA Proxy
    • ICA traffic is handled by Workspace app’s ICA engine – either locally installed Workspace app, or HTML5 Workspace app

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 Citrix Gateway.
    1. StoreFront is usually proxied through Citrix ADC Load Balancing.
    2. If Citrix 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 Citrix 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 Citrix Gateway, or if HDX Optimal Routing is enabled, then the .ica file usually contains the FQDN of a Citrix 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 Citrix 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 Citrix 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 Citrix 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 Citrix Gateway that’s in the same datacenter as the VDA.
    2. Proxy ICA traffic through the Citrix 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 Citrix Gateway in the same datacenter as the VDA, StoreFront has two methods for identifying the Citrix Gateway that’s closest to the VDA:
    1. Different Citrix Virtual Apps and Desktops site/farm in each datacenter. If a VDA is launched from a particular site/farm, then provide the Citrix Gateway FQDN that is associated with that site/farm. This is configured using HDX Optimal Routing.
    2. Different Citrix Virtual Apps and Desktops zone per datacenter. If the VDA is launched from a particular zone, then provide the Citrix Gateway FQDN that is associated with that zone. This is configured using HDX Optimal Routing.
  7. Proximity and Persistence – For proxying ICA through a Citrix 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 Citrix 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 Citrix ADC to insert a header to StoreFront indicating the Citrix Virtual Apps and Desktops zone the user is connecting from. See the GSLB Powered Zone Preference whitepaper.

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

  • ICA Proxy through Citrix 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 Citrix Virtual Apps and Desktops Site/Farm is a collection of Delivery Controllers that share a single Site SQL Database. Multiple Citrix Virtual Apps and Desktops Sites/Farms implies multiple Site SQL databases, each configured separately. Note: farm is the old name for Citrix Virtual Apps and Desktops Site.

  • If you stretch a single Citrix Virtual Apps and Desktops Site/Farm across datacenters, then you have to deal with replication and recovery of the single SQL database.
  • Citrix Virtual Apps and Desktops 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 Citrix Virtual Apps and Desktops Site/farm.

Multiple Citrix Virtual Apps and Desktops Sites/Farms – StoreFront can enumerate icons from multiple Citrix Virtual Apps and Desktops 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.

  • CVAD 2311 and newer have multiple site management in Web Studio in the Settings node.

    • Use the Site selector at the top right of the page.
  • In StoreFront, 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 Citrix Virtual Apps and Desktops configuration using separate sites/farms in each datacenter. Another option is zones.

  • Citrix Virtual Apps and Desktops Sites/Farms: Separate Citrix Virtual Apps and Desktops sites/farms in each datacenter.
    • The Delivery 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, Citrix Gateway will use StoreFront in the remote datacenter. However, the remote datacenter has its own Citrix Gateway, thus there will be two different Citrix 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 Citrix Gateways: Externally-accessible Citrix Gateway ICA Proxy VIPs in both datacenters.
    • The main Citrix Gateway DNS name is active/active GSLB. For example: citrix.company.com)
    • Each datacenter has a datacenter-specific GSLB active/passive DNS name for Citrix 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 Citrix Gateways: Internally-accessible Citrix Gateway ICA Proxy VIPs in both datacenters for AppFlow reporting.
    • For AppFlow/Insight reporting, Citrix Gateway ICA Proxy is typically used internally too. If you don’t need AppFlow, then you don’t need internal Citrix Gateway.
    • To handle Single Sign-on from Receiver, internal Receivers will connect HTTP directly to StoreFront Load Balancing instead of proxied through Citrix Gateway.
      • This implies that you have separate DNS names for StoreFront and Citrix Gateway.
    • HDX Optimal Routing will force the ICA connection to go through Citrix 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 Citrix Gateway DNS name is active/active GSLB. For example: citrix.company.com.
      • Each datacenter has a datacenter-specific GSLB active/passive DNS name for Citrix 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 Citrix Gateway.
    • Externally,  citrix.company.com resolves to a Citrix 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 Citrix Gateway DNS name.
  • DNS Delegation for GSLB: multiple DNS names are delegated from internal DNS and public DNS to Citrix 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 Citrix ADC is not recommended. Public GSLB should be handled by DMZ Citrix ADC appliances. Internal GSLB should be handled by Internal Citrix ADC appliances.
    • If you only have one Citrix ADC 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 Citrix 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 Citrix ADC, all STAs must be added to all Citrix 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 Citrix Virtual Apps and Desktops in multiple datacenters, you must design roaming profiles and home directories correctly.

Icon Aggregation and Home Sites

To configure icon aggregation using PowerShell, see CTA Dennis Span at Citrix StoreFront Multi-Site Aggregation with PowerShell at CUGC. The PowerShell cmdlets include the following:

  • New-STFEquivalentFarmset
  • Add-STFUserFarmMapping

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 Citrix 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 Citrix Virtual Apps and Desktops in Datacenter A, then you probably want the ICA connection to go through a Citrix Gateway Virtual Server in Datacenter A.
    • If the main DNS name for accessing Citrix 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.
  • Citrix Gateway for internal connections (AppFlow). If you want to force internal ICA connections to go through Citrix Gateway so AppFlow data can be sent to Citrix Application Delivery Management (ADM), 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 Citrix Gateway Virtual Server requires user certificates. If ICA traffic goes through a Citrix 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 Citrix Gateway Virtual Server that doesn’t have user certificates as Mandatory. Use Optimal Gateway to force ICA connections through the other Citrix Gateway Virtual Server. Note: SmartAccess Callback URL also cannot use a Citrix Gateway Virtual Server where client certificates are set to Mandatory, so the extra Citrix 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 Citrix Gateways.
  2. Add more Citrix 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 Citrix 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 and Citrix Virtual Apps and Desktops, 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 Citrix ADC appliance that authenticated the user. If you have multiple Citrix ADC appliance pairs communicating with a single StoreFront server, then StoreFront needs to identify which Citrix ADC appliance pair the request came from, so it can perform a callback to that particular appliance pair.

If each of the Citrix Gateways uses the same DNS name (e.g. 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 Citrix Gateway Virtual Server that is handling the callback. Here are some options to handle the certificate requirement:
    • On the main Citrix Gateway Virtual Server, assign a wildcard certificate that matches both the GSLB name, and the datacenter-specific callback name.
    • On the main Citrix 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 Citrix Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific callback name.
  3. In the StoreFront console, create multiple Citrix 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 Citrix 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 Citrix ADC appliance from another.
    • When users use HTTP to connect to a Citrix Gateway for authentication and icon enumeration, when Citrix Gateway communicates with StoreFront, Citrix 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 Citrix ADC appliance pair (e.g. callback-a.corp.com). The callback URL must resolve to a Citrix 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

278 thoughts on “StoreFront 2407 – Configuration for Citrix Gateway”

  1. Hi Carl
    we bought citrix virtualApp and Desktops advanced license for our VDI deployment on premise and I have installed the license file in Citrix license server.
    I am getting following error when I am login into VDA agent.

    No remote desktop license server is specified.
    we have asked vender when we bought license for citrix they said you don’t need to buy remote desktop license as log as you have citrix virtualApp and Desktops advanced license. please advice.

    Reply

    1. All users that connect to a Remote Desktop Session Host (aka Server OS), must have a Microsoft Remote Desktop Services CAL. This is separate from the Citrix licensing.

      Reply

          1. sorry to ask again Carl. I just want make it clear.
            we have bought only citrix virtualApp and Desktops advanced license.
            I am planning to deploy MCS images for internal and external users accessing VDI desktop. please advice whether we need to buy RDS license accessing VDI desktop per user.

          2. If your VDAs are Server OS (e.g., Windows Server 2022), then each user also needs an RDS license.

            If your VDAs are Desktop OS (e.g., Windows 11), then RDS license is not needed.

  2. I am having an issue with Citrix load balance using Citrix ADC
    I am able to access the VDI directly from Storefront , not able to access Citrix ADC load balance .
    getting error cannot complete your request

    Reply

    1. If your browser address bar shows a StoreFront path (e.g., /Citrix/StoreWeb), then look at StoreFront Server > Event Viewer > Applications and Services > Citrix Delivery Services.

      Reply

      1. Thank you for your quick reply Carl.
        I have checked the StoreFront server event log and found Event 17.

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

        System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
        The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
        Url: https://127.0.0.1/Citrix/NBE-UK/discovery
        ExceptionStatus: TrustFailure
        at System.Net.HttpWebRequest.GetResponse()
        at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(HttpWebRequest req)
        at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(String url, String token, HttpRequestParameters options, Object requestData, CookieContainer cookieContainer, Boolean overrideLoopback)
        at Citrix.DeliveryServicesClients.Discovery.RequestHandler.DiscoveryHttpRequestHandler.GetDocument(String url)
        at Citrix.DeliveryServicesClients.Discovery.DiscoveryClient.GetDocument(String url)
        at Citrix.Web.DeliveryServicesProxy.ConfigLoader.Discovery.AppendConfigurationFromDiscoveryService(WebReceiverConfigSection section, DiscoveryClient client)

        System.Security.Authentication.AuthenticationException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
        The remote certificate is invalid according to the validation procedure.
        at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
        at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
        at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest, Boolean renegotiation)
        at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
        at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
        at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
        at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
        at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
        at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
        at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
        at System.Net.ConnectStream.WriteHeaders(Boolean async)

        Reply

        1. Click your Store. On the right side, click Manage Receiver for Web. Click Configure. On the Advanced Settings page, in the third row, change loopback to OnUsingHttp.

          Reply

          1. Thank you Carl, it is working now. much appreciated.
            I got another issue when I launch VDI desktop Citrix Receiver launch.ica file .
            however I can access the VDI desktop if I open with Citrix connection manager. Any idea , how do we fix. Thanks

          2. When you connect to StoreFront web page, there’s a blue button to Detect Workspace. Click that button and it should work automatically.

  3. Carl – first off, thank you for all that you do!

    I have a question about site aggregation, specifically the load balance across controllers options. I’m working on a large migration from 1912 to 2402 CU1. I currently have both sites added to StoreFront and aggregated in a load balancing failover mode and it’s set to enumerate the 2402 site first, then the 1912 site. This gives me the ability to publish identically named applications, grant certain users access to them, and they launch in 2402 and not 1912 unless I remove them. Where everyone else still goes to 1912. I’ve used this in previous migrations and it works great and makes things seamless for the end user.

    May not be how it’s designed to be used exactly but it works great for doing so. Anyways…

    I had a thought about the load balancing option whereas I could migrate a few systems into the new site, open it up to the users (all from 1912), and use it as a way to not only get some real testing but eventually migrate systems gradually from 1912 to 2402. Note, we are using the same server VDAs and upgrading the agent.

    My question is, how does SF actually load balance between the sites? I’m guessing it’s designed to be used where both sites are similar is capacity. In my example the 2402 site would be much smaller to start and gradually VDAs would be moved over until the 1912 is evacuated.

    I’m considering testing this theory if I can get approval. However I was trying to gather info before I do to see if the SF site load balancing would be smart enough if 2402 has no more capacity all the remaining sessions would just got to 1912.

    Thanks again!

    Reply

    1. Load balance resources across controllers: This setting controls session launch. Launch requests are either load balanced (round robin) across the Sites or distributed in failover order, regardless of whether the Sites are “identical” or not. Session sharing takes precedence over a load balancing decision and note that load balancing does not account for load index. Therefore, if a user already has a session in Site B and launches another application or desktop, that session will also launch in Site B (assuming the application or desktop is available there).

      https://community.citrix.com/tech-zone/design/design-decisions/storefront-multisite-aggregation/

      Reply

  4. Hello Carl,

    please assist with the error. I can access the application via Citirx gateway however I cannot lunch my apps.

    Error message: Failed to connect to the server because of an SSL error: 1000061.SSL Error 31: You have not chosen to trust
    “test-gateway.ideas.local”, the issuer of the server’s security certificate.

    thank you

    Reply

  5. Hello Carl. I have installed Citrix SF 2402 version. When i click on logoff button it gives below error. I have enabled trust to XML and also selected logoff action to terminate but still i see this error. Could you please provide solution ?

    ‘Logoff error : If any apps are still running, please exit them manually.

    Reply

  6. Hi Carl,
    I Configure a NetScaler ICA Gateway with the Authentication(LDAP) but gateway page stuck in “please log on loading your apps “.
    validated- LDAP authentication is working fine, STA is up and DNS is resolving. Storefront server is reachable from ADC and (using same url for both Internal- storefront base and external gateway ).
    Citrix ADC VPX for KVM 14.1 build 17.38.
    CVAD 2303 cu4. Let me know how to fix it.

    Reply

      1. Hi Carl,
        Not configured AAA Group or AAA User. Reconfigure the Netscaler Gateway ICA but still gateway page stuck in “please log on loading your apps “.
        Let me know how to find where it stuck and if its session policy related issue, then how to find logs related with session policy. Also not able to discover any events or logs on storefront for gateway access/denial request. I had cross validated the configuration from “https://www.carlstalhood.com/citrix-gateway-ica-proxy/” and not found any difference what I configured. In Active user sessions able to see authenticated Username, client IP( end user IP) , Client port, server IP-VIP, server port, but no Intranet IP.
        Even added new themes using base theme (RFwebUI) not no progress.
        Regards,
        Akash Tenguria

        Reply

          1. After unbind the session policy’s with virtual server, gateway page popup with error “Cannot complete your request”.

          2. So the policy seems to hit… the session profile is 100% correct? I would either play around with the profile (setting a wrong web interface address for example) and observe the error message to narrow down the issue or take a network trace.

  7. Hi
    Am I able to have a single netscaler gateway service two completely separate storefronts using different URL’s to connect to the netscaler and depending on the url directing to the correct storefront?

    For example
    address@domain1 > same netscaler > storefront1
    address@domain2 > same netscaler > storefront2

    Our current citrix is out of date and on the soon to be unsupported W2012 and the URL’s all need changing. I’m building a new one on W2022 with 2203 LTRS but would like to get them work side by side before decommissioning the old one.
    Thanks
    Andy

    Reply

    1. Create separate Session Policies for each one. The policy expressions should be HTTP.REQ.HOSTNAME.EQ(“domain1”) or something like that.

      Reply

  8. Hello Carl,

    I have a question regarding a new configuration for a citrix server 7.2203 with netscaler version 13.0.88.16

    On the web page for the external access, i need to have “username”, “password” and “token” , but i have “username”, password” and password2″.

    Can you tell me please how i can fix this?

    Thank you

    Reply

      1. Hello Carl.

        Thank you for your privious response. It worked.

        Another question. When i try to connect to the web page with token, the credentials are incorrect.

        The credentials are ok and the Authentication is working from the storefront page.

        I think there is something regarding the token for this netscaler. On others, the token is ok. On the netscaler everything is up.

        What do you think i should check?

        Thank you

        Reply

  9. Hello Carl,

    We have a CVAD site across two data centres with GSLB-enabled Citrix Gateway deployed on each location. Intentionally we want all connections going through one of the ADCs with EPA checks before nfactor authentication, even for internal users. With web browser pointing to GSLB FQDN for logon, everything works fine with EPA check, 2FA and Workspace app launched etc. However, if we launch Workspace app (either Windows and Mac) to add account, it goes to GSLB determined ADC for authentication, but then right after that, Workspace is redirected to ADC and it prompts for authentication again. But this time, it does not go to GSLB determined ADC. It goes to the default gateway (the one configured as default Citrix Gateway appliance of on Remote Access Settings on StoreFront server). After second time of authentication, account is added to Workspace app. Subsequent logins would go to default gateway only. If the default gateway appliance is down, login will fail without trying to login via the next available ADC. If there anything I configured incorrectly on Storefront in the parts of “Manage Citrix Gateways” or “Configure Remote Access Settings?
    Thanks!

    Reply

    1. The “default gateway” in StoreFront should be the GSLB FQDN. You might have multiple Gateways on StoreFront with the same FQDN but different callback URLs. The GSLB FQDN would be active/passive to send all traffic through one Gateway VIP.

      Reply

      1. Carl, thanks for your reply. Currently, there are two Citrix Gateway entries on Storefront for individual gateways and Gslblocation attribute added by Get-STFRoamingGateway, which points GSLB FQDN because we want both GSLB FQDN and individual gateways accessible. So, should we add a third entry to the list which points to GSLB FQDN and on Remote Access settings, we select it as the default appliance? Or, we should keep only the original two entries but change their URL to GSLB FQDN and remove the Glsblocation attribute (but then URL of individual gateways will no longer be accessible).

        Reply

        1. The Gateways in StoreFront only apply to Workspace app and don’t affect browsers.

          I usually create two Gateway objects with the same GSLB FQDN but different VIPs for Callback URLs. I haven’t tried the Gslblocation attribute.

          Reply

          1. Hi Carl,
            Following your suggestion, we have reconfigured the Gateway objects with same GSLB FQDN as URLs, double authentication issue does not occur anymore. CWA connects to GSLB determined gateway and works fine. However, when we enforce failover with GSLB by stopping the gateway that CWA has connected, the connection becomes stale. Neither logoff nor re-login works. Unlike working with browser, it seems CWA is waiting for connection timeout before it is able to connect to new gateway that GSLB resolves to while browser can always establish a new https connection. Is it related to the session time-out value (default 30 mins)? Any suggestion?
            Thanks again for your help!

  10. Hi Carl
    Great article. I’m planning aggregation across 2 different cvad sites.site1 is 1715ltsr in AD domain X the site2 is 1912 ltsr in AD domain Y .
    Site2 is the site I will be using to configure storefront aggregation.
    Assuming user A has an AD account in domains X and Y.
    If user A authenticates through Storefront in site2 with AD account in domain Y, I am assuming there will have to be an AD trust between domains X and Y and user A will need to be in a group in domain Y that is a nested member of a universal group in domain X which has access to published resources in site1?

    Reply

    1. The same AD Identity needs to be assigned to both icons if you want to load balance or failover the two icons.

      Reply

      1. Hi Carl
        Not sure I follow your response about the icons. I’m not planning load balancing or failover, I am just trying to facilitate users accessing resources from both cvad sites, with one AD account with 2 different forests involved. Just wanted to confirm my assumption about AD trusts and nested resource group memberships?

        Reply

        1. Each “site” (aka CVAD farm) provides a list of icons. Users and groups are assigned to the icons. If you want users to see icons from two different “sites”, then the one AD account must be granted access to icons in both “sites”. If the delivery controllers for the “sites” are in separate forests, then implement a domain trust and grant users in one domain to access published icons from delivery controllers in the other domain. This is standard Windows cross-domain authorization. Citrix has some articles regarding multiple domains/forests. For example, https://support.citrix.com/article/CTX134971/successfully-deploying-xendesktop-in-a-complex-active-directory-environment

          Reply

  11. Hi Carl, thanks for the nice article, it is very helpful. I’ve managed setup ADC gateway for StoreFront and it’s working fine for the internal access. But I’m facing a strange certificate issue accessing from internet with error message ‘Unable to connect to the server. Contact your system administrator with the following error: SSL Error 59: The server sent a security certificate identifying “www.notexist.com”, the SSL connection was to “Gateway.MyDomain.Com”.’. Could you please point me a direction how to fix this?

    Reply

    1. Is DNS working correctly for your Gateway FQDN? Maybe you have a DNS service that sends unresolvable DNS names to a generic webpage.

      Reply

      1. Thanks for your reply! DNS is working fine, one thing to mention is that the internal and external domain names are different. We are using MyDomain.com for internet access and MyDomain.net for internal access.
        Gateway FQDN: Gateway.MyDomain.com
        StoreFront FQDN: StoreFront.MyDomain.net
        VDA FQDN: VDA1.MyDomain.net
        We have setup CNAME for Gateway domain and it’s resolvable from both internal and external network. StoreFront and VDA FQDNs are only resolvable from internal network.

        Reply

  12. Hi Carl

    Looking at OGR and how to maintain a level of redundancy to the solution. If OGR is setup to direct traffic to a specific gateway for a XenDesktop Site what happens if that gateway is down ?

    is there a mechanism for automatic failover to an alternative gateway.

    Thanks for all your work, it’s an invaluable resource.

    Reply

  13. Hey Carl, quick question on this statement. “If the main DNS name for accessing Citrix 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.”

    Am I understanding it correctly that if the GSLB is used over 2 Netscaler gateways each each DC. Then you need to create 2 additional DNS names for the individual Netscaler Gateways at each site so the HDX optimal routing know who is what?

    Reply

      1. Ok cool, after reading all the comments I figured so. Thanks you!

        Now when you create the DNS records for the NS GW VIP( each DC aka GW FQDN)these are only needed so that Storefront knows what NS GW to send it to for OGR and those DNS records aren’t used outside if using GSLB as the main NS GW DNS name externally that his the public IP. So there only DNS records needed internally for the FQDN of the site NS GW?

        Reply

        1. Hey Carl, I’m a bit confused. In the ORG it says to have different DNS names for each DC if you using GSLB. But then it says if you’re using one storefront group use same DNS names for the URLs just name them different . Which would be the GSLB url In as each Gateway. How does ORG work and determine where to send the traffic? I’m also a bit confused on the DNS names That represent each Netscaler gateway, if I’m using one GSLB name. Does the other DNS names need to be open from the outside as well? Or is a internal DNS name ok as long as SF knows where to send it?

          I’m trying to wrap my head around using one GSLB name, then creating other DNS names for the site Gateways, using one storefront group with ORG.

          So for example.
          1 SF group with 4 SF servers
          2 Netscaler Gateways in each site
          1 GSLB Url for the 2 Netscaler Gateway.
          2 Netscaler Gateway DC DNS names for ORG.

          Do I create the different names and then add the GSLB URL and define the callback on those only?

          Then add the two other Netscaler gateways DNS and leave the callback back out(being it’s defined already)and just set the ORG to use the specified other 2 Netscaler DNS names?

          Reply

          1. Users type in a DNS name to access Citrix Gateway. That DNS name is usually GSLB, which means it could go to one of multiple gateways.

            However, HDX Optimal Routing must go through a specific gateway (not GSLB active-active), so new DNS names are required for each Gateway. StoreFront HDX Optimal Routing links a specific FQDN to a specific site/farm (StoreFront > Manage Delivery Controllers).

  14. Even after removing old STA from storefront and in ADC, there are still 5 more STA binded in ADC and same is available in storefront. when the app is launched and the relevant ICA file is opened it is still getting the old STA ID and token, . due to this users are getting error as “The published application is not available currently”

    Reply

  15. Thanks for the article, Carl, very well explained and detailed. I’m planning on using GSLB as a way to provide a unique point of access to 2 different CVAD sites (each one in a different datacenter). Each of those datacenters have 2 different ISPs, so I already designed the GSLB solution to provide access on a Public IP tied to each on of those ISPs. Now, I am at the point where I’m not sure how to be able to aggregate those 2 gateways per DC to be able to be able to provide OGR in an Active-Active fashion for each DC (Meaning ISP1 and 2 Provide access to the VDAs in Datacenter 1, and ISP 3 and for to the VDAs in Datacenter 2). Do you know if that’s possible?

    Reply

    1. Create separate OGR DNS names for each datacenter. The OGR DNS names are active/active GSLB across the two ISPs.

      Reply

  16. Hi, Carl! Thank’s a lot for this article! Finally I’ve got many things cleared up!
    But some questions are still remain.
    I have configured gateway in GSLB to one SF Group as you wrote. My gateway have two-factor authentication with client certificate, so the option “Client Authentication” is up with mandatory. I have made two different callback URL for each node (client authentication is off). And everything works fine, but when I trying to start application – it checks my client certificate again! In ICA-file i receive “SSLProxyHost=” instead “SSLProxyHost=”
    Where could I made a mistake?

    Reply

    1. You can configure HDX Optimal Gateway to send ICA traffic through the Gateway that doesn’t have client certificates enabled.

      Reply

      1. Thank you for response!
        I have only one group of two delivery controllers, and on the Optimal HDX Routing page I can’t chose it for the both gateways.

        Reply

  17. Hi Carl!

    we have configured an external gateway on NS12.1 64.16

    The virtual server is configured to use two Delivery Controllers, which run CVAD 1912 CU4, as STAs. Authentification and launching Apps / Desktops work fine, but the Gateway does not detect the workspace app of the client. A user can either choose to use the lightversion or select “Already installed”.

    Storefront is a dedicated machine and app detection does not work on any client (+different webbrowsers).

    If I connect to the storefront, internally, it detects the app just fine.

    Any idea how to configure the auto-detection?

    Reply

      1. Thanks for the quick response! Yes, ‘dig storefront.corp.org’ resolves the correct IP or should I check another way?

        The only communication that is blocked by our firewall from ADC -> Storefront is on ICMP, that should not matter, right?

        Reply

        1. Do users get the prompt to launch Workspace app during the detection process?

          You can try running Fiddler on the client machine to see the decrypted http packets from workspace app.

          Reply

          1. Yes, there is a prompt to open the app.

            I ran Fiddler. When trying to detect the app the process ‘webhelper’ connects over https. Nothing after that.

            Decrypted message:

            Secure Protocol: Tls12
            Cipher: Aes256 256bits
            Hash Algorithm: Sha256 256bits
            Key Exchange: RsaKeyX 2048bits

            == Server Certificate ==========

            $Corp_Certificate_Info

        2. I’m seeing something similar in our setup. WebHelper gets invoked by the browser with the correct settings, but then after establishing a TLS connection with the ADC it just…stops.

          Reply

          1. I am currently talking to Citrix Support, trying to resolve the issue. I will let you know any solutions we can find.

          2. Hi, finally we got a solution from Citrix. For the app detection to work through a Gateway the Site Binding in IIS on the StoreFront has to be configured with a BLANK hostname.

  18. Hi Carl, I would like to know if you know how to prevent someone Access Gateway / StoreFront from allowing edited ICA files to be used

    Reply

  19. Hi Carl, I wanted to make a query, I have created a site for xenapp, with a url to connect both internal and external users, via the web everything works fine, but because of the workspace app, it does not work, when I close the agent and do it I reopen, it no longer connects with the services url and it tells me that it failed to update the applications. any ideas?

    Reply

  20. Carl – this comment in your breakdown above raises a question: “The Gateway for the active/active GSLB-enabled DNS name doesn’t need any farms associated with it.”

    Does GSLB have to be in an active/active deployment for HDX Optimal Routing to work?
    I ask, because we had this working in our test environment at one time, and then we switched from an active/active GSLB deployment to an active/passive a few weeks back. Was testing HDX Optimal Routing in that environment yesterday and it’s not working now. Nothing was changed in the HDX routing related settings.

    Reply

    1. Each datacenter should have a datacenter-specific FQDN. Add each DC-specific FQDN as a Gateway to StoreFront. Then assign the DDC farm or zone to each DC-specific Gateway.

      Reply

      1. Right. That’s understood and how we’ve had it setup. The question is should HDX optimal routing work the same way (when setup properly) regardless of if the external GSLB setup is active/active or active/passive?

        TIA

        Reply

        1. Correct. OGR should be sending it to DC-specific FQDN, which should not care about how the active/active FQDN is configured. You can check your .ica files for SSLProxyHost to see the FQDN it’s sending you to.

          I normally configure GSLB active/passive for the DC-specific FQDNs so OGR doesn’t break if a DC is down.

          Reply

          1. I’m curious if you’ve ever seen something like this.

            We are using active/passive GSLB setup on external domain name.
            workspace.acme.com (GSLB URL)
            site-a-workspace.acme.com (active)
            site-b-workspace.acme.com (passive)

            Internally, we are using active/active GSLB setup for internal domain name between site A and site B (domain name same as external, using split DNS).

            External users are connecting via GSLB URL to Site A gateway. When launching a published desktop, no matter if it’s residing on StoreFront server group in Site A (assigned to site A gateway), or StoreFront server group in site B (assigned to site B gateway), they are all launching via site B gateway. Even Site A desktops.

          2. Do you have a proxy server? If your SSLProxyHost is set to an active/active FQDN, then maybe it’s doing persistence on the proxy’s source IP. Otherwise, check your .ica file for SSLProxyHost to make sure it’s the correct FQDN and then make sure it resolves to the correct IP.

          3. No SSL Proxy server is in use.
            All .ICA files, regardless if they are Site A or Site B resources, have a SSLProxyHost value of the site-specific FQDN for Site B.

          4. That’s the problem. Is each site a separate farm? If so, then you should assign each farm to a different gateway in StoreFront console. If it’s a single stretched farm with multiple zones, then zone configuration is different in StoreFront.

          5. Each site has separate farms and they are both mapped/assigned accordingly to the correct corresponding site specific gateways.

  22. Hi
    We have 2 sites that on aggregation
    The first site version is 7.15 and the second site version is 6.5
    When we open application from 7.15 site and then try to open application from 6.5 site
    The application from 6.5 dont open until we close the application from 7.15 site.
    What we can do to fix it

    Reply

  23. Carl, I have HTML5 working for my 2019 VDA, but the 2016 and 2012 VDA’s show this:

    SESSION:|:ICA:|:TRANSPORT:|:DRIVER:|:close with code=1006
    ERROR:|:error =error-server,error-local-access

    (I have 1 server with storefront/controller and the other 3 are vda’s)

    I’ve used the same scripts to enable ssl over vda… what do you think is up with the 2016 and 2012 boxes?? (WorkspaceApp works on all 3, all the time)

    Reply

    1. Ok, turns out it was the SSL Cipher Suite Order that needed to be “fixed” on the 2016 box. So now I have HMTL5 access to both the 2019 and 2016 VDA’s. But am still unable to figure out the correct “Cipher Suite” for 2012. Can anyone give me a copy of their 2012 cipher suite order for Citrix 7 and HTML5 working ???

      Reply

  24. Hi Carl, I have one question for you.
    I set a citrix gateway store in the citrix workspace app and I need to force the connection trough the citrix gateway. (No direct storefront connection).
    I’ve to choose between Optimal hdx routing or an internal fake beacon.

    Reply

    1. Optimal HDX Routing is only for ICA traffic. Fake internal beacon sends both StoreFront traffic and ICA traffic through the Gateway.

      Reply

  25. Hello Carl,

    I’ve used your articles to set up a POC environment, and they have been great. There’s one thing where I’m not sure if I made a mistake or not.

    When I connect to StoreFront through Citrix Gateway it gives back the internal URL of the store. I wouldn’t even have realized that if I hadn’t used HTTP for all internal connections (it’s only a POC after all) and it resulted in Citrix Workspace not connecting unless I allowed it insecure URLs in the registry. So in Citrix Worksapce I used https://citirx.poc.domain to connect, but in the accounts it shows http://citrix-server/Citrix/StoreName/discovery as URL. It does have the gateway in the extended settings. Also after enabling logging of the ICA file I see the internal URLs for StoreURL and SubscriptionUrl (the gateway is in SSLProxyHost).

    Is that expected or did I do something wrong? Because I had seen a Whiteboard video on the Citrix YouTube channel and they seemed to emphasize that no internal URL goes out to the client if using Citrix Gateway. But I might have misundestood that.

    Thanks!

    Reply

    1. When you add an account to Workspace app, it is downloading the provisioning file (.xml file) from StoreFront and using the .xml file to configure itself. Inside the provisioning file is Base URL, Gateway URL, and Internal Beacon. If Workspace app can connect to the Internal Beacon, then Workspace app connects to the Base URL. If Workspace app cannot connect to the Internal Beacon, then Workspace app connects to the Gateway.

      Browsers don’t behave like this. Browsers only see the Gateway URL and nothing else.

      Reply

      1. Ah, understood. I thought the provisioning file would just be different when connecting through the Gateway.

        Reply

      2. Hi Carl,
        If we have two storefront servers, how can add them to netscaler gateway.
        and how to add two domain controllers IP address for authentication on netscaler gateway

        Thanks

        Reply

  26. Hi Carl, I have a random error “cannot complète your request” (Citrix gateway).

    after investigation, I have an xml error: “incorrect xml character: XML5617 row 5 column 22” when I have the error “cannot complete your request”

    Rfuiweb is used.

    Reply

      1. My answer : it was an error with load balancing. I switched to COOKIEINSERT and no more 403 errors and no more “cannot complete your request”

        Reply

  27. Hello Carl, in the Configure Remote Access Settings dialog box, we have a default appliance which is not the one we are using. An impact?

    Reply

    1. When users use Workspace app to add the store, the default appliance is selected. Users would have to manually change Workspace app to use a different Gateway.

      Reply

  28. Hi Carl!
    Thanks for your work!
    I config my citrix adc(NS13.0 71.40.nc), then I setup Integrate with Citrix Products with quick start step by step.
    when i finsh, i can access my desktop via web interface, but can’t access with workspace client, how can i fix it?

    error message is：
    There is no Citrix XenApp server configured on the specified address. (Socket Error 10060)’

    i have even close firewall on vdi

    Reply

    1. Do you see the list of icons? If not, then it’s usually a problem with the Internal Beacon or Base URL. Workspace app 2012 > Advanced Preferences has a Log Collection link.

      Reply

      1. yes, I can see all the icons list,
        when i connect to vpn, i get vnc ip like 172.16.11.0/24

        citrix adc public ip is 172.16.101.x

        i have 2 vdesktop, first desktop a ip is 172.16.11.0/24, second vdesktop b is 172.16.25.0/24

        network 172.16.11.0/24 can’t connect to 172.16.25.0/25

        i can both open vdesktop a and b from web interface without any problem, but i can’t open b desktop with workspace, can only open desktop a, i have setup workspace with citrix adc domain already.

        Reply

  29. Hi Carl, hoping you can help a Network guy (apologise if i mix terms of aconyms) get his head around the communication flow we have. We currently have internal and external ADC’s. We currently hit a url from our thin clients that routes to internal ADC where they launch their desktop. The problem i have with this is in CTXsession & with packet captures it shows our remote address as our ADC Netscaler. i Dont actually want this for our internal users, i’d like them to communicate directly to the VDA, this has become a bigger problem since we moved our VDA’s into Azure where our back end compute now lives and our sites communicate through an MPLS to Azure over express route (private connection)

    If i launch Storefront directly i get what i want, ctx session goes direct from thin client to VDA in Azure.

    What im trying to understand really is architecturally what is the best way to do this, should i be recommending we move our thin clients to talk to the load balanced IP of storefront servers instead? Or is there a way i can get Netscaler to handover the ICA session to go direct? i think because of some of the other logic built into our session policies the favourable thing to do was to stay pointing to internal Netscaler but im at a loss as to how to get Netscaler to handover the connection, all of the guides online seem to be about doing the opposite and configuring the ICA Proxy settings, which i am happy with for external use anyway.

    Hope that makes sense and you can steer me in the right direction with this SOS 😀

    Reply

    1. If you want a single FQDN for both internal and external, then I usually do split DNS where internal DNS resolves the FQDN to the StoreFront load balancing VIP and the external DNS resolves the FQDN to the Gateway VIP.

      Reply

  30. Is it possible to have Single FQDN for both internal and external while only having certificate on the netscaler?

    I mean offloading all SSL to netscaler and have no SSL on the storefront and devlivery controllers at all.

    Reply

    1. Both the LB vServer and the Gateway vServer are on NetScaler. Both can share the same certificate.

      I recommend using SSL between NetScaler and StoreFront but the cert on StoreFront can be any cert.

      Reply

  31. Carl, is there a way to restrict the Storefront HTML Receiver based off of an active directory group either through a Netscaler session policy, or some way to do it within the storefront IIS settings? We are on NS 12.1 and Storefront 1912 CU1.

    Reply

    1. In Citrix Gateway, maybe you can use an Authorization Policy to deny access to /Citrix/StoreWeb/clients/HTML5Client/. Bind it to a AAA Group.

      Reply

  32. Hi Carl, we’ve been using single FQDN with our old SF servers (3.0.1) successfully for years. We tried to get this running with our test SF (19.12) servers without success, we spoke to Citrix who said it will no longer work, is this true?

    Reply

    1. It definitely works. What is not working for you? Make sure the Internal Beacon is not the Single FQDN and is internal only. Callback must also be a different FQDN.

      Reply

        1. So, I’ve managed to get it all setup and configured and it all appears to be working except HTML5 internally. With the old SF servers we modified the webconfig’s optimal gateway routing to route traffic via an internal NS gateway which took care of the SSL side. Is that still a valid configuration with SF 19.12, and if so what is the best way to inject that config?

          Reply

          1. In StoreFront console, go to Stores > myStore > Configure Store Settings. There’s an HDX Optimal Routing page.

          2. Do I just set the internal gateway to HDX routing only? Then do I use the callback URL for the internal gateway, external gateway, or both? This is where I tend to get a bit stuck!

          3. Callback is not needed unless you are doing SmartAccess or SAML.

            Add HDX Optimal Gateway. Uncheck the External only box.

          4. OK I’ve tried that but HTML5 is still failing on our internal network?

            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: TRYING FOR SOCKET CONNECTION ON citrixappsb.sealedair.com : 443
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: websocket-url=wss://xxxxxx.com:443
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: Current Protocol Index is : 0
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: CHANNEL SOCKSV5
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: websocket-url=wss://xxxxxx:443
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: Current Protocol Index is : 1
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: websocket-url=wss://xxxxxx:443
            [Tue, 15 Sep 2020 12:16:57 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: Current Protocol Index is : 2
            [Tue, 15 Sep 2020 12:16:58 GMT] SESSION:|:ICA:|:TRANSPORT:|:DRIVER:|:close with code=1006
            [Tue, 15 Sep 2020 12:16:58 GMT] ERROR:|:error =error-server,error-local-access

            Any ideas?

          5. Hi Carl & Nick,

            I am having the exact same issue on my Storefront servers and using HTML5. If I do not setup Optimal Gateway Routing, the NSGW works fine. If I have Optimal Gateway Routing Enabled, I get an error: As you can see, its trying to use port 8008, but I thought if it goes through the NSGW, its supposed to use 1494/2598? I had the HDX Routing Configured under the store with the managed zones.

            [Tue, 15 Dec 2020 22:34:41 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: TRYING FOR SOCKET CONNECTION ON 1.2.3.4: 8008
            [Tue, 15 Dec 2020 22:34:41 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: websocket-url=ws://1.2.3.4:8008
            [Tue, 15 Dec 2020 22:34:41 GMT] INIT :|: CONNECTION :|: WEB SOCKET :|: INFO :|: Current Protocol Index is : 0
            [Tue, 15 Dec 2020 22:34:41 GMT] SESSION:|:ICA:|:TRANSPORT:|:DRIVER:|:error with code=18 , name=SecurityError , message=Failed to construct ‘WebSocket’: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. ,call stack=Error: Failed to construct ‘WebSocket’: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
            at JA8hr.connect [as ECjNo] (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:132:3352)
            at KDxXd.ECjNo (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:134:3032)
            at qhTmi.connect [as ECjNo] (https://url.abc.com/Citrix/myWeb/clients/HTML5Client/src/Business/IcaClient05022020.js:138:12078)
            at BvsKd.start (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:358:6626)
            at https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:386:3116
            at Object.get (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/SessionWindow.js:40:26422)
            at szwyx (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:386:2744)
            at Uev2r.plg23 (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:386:1216)
            at MessagePort.vUxqw (https://url.abc.com/Citrix/myweb/clients/HTML5Client/src/Business/IcaClient05022020.js:360:7594)
            [Tue, 15 Dec 2020 22:34:41 GMT] ERROR:|:error =error-secure
            [Tue, 15 Dec 2020 22:34:41 GMT] INIT :|: CONNECTION :|: TRANSPORT DRIVER :|: CHANNEL CGP
            [Tue, 15 Dec 2020 22:34:41 GMT] INIT :|: CONNECTION :|: CGP SOCKET :|: INFO :|: Start Initializing CGP Socket

  33. Carl, I hope you can help me. I have a ADC Gateway with load balanced Storefronts. I use Azure MFA (NPS). The web version works perfectly. Users surf to the gateway, logon, enter a code received by SMS and they are ready to work. The receiver is giving me a headache. I configured Storefront to use no Full VPN. I enter the gateway url in the receiver to configure it for the first time, logon and it asks me for the MFA code. I enter it, and everything works fine. This works both internally as externally. However, when a user is working externally and the receiver is shutdown, the users logs off or reboots the pc, he is no longer able to start his apps or login in the receiver. It says ‘your apps are not available at this time. Cannot contact store service’. So it only works 1 time externally, when you add the gateway address, afterwards is always fails. Could you tell me what’s the reason?

    Reply

  34. Hi Carl,

    Thank you for the information. I am quite impressed with your knowledge around the Citrix products. I am hoping that you can help me with my new Citrix installation.

    I have been using Citrix XenApp 6.5. I want to install the latest LTSR version on a new server and begin using the new version.

    I have gone through the installation and setup of the Delivery Controller, Director, Studio, License Server, Storefront and the VDA for version 1912 LTSR Virtual Apps. I have published apps to the StoreFront and set up a Published Desktop. We generally have very few users logged into Citrix at any given time (with this crisis being an exception), so a single server installation works just fine for us. As such, I have installed all components on a single physical server.

    The Receiver for Web Sites is currently configured as http://[servername].[domainname].local/Citrix/%5BSiteName%5DWeb. I can connect to the StoreFront and launch all applications and the published desktop when I connect from a computer attached to the local domain by using either this address or http://[local IP address]/Citrix/[SiteName]Web . If I enter just the part before the /Citrix it resolves to full path in both cases.

    During the setup I was given the option to Enable Remote Access. When this is selected however, it indicates that a Citrix Gateway appliance is required. I have not set up a Citrix Gateway and would prefer not to if I don’t have to.

    Externally, I can connect to the Storefront by navigating to http://[external IP address]/Citrix/[SiteName]Web (I have the external IP address NAT’d to the internal IP address on my firewall). The Storefront launches fine and I can see all of my apps listed. When I attempt to launch any of them however, I receive an error message. The most common is ‘Unable to connect to the server. Contact your system administrator with the following error: Protocol Driver error’. I have also seen a message a couple of times indicating the server could not be located. Searches for this error seem to indicate that the Citrix server cannot be reached.

    My current XenApp 6.5 installation works quite well and is configured to use the NAT translation for external access, which does not require the Citrix Gateway:

    From all I have been reading about the current Virtual Apps installation, it seems that the Citrix Gateway should be optional. I cannot find an answer as to how to configure the current installation to allow remote access without a Citrix Gateway however.

    The remote access component is my biggest hurdle at the moment. If I can get that working, I will be able to finish the new installation and begin going live on the new version.

    I opened a support case with Citrix and asked them and they told me I need a Citrix Gateway. I asked whether there is a software version that could be installed on the same single server and they could not tell me. They said to open another support case with a different department.

    I do use a Cisco ASA and I believe it has some functionality around creating a Clientless VPN tunnel that might be used as an alternative to the Citrix Gateway but am not clear on which is best and the most cost effective.

    What would you recommend?

    Thank you in advance for any help you can provide me.

    Reply

    1. There are always two connections to any published app or desktop. The first connection is to StoreFront, which you can easily NAT. The second connection goes directly to the VDA machine. Each VDA machine has its own IP address and it is difficult to NAT multiple VDA IP addresses. Citrix Gateway proxies the second connection through a single IP address so you only have to NAT the Citrix Gateway IP.

      Without Citrix Gateway ICA Proxy, you’d need VPN.

      Reply

      1. Thank you for the your prompt response Carl.

        Is there a software version of the Citrix Gateway that I can download or do you have to install a NetScaler appliance?

        If there is a software version of the Citrix Gateway, can you point me to the version I would need and where to download it please? I am assuming that there is would be no additional licensing fees for a software version of the Gateway.

        Reply

        1. Citrix Gateway VPX is cheapest at around $1000. This edition does not have ADC load balancing.

          Reply

          1. Thanks for the information Carl. I’ll look into that. I definitely don’t require load balancing.

  35. Hi Carl,

    In your example, the FQDN used to configure the StoreFronts Base URL is https://storefront.corp.com but when you configure the Citrix Gateway the Citrix Gateway URL is https://citrix.corp.com. If you configure single FQDN, these two URL, should not be the same?

    Is it possible to use the same netscaler to configure internal load balancing (for my two StoreFronts) and the external access from internet to my two StoreFronts? Would you need two Stores for this purpose? Thanks!

    Reply

    1. It depends if you’re doing Single FQDN or not. Single FQDN is optional. One difficulty with Single FQDN is how to handle DNS resolution for users with laptops that move between internal and external since internal it needs to resolve to StoreFront while external it needs to resolve to Gateway. There tend to be fewer DNS problems with two FQDNs instead of Single FQDN.

      Gateway proxies the connection to internal StoreFront. You don’t need a separate store just for External. Yes, a single ADC can do both, but it’s security best practice to put Gateway on a DMZ-only appliance and put StoreFront on a separate internal-only appliance.

      Reply

      1. Thanks for your answer. If I use single FQDN, I can configure the Beacons to handle internal and external DNS resolution, is it correct?

        Do you have a guide to configure a Gateway on DMZ appliance?

        Thanks.

        Reply

          1. Thanks Carl,
            In my case, there are only a few users who have external access and they use differents devices for internal access.

          2. Hi Carl,

            Finally, the client want two FQDNs (one for external access and another one for internal access). In this case, is it necessary two vServers in the NetScaler? Do you have a guide for this scenary?

            Many thanks

          3. Are they giving out different IP addresses? If so, then can create separate GSLB Services and separate GSLB vServer. I recommend separate ADC appliances for internal GSLB DNS vs external GSLB DNS.

  36. Carl, Receiver Roaming – Storefront doesn’t allow adding 2 farm’s in same farm name in manage delivery controllers. could you please confirm?

    Reply

    1. When you add a farm to Mange Delivery Controllers, you can name the farm anything. The farm name only affects subscriptions/favorites.

      Reply

  37. Hi Carl, can I have same SRID for 2 Stores on the same SF server?

    Use case:
    Wanted to keep internal and external separate. Today we are using same store and domain joined laptops work seamlessly when they are remote using beacon.

    If I create a new Store and tag it with Gateway, domain joined laptops are having an issue “Cannot contact Store”.

    I want to make this change seamless for end users.

    Thanks.

    Reply

    1. I don’t think I’ve tried it.

      What is the internal beacon? If it’s reachable, then Workspace app connects to the Base URL. If internal beacon is not reachable, then Workspace app connects to Gateway address. You can enable Workspace app logging to see the problem.

      Reply

  38. For user mapping on storefront server group at siteB, SiteBusers should be at 1st Priority and SiteAusers should be at 2nd Priority, right Carl?

    Reply

  39. Hi Carl, I have a question about creating two load balancing vServer for Storefront servers.

    You said, “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.”

    Do I also need to create session policy/profile for load balancing vserver created for the remote storefront servers?

    Reply

    1. Nope. Just point it to the Primary Load Balancing vServer and if it is down then it will automatically fail over to the Backup vServer.

      Reply

      1. In Session Profile inside “Published application” tab under “Web Interface address” I am using Load Balancing VIP like https://10.10.10.10/Citrix/StoreWeb.

        Even in this kind of set up, I don’t have to create a session policy with load balancing VIP of remote Storefront servers?

        What I understand from your point is that since BaseURL is same for local and remote Storefront servers and NetScaler can resolve load balancing VIPs (local as well as remote) to the BaseURL, a single session policy (with Web Interface address = https://citrix.corp.com/Citrix/StoreWeb) is enough for RfW, right Carl?

        Reply

        1. Point your browser to the primary load balancing VIP. Disable the Service Group for the primary load balancer so it goes down. The Backup vServer should now be reachable through the primary load balancing VIP.

          Reply

  40. Carl, SSO is working in the old OU where there is no Receiver policy.
    After moving computer objects to different OU It is prompting for credentials. I enabled pass-through authentication in the computer configuration policy’s, but no luck.

    Reply

  42. Hi Carl,

    Thanks for your work.
    I’ve configured my Netscaler and Storefront with a single FQDN. I use email based discovery with multiple email suffixes. The Storefront servers are load balanced on the Netscaler. Just as your write-up suggests.
    But I only have 1 Netscaler so my line manager wants me to change this setup and use NLB for load balancing the Storefront servers as I have a SPOF now, and unfortunately I cannot disagree. I would love to install a second Netscaler in our other datacenter, but I just don’t have the approval for that.
    Is it possible to maintain the single FQDN setup, but use NLB for the Storefront servers? In other words can I just replace IP adress from the vServer to the NLB IP? Or is this not possible?
    Furthermore do you have a really strong argument why I should use the load balancing from Netscaler as opposed to NLB?

    Reply

    1. I don’t think I’ve tried NLB anywhere, partly because Citrix ADC VPX Express is free.

      Reply

  43. Great stuff. Invaluable site. Regarding optimal HDX routing – for a Receiver for Web client, assuming both Netscaler and Direct are configured for HDX routing, how is the decision normally made as to whether a client is external (and thus gets the SSLProxy=netscaler & SSLEnable=on entries in the downloaded ICA file)? I thought it was maybe Beacons, but everything I can find seems to indicate that logic’s only used by full Receiver client, not by web. Thanks!

    Reply

    1. NetScaler Gateway adds headers to the HTTP requests that it sends to StoreFront. If StoreFront sees the headers, then StoreFront assumes the user is connecting through a Gateway, which means “external”.

      Reply

Leave a Reply

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