Citrix Cannot Connect to Server Try Connecting Again in a Few Minutes

Navigation

This article applies to StoreFront versions 2203 LTSR, 1912 LTSR CU5, 1909, iii.16, 3.12.8000, and all other versions three.five and newer.

  • Change Log
  • StoreFront Configuration for Citrix Gateway
    • Citrix Gateway Logon Page Theme
  • Single FQDN for internal and external
  • Design StoreFront and Citrix Gateway for Multiple Data Centers
    • HTTP protocol vs ICA protocol
    • StoreFront and Multiple Sites or Zones
    • StoreFront in Multiple Data Centers
    • Typical Multi-datacenter Design
  • StoreFront Configuration for Multiple Data Centers
    • Configure Icon Aggregation and Home Sites
    • Configure HDX Optimal Gateway
  • Multiple Gateways Connecting to One StoreFront

Changelog

  • 2019 Dec 5 – Internal Beacon – added link to Julian Mooren Citrix ADC – How to create a High Available Beacon Signal for Citrix StoreFront
  • 2019 Mar 30 – inverse NetScaler Gateway to Citrix Gateway for StoreFront 1903
  • 2018 Sep two – replaced XenApp/XenDesktop with Citrix Virtual Apps and Desktops
  • 2018 Mar 13 – in the Icon Assemblage department, added link to CTA Dennis Span Citrix StoreFront Multi-Site Aggregation with PowerShell at CUGC
  • 2017 December 2 – updated Docs links for current-release

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 so 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 theStores node, and click Manage Citrix Gateways.
  4. If StoreFront 3.6 or newer, find theimported from file link on tiptop. This is a new feature of NetScaler 11.ane and newer. An example configuration that uses this characteristic can be constitute in the StoreFrontAuth page.

  5. If you're non using the Gateway config file from NetScaler eleven.i and newer, click Add.
    1. In the General Settings page, enter a brandish name. This name appears in Citrix Receiver or Citrix Workspace app, then get in 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 demand 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 folio, click Add.
    5. Enter the URL to a Commitment Controller. This tin be http or https.
      • STA is installed automatically on Delivery Controllers.
      • There is no human relationship between STA and farms. Any subcontract can use whatsoever STA server.
      • StoreFront chooses the STA server. Citrix Gateway must exist configured to utilize the same STA servers that StoreFront chose.
    6. ClickOK.
    7. Go along adding Secure Ticket Authorities (Delivery Controllers). Any Secure Ticket Government you add hither must as well be added to the Citrix Gateway Virtual Server on the Citrix ADC apparatus. Click Next.
    8. In the Authentication Settings page, the VServer IP Address field is typically left blank. You lot merely utilise this field if you lot have multiple Gateways (on divide appliance pairs) connecting to one StoreFront server. See beneath for details.
    9. If you lot need SmartAccess or non-countersign hallmark (due east.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 yous are configuring Single FQDN, and so the Callback URL must be different than the Unmarried 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 customer certificates set to Mandatory.
      • See CTX399424 Gateway Callback and / or XML Advice fails after upgrade to Storefront 2203 for a workaround.
    10. If you don't need SmartAccess or not-countersign authentication, then leave the Callback URL field empty.
    11. If yous enabled two-factor authentication (LDAP and RADIUS) on your Citrix Gateway, change the Logon blazon to Domain and security token. Otherwise leave it set to Domain simply.
    12. Click Create.
    13. So clickFinish.
  6. You can add more Gateways depending on your blueprint. Multiple datacenters typically requires multiple Gateways. ClickShut when washed.
  7. To enable the shop to utilise Citrix Gateway, in the middle, right-click your store, and click Configure Remote Access Settings.
    1. Check the box side by side to Enable Remote Admission.
    2. Get out it set toNo VPN tunnel.
      • Annotation: if you desire Receiver to automatically launch a VPN tunnel, and then run into CTX200664 How to Configure Receiver for Seamless Feel Through NetScaler Gateway.
    3. Bank check the box next to the Citrix Gateway object y'all just created. This binds the Gateway to the Store.
    4. If you lot accept multiple Gateways, select one of them as theDefault apparatus.
      • Note: when you point Receiver to a Citrix Gateway URL for Discovery, afterwards Discovery is complete, the Default appliance selected hither is the Gateway that Receiver uses. In other words, Receiver ignores the Gateway y'all entered during discovery.
    5. Click OK to close theConfigure Remote Access Settings dialog box.
  8. In the StoreFront Console, right-click theStores node, and clickManage Beacons.
  9. In the top half of the window, make sure theInternal beacon is set to a URL that is but reachable internally.
    1. If you are configuring Single FQDN, and then the Internal buoy must be different than the Single FQDN.
    2. Service URL = the StoreFront Base of operations URL. If yous're non configuring Single FQDN, then the Base of operations URL is usually not accessible externally and is acceptable as an Internal Buoy.
    3. The Internal buoy must never go downwards. If it's down, then internal native Receivers will stop working. I pick is to configure a Citrix ADC Responder HTML page as detailed at Julian Mooren Citrix ADC – How to create a High Available Buoy Point for Citrix StoreFront. 💡
    4. ClickOK when done.
  10. Right-click theServer Grouping node, and click Propagate Changes.

Citrix Gateway Logon Folio Theme

To make the Citrix Gateway logon folio look like Receiver three.0 and newer, encounter Citrix Gateway 12 Portal Theme. The Citrix Gateway X1 theme has the fewest bug and the well-nigh readily available documentation for customization. The Citrix Gateway RfWebUI theme has less documentation for customizations.

Single FQDN

Overview

Links:

  • Citrix CTX200848 How to Configure Single Fully Qualified Domain Name for StoreFront and NetScaler Gateway
  • Citrix Docs – Create a single Fully Qualified Domain Name (FQDN) to admission a shop internally and externally

Y'all tin either define separate FQDNs for StoreFront Load Balancing (internal) and Citrix Gateway (external). Or, yous can define a Single FQDN for both.

Single FQDN has the following requirements:

  • Receivers:
    • Receiver for Windows iv.ii or newer. Or upgrade to Workspace app.
    • Receiver for Mac 11.ix 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 Unmarried FQDN to theStoreFront Load Balancing VIP
    • External DNS should resolve the Unmarried FQDN to theCitrix Gateway VIP (public IP)
  • NetScaler ten.ane or newer
  • The FQDN for Internal Beacon must exist unlike than the Unmarried 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 Buoy URL can exist http instead of https.
    • If Internal Beacon URL is https, then the car hosting the IP accost for the Internal Beacon must accept 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 simply needed for SmartAccess and SAML.
    • Callback FQDN can resolve tot he same Gateway VIP used past external users. Or, you tin 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 yous have laptops that motility from internal to external and back once again, then DNS caching will interfere with Single FQDN. The DNS response for Single FQDN needs to modify whenever the device moves from internal to external and back again. However, Receiver uses the aforementioned DNS cache as Internet Explorer, which caches DNS responses for thirty minutes. To clear the DNS cache, you have to close Receiver and re-open it. The DNS response y'all run across when y'all 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 intendance nearly email-based discovery, so the configuration of Single FQDN is fairly elementary. Sample DNS names are used beneath. Make certain the certificates lucifer the DNS names.

  1. Internal DNS name = the Single FQDN (e.thou.storefront. corp.com). Internally, the DNS name resolves to the internal Load Balancing VIP for StoreFront. Set up the StoreFront Base URL to this accost.
  2. External DNS name = the Single FQDN (east.g.storefront. corp.com). Externally, the DNS proper noun resolves to a public IP, which is NAT'd to Citrix Gateway VIP on DMZ Citrix ADC. Set up the Citrix Gateway object in StoreFront to this FQDN.


  3. If yous need SmartAccess, so the Callback URL = any DNS name (e.m. callback.corp.com) that resolves to a Citrix Gateway VIP on the aforementioned DMZ Citrix ADC appliance that authenticated the user. The Callback URL cannot exist the Single FQDN.
    • Callback URL tin be omitted if yous don't need SmartAccess features, or SAML hallmark.
    • The callback DNS name must be unlike than the Single FQDN.
    • The callback DNS name must resolve to a Citrix Gateway VIP on the aforementioned appliance that authenticated the user. This could be the same DMZ Gateway VIP used past external users. Or you tin can create a carve up internal Gateway VIP on the same appliance.
    • The Citrix Gateway vServer for callback must have a certificate that matches the Callback DNS proper noun.
  4. Internal Beacon = any internal website URL that is not externally accessible. You tin can't use the Unmarried FQDN every bit the Internal Beacon. Note: if the internal beacon is downwards, and then internal Receiver Self-service volition not work correctly.
    • Brand sure the Internal Buoy is not resolvable externally.
    • The Internal Beacon URL cannot exist the Single FQDN. It must be unlike.
    • Ideally, the Internal Buoy should exist a new DNS name that resolves to a StoreFront Load Balancing VIP.
    • If the internal beacon is https, and so the document must match the internal buoy DNS name. However, http URLs besides 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 Tape 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 Accost to the Single FQDN.


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

If you need electronic mail-based discovery, and then here'southward an instance configuration for ICA Proxy Citrix Gateway

DNS:

  • Sample DNS names:
    • Single FQDN = citrix.corp.com
    • Callback FQDN = callback.corp.com
    • Internal Buoy 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.electronic mail.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 aforementioned Citrix ADC that authenticated the user. Unremarkably only needed for SmartAccess and/or SAML.
    • For the internal buoy, 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 electronic mail suffix is also corp.com. If you more than one email suffix, then wildcard will not piece of work.
    • Another choice is the following Subject Alternative Names:
      • citrix.corp.com
      • callback.corp.com – for callback URL. But accessed from internal.
        • Or you tin can create a dissever internally-facing Gateway vServer for callback with a separate certificate.
      • If electronic mail-based discovery, discoverReceiver.email.suffix for each electronic mail suffix. If yous accept multiple email suffixes, yous'll need multiple SAN Names.
  • Internal certificate for StoreFront Load Balancing:
    • Publicly-signed certificate is recommended, particularly for mobile devices and thin clients.
    • Since y'all have the same DNS name for internal and external, you tin apply the external certificate for internal StoreFront.
    • One option is wildcard for *.corp.com. Assumes email suffix is also corp.com. If you have more one email suffix, then wildcard will non piece of work.
    • Another option is the following Bailiwick Alternative Names:
      • citrix.corp.com
      • If email-based discovery, discoverReceiver.e-mail.suffix for every email suffix. If you have multiple e-mail suffixes, then you will have multiple SAN names.

StoreFront Configuration:

  • Base of operations URL = https://citrix.corp.com
  • Internal buoy = https://internalbeacon.corp.com. Make sure it'southward non 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 = Let or Off
    • Plug-in Type = Java
    • Unmarried Sign-on to Web Applications = checked
  • Security tab:
    • Default say-so = 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 Admission = Let or Off
    • Plug-in Type = Java
    • Unmarried Sign-on to Web Applications = checked
  • Security tab:
    • Default say-so = Let
  • Published Applications tab:
    • ICA Proxy = On
    • Web Interface accost = https://citrix.corp.com
    • Unmarried Sign-on Domain = Corp
    • Account Services address = https://citrix.corp.com

Multiple Datacenters / Farms

Multi-datacenter Citrix Gateway and StoreFront Blueprint

HTTP vs ICA

There are two connections from every Citrix customer:

  • 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 information technology through Citrix ADC load balancing.
    • HTTP traffic is initiated past either a web browser, or by Receiver Self-Service
  • ICA (SSL optional) – goes to Virtual Delivery Agent
    • ICA can go straight (internal) to a VDA
    • Or ICA tin can be proxied through Citrix Gateway ICA Proxy
    • ICA traffic is handled past Workspace app'south ICA engine – either locally installed Workspace app, or HTML5 Workspace app

The FQDN for the HTTP connexion can be the aforementioned or different than the FQDN for the ICA connexion.

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

  1. DNS proper 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 proper noun to ane of the datacenter VIPs.
    1. This tin can exist active/agile, or active/passive.
  4. Proximity and persistence – For active/active, since StoreFront traffic (HTTP) is so minimal, it normally doesn't matter which datacenter is selected. But you tin 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 past 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, and so the .ica file usually contains the private IP accost of the Virtual Delivery Agent. Receiver connects straight 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 lot simply have to expose one public IP address per datacenter no matter how many VDAs yous 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 yous have 2 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 command which datacenter is used for the ICA connection. There are two common designs:
    1. Proxy ICA traffic through a Citrix Gateway that'south 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 dorsum booty 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/subcontract 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 commonly a long-lived TCP connexion 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. Come across the GSLB Powered Zone Preference whitepaper.

Internal Citrix Gateway ICA Proxy? – Internal users typically accept direct connectivity to VDA Private IP addresses, and then yous commonly don't need to apply 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 Awarding 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 Commitment 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 accept to deal with replication and recovery of the unmarried SQL database.
  • Citrix Virtual Apps and Desktops Zones and Local Host Cache arrive more feasible to stretch a farm. See XenDesktop Site Failover – how do you do it? at CUGC for an first-class discussion on multi-datacenter zone design.
  • VDAs tin can merely annals with one Citrix Virtual Apps and Desktops Site/farm.

Multiple Citrix Virtual Apps and Desktops Sites/Farms – StoreFront tin 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 then that only a single icon is displayed to the user. When the user clicks the icon, StoreFront then needs to select a site/subcontract.

  • Sites/Farms tin can be prioritized (active/passive) for different Active Directory groups. This allows you to specify a "abode" site for specific users. Typically yous ready the preferred site/farm to be in the aforementioned datacenter that contains the user's home directory and roaming profile.
  • Or sites/farms can be agile/active load counterbalanced. This works all-time for applications that have synchronized active/agile back-end information.

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

  • StoreFront Panel GUI – The most common multi-site/farm configurations tin be washed in the StoreFront Panel GUI, including configuration of "Habitation Sites" (dissimilar Advertisement groups prioritizing different sites/farms).
  • XML files – for more complex multi-site configurations. Meet Citrix Docs – Prepare upward highly bachelor multi-site shop configurations

Note: if yous have existing subscriptions/favorites, then enabling icon aggregation will cause the existing subscriptions to be ignored. You tin migrate the existing subscriptions past exporting, modifying, and importing. Run into Subscriptions Missing later on Enabling Assemblage 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 unlike StoreFront Server Grouping.

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

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'southward possible for each datacenter to be treated equally a split up Store, causing multiple Store entries in Receiver. This can be prevented past ensuring the following configurations are identical in both datacenters. Source = Juan Zevallos at Citrix Discussions:

  • Match the SRID – in StoreFront, if you utilise the same Base of operations URL in the 2 separate installations, then the SRID should end upward being identical. If the Base URL is inverse after the initial setup, the SRID doesn't change. The SRID tin be safely edited in the \inetpub\wwwroot\Citrix\Roaming\web.config file. It will be replicated into the discovery servicerecord entry in the Store spider web.config, which can exist edited likewise, or refreshed from the admin console by going into Remote Access setup for the shop, and hitting OK. Make sure to propagate changes to other servers in the grouping.
  • Lucifer the Base URL
  • Match the Delivery Controller names nether "Manage Delivery Controllers" – The XML brokers tin be different, only the actual name of the Delivery Controller/Farms must be identical.

Typical Multi-Datacenter Configuration

Here'due south a typical active/active Citrix Virtual Apps and Desktops configuration using separate sites/farms in each datacenter. Some other option is zones.

  • Citrix Virtual Apps and Desktops Sites/Farms: Carve up 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 ordinarily 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 split up sites/farms is that you lot 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 Grouping is configured identically. You can export the config from one Server Grouping, 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, aforementioned Gateways, and same Beacons.
    • If subscriptions/favorites are enabled, use PowerShell commands to configure subscription replication between the ii Server Groups.
  • StoreFront Load Balancing: Carve up StoreFront load balancing VIP in each datacenter
    • Each Load Balancing VIP can exist active/passive. Agile = the StoreFront servers in the local datacenter. Passive = the StoreFront servers in the remote datacenter.
      • Create two Load Balancing vServers: 1 for local StoreFront, one for remote StoreFront. In the Active (local) Load Balancing vServer, add the Protection section, and configure the Fill-in (remote) vServer.
      • When the active StoreFront is down, Citrix Gateway volition use StoreFront in the remote datacenter. However, the remote datacenter has its ain Citrix Gateway, thus in that location will exist two unlike Citrix Gateways connecting to ane StoreFront Server Group. If you use SmartAccess or SAML and need the Callback URL, and so 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 2 farms.
    • Apply Advert groups to specify a user's home datacenter, which contains the user's roaming profile and dwelling directory.
    • Configure farm priority based on Ad groups. For an aggregated icon, the Advertisement 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 proper noun is agile/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, andcitrix-b.company.com
    • The Gateway SSL certificate needs to match all three DNS names: the chief agile/active DNS name, and the two datacenter-specific agile/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 Unmarried 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 divide 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 exist valid for both internal and external. If this is not the case, then you can deploy dissever StoreFront servers for internal and external.
    • DNS:
      • The main Citrix Gateway DNS proper noun is active/agile GSLB. For example: citrix.visitor.com.
      • Each datacenter has a datacenter-specific GSLB active/passive DNS name for Citrix Gateway. For example: citrix-a.visitor.com, andcitrix-b.company.com
      • The Gateway SSL document needs to lucifer 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.visitor.com resolves to a Citrix Gateway VIP.
    • Internally,storefront.company.com resolves to a StoreFront Load balancing VIP.
    • Single FQDN unremarkably causes more than issues than it's worth. If y'all don't do Single FQDN, and so you tin hide the StoreFront DNS name by pushing the store configuration to Receiver using Group Policy. Browser users would merely need to know the Citrix Gateway DNS proper noun.
  • 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 resolvecitrix.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 past DMZ Citrix ADC appliances. Internal GSLB should be handled past Internal Citrix ADC appliances.
    • If you only have 1 Citrix ADC apparatus for both internal and public, then see Ane appliance resolving a single DNS name differently for internal and public at GSLB Planning.
    • citrix.visitor.com is configured as Active/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
    • citrix-a.visitor.com is configured as Agile/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.visitor.com is configured equally Agile/Active GSLB with Proximity Load Balancing, and Site Persistence equal or greater than StoreFront RfWeb timeout.
  • HDX Optimal Routing: Utilize HDX Optimal Routing to route ICA traffic through the Citrix Gateway that is closest to the destination subcontract. This requires datacenter-specific DNS names (due east.thousand. citrix-a.visitor.com, citrix-b.company.com)
    • Y'all tin can use i of these DNS names to connect to StoreFront in a specific datacenter, which is helpful for testing.
  • STAs: each StoreFront Server Grouping uses STAs in the local datacenter. Since ICA Traffic could terminate up on either Citrix ADC, all STAs must be added to all Citrix Gateways.
  • Beacons: the internal buoy is disquisitional. If the internal beacon is downwards then Receiver Self-service won't be able to determine if the customer device is internal or non. GSLB tin can be used for the internal beacon DNS proper noun.
  • Roaming Profiles: If yous are running Citrix Virtual Apps and Desktops in multiple datacenters, you must blueprint roaming profiles and domicile directories correctly.

Icon Aggregation and Home Sites

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

  • New-STFEquivalentFarmset
  • Add together-STFUserFarmMapping

To configure icon aggregation using the StoreFront Panel:

  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 information technology.
  5. If you are publishing identical resources from multiple farms, click the link to Aggregate resources.
  6. In theAggregate Resource dialog box, practice the following:
    1. Select the farms with identical resources that you lot desire to aggregate.
    2. Notice the checkboxes on the bottom. If your goal is to configure abode sites, then make certain y'all uncheckLoad remainder resources across controllers.
    3. Click theAggregate button to motion them upwardly to theAggregated department.
    4. Note: if yous have existing subscriptions/favorites, and so enabling icon assemblage volition cause the existing subscriptions to be ignored. Yous tin drift 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 Assemblage window, click Map users to controllers.
  8. In theCreate User Mapping wizard, do the following:
    1. If yous want the aforementioned farm failover social club (active/passive) or subcontract load balancing settings for everyone, then leave the User Groups page set to Anybody. Or if you intend to have unlike home sites for different users, add a user group that contains the users that will exist homed to a particular datacenter. You can run this wizard multiple times to specify different home sites for different user groups. Click Adjacent.
    2. In the Controllers page, click Add together.
    3. Select the farms that these users volition take access to, and click OK.
    4. If you configured farm assemblage without load balancing, then utilise the upwards and downward pointer buttons to put the active site/subcontract for this grouping of users on top. The lower priority sites will only be accessed if the primary site is down. You can run this sorcerer multiple times to specify unlike agile sites for different users.
    5. If farm aggregation is configured for load balancing, and so in that location are no arrows to prioritize the farms.
    6. Click Create.
  9. You can click Add to add together more than user mappings. If you lot add multiple user groups, you can assign different chief sites/farms to each Agile Directory group. This is how you configure "abode 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 utilize the Main and Secondary keywords to override farm priority gild.

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

HDX Optimal Routing

The Optimal Gateway feature lets yous control the Citrix Gateway used for ICA connections. Hither 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, so you probably want the ICA connection to become through a Citrix Gateway Virtual Server in Datacenter A.
    • If the main DNS name for accessing Citrix Gateway is GSLB load balanced across datacenters, and so y'all need additional datacenter-specific DNS names then 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 get through Citrix Gateway and so AppFlow data can be sent to Citrix Awarding Delivery Direction (ADM), then y'all can do that using HDX Optimal Gateway, even if the user originally connected straight to the StoreFront server. See CTX200129 How to Forcefulness 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.k. Smart Card), then each session launch will result in a Pin prompt. To prevent these extra prompts, build a carve up 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. Notation: SmartAccess Callback URL as well 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 also.

HDX Optimal Gateway tin can be configured in the StoreFront Panel:

  1. Right-click theStores node, and click Manage Citrix Gateways.
  2. Add more Citrix Gateways: i for each datacenter.
  3. When adding a Gateway, yous can designate a Usage or role.
    1. The Gateway accessed through the active/active GSLB DNS name must be set up to Hallmark and HDX routing.
    2. The Gateways for Optimal Routing could be set to HDX routing only. Or if examination users volition apply these datacenter-specific DNS names to connect to Gateways in specific datacenters, leave them set toAuthentication and HDX routing. There'southward no damage in leaving all of the Gateways gear up 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 i of the datacenter-specific Gateways, and click Manage Delivery Controllers.
  7. Select the farms that should use this gateway, and click OK.
  8. Echo for the other datacenter-specific Gateways.
  9. The Gateway for the active/agile GSLB-enabled DNS name doesn't need any farms associated with it.
  10. If you desire to use Citrix Gateway internally for AppFlow reporting, and 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, yous 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 agile/agile GSLB-enabled Gateway and login. Later clicking an icon, HDX will be routed through i of the datacenter-specific Gateways based on the farm the icon was launched from.

Multiple Gateways (GSLB) to One StoreFront Server Grouping

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 become to the aforementioned Citrix ADC appliance that authenticated the user. If you take 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, then it tin can perform a callback to that particular appliance pair.

If each of the Citrix Gateways uses the same DNS name (e.g. GSLB), then yous tin't use the DNS name to distinguish one appliance from the other. Instead, StoreFront tin 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 proper noun must friction 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 document that matches both the GSLB name, and the datacenter-specific callback name.
    • On the master Citrix Gateway Virtual Server, assign an SSL certificate with Subject Alternative Names for both the GSLB proper noun, 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 panel, create multiple Citrix Gateway appliances, ane for each datacenter.
  4. Requite each of the gateway objects unique Display names. Y'all can't accept two Gateway objects with the same brandish name.
  5. Enter the same Citrix Gateway URL in all of the gateway appliances.

  6. In the Authentication Settings folio, in the VServer IP accost field, enter the Gateway VIP for this particular apparatus pair. StoreFront will apply 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 10-Citrix-Via-VIP. StoreFront reads this VIP header, and compares it to the Gateway objects bound to the Store. If in that location's a match, StoreFront uses the Callback URL configured for that Gateway object.
  7. The callback URL must be unique for each Citrix ADC apparatus pair (e.g. callback-a.corp.com). The callback URL must resolve to a Citrix Gateway VIP on the same apparatus pair that authenticated the user.

  8. When enabling Remote Access on the shop, select both Gateway appliances. Select one equally the default appliance. It shouldn't matter which one is default.

Related Pages

  • Back to StoreFront 2203 LTSR through 3.5
  • Citrix Gateway 12.1 / NetScaler Gateway 12.0
  • Citrix Gateway thirteen.10

barnettwituare.blogspot.com

Source: https://www.carlstalhood.com/storefront-cr-configuration-for-citrix-gateway/comment-page-1/

0 Response to "Citrix Cannot Connect to Server Try Connecting Again in a Few Minutes"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel