StoreFront 3.5 Configuration for NetScaler Gateway

Navigation

Contained on this page are the following topics:

• StoreFront Configuration for NetScaler Gateway
• Single FQDN for internal and external
• Multiple Datacenters
• Optimal Gateway
• Multiple Gateways Connecting to One StoreFront

StoreFront Config for Gateway

1. See the NetScaler 10.5 page or NetScaler 11 page for instructions on configuring NetScaler Gateway for StoreFront.
2. In the StoreFront Console, right-click the Store and click Manage Authentication Methods.
   
3. Ensure Pass-through from NetScaler Gateway is selected and click OK.
   
4. If you need the SmartAccess feature, then you need to configure StoreFront to perform an authentication callback to a NetScaler Gateway Virtual Server on the same appliance that authenticated the user.
   1. If you need SmartAccess and are doing Single FQDN then the Callback FQDN must be different than the Single FQDN.
   2. If you need SmartAccess and are doing different FQDNs for Gateway and StoreFront, then the Callback FQDN is usually the same as the Gateway FQDN.
   3. Make sure the StoreFront server can resolve the Callback FQDN to a Gateway VIP (with matching certificate). One option is to edit the C:\Windows\System32\drivers\etc\hosts file and add an entry for the Callback FQDN.
      
   4. After configuring the HOSTS file, on the StoreFront server, open a browser and navigate to the DNS name. Make sure the Gateway vServer logon page appears.
5. In the StoreFront Console, right-click Stores and click Manage NetScaler Gateways.
   
6. Click Add.
   
7. In the General Settings page, enter a display name. This name appears in Citrix Receiver so make it descriptive.
8. Enter the NetScaler Gateway Public URL. This can be a GSLB-enabled DNS name. Click Next.
   
   
9. In the Secure Ticket Authority page, click Add.
   
10. Enter the URL to a XenDesktop Controller. This can be http or https.
    
11. Continue adding Secure Ticket Authorities (XenDesktop Controllers). Whatever Secure Ticket Authorities you add here must also be added to the NetScaler Gateway Virtual Server on the NetScaler appliance. Click Next.
    
12. In the Authentication Settings page, if you have multiple Gateways (on separate appliance pairs) connecting to one StoreFront server then then you’ll need to enter the vServer IP address (VIP) of the NetScaler Gateway Virtual Server so StoreFront can differentiate one NetScaler Gateway from another. If there’s only one Gateway communicating with this StoreFront server group, then leave the VServer IP address field empty.
13. If you need SmartAccess, then enter the Callback URL.
    • The Callback URL must resolve to any NetScaler Gateway VIP on the same appliance that authenticated the user. For multi-datacenter, edit the HOSTS file on the StoreFront server so it resolves to NetScaler appliances in the same datacenter.
    • The Callback URL Gateway Virtual Server must have a trusted and valid (matches the FQDN) certificate.
    • The Callback URL Gateway Virtual Server must not have client certificates set to Mandatory.
14. If you don’t need SmartAccess then leave the Callback URL field empty.
    
15. If you enabled two-factor authentication (LDAP and RADIUS) on your NetScaler, change the Logon type to Domain and security token. Otherwise leave it set to Domain only.
    
16. Click Create.
17. Then click Finish.
    
18. Right-click a store and click Configure Remote Access Settings.
    
19. Check the box next to Enable Remote Access.
20. Leave it set to No VPN tunnel.
    • Note: if you want Receiver to automatically launch a VPN tunnel, then see CTX200664 How to Configure Receiver for Seamless Experience Through NetScaler Gateway.
21. Check the box next to the NetScaler Gateway object you just created and then click OK.
    
22. Then in the StoreFront console, right-click Server Group and click Propagate Changes.
    

Single FQDN

Docs.citrix.com – Create a single Fully Qualified Domain Name (FQDN) to access a store internally and externally

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

Single FQDN has the following requirements:

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

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

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

1. Internal DNS name = the Single FQDN (e.g. storefront.corp.com). Resolves to internal Load Balancing VIP for StoreFront. Set the StoreFront Base URL to this address.
   
2. External DNS name = the Single FQDN (e.g. storefront.corp.com). Resolves to public IP, which is NAT’d to NetScaler Gateway VIP on DMZ NetScaler. Set the NetScaler Gateway object in StoreFront to this FQDN.
   
3. If you need SmartAccess, then the Callback URL = any DNS name (e.g. callback.corp.com) that resolves to a NetScaler Gateway VIP on the same DMZ NetScaler appliance that authenticated the user.
   
   • Callback is optional if you don’t need SmartAccess features.
   • The callback DNS name must be different than the Single FQDN.
   • Your external NetScaler Gateway certificate could match both the Single FQDN and the Callback FQDN. Or you can create separate NetScaler Gateway Virtual Servers on the same appliance with separate certificates that match these FQDNs.
4. Internal Beacon = any internal website URL that is not externally accessible. You can’t use the Single FQDN as the Internal Beacon. Ideally, the Internal Beacon should be a new DNS name that resolves to the StoreFront Load Balancing VIP. However, this requires the StoreFront Load Balancing Virtual Server to have a certificate that matches both the Single FQDN and the Internal Beacon.
   
   • If are using Receiver for iOS internally then be aware that Receiver for iOS handles the Internal Beacon differently than Receiver for Windows. Receiver for iOS will append /Citrix/Store/discovery to the Internal Beacon and thus it only works if the Internal Beacon DNS name resolves to the StoreFront server. Since you can’t use the StoreFront Base URL as the Internal Beacon you’ll need a different DNS name that resolves to the StoreFront servers and matches the StoreFront certificate. Note: if you are not allowing internal iOS devices then this isn’t needed.
5. Make sure the DMZ NetScaler resolves the Single FQDN to the internal StoreFront Load Balancing VIP. You typically add internal DNS servers to the NetScaler. Or you can create a local Address Record for the Single FQDN.
   
6. In the NetScaler Gateway Session Profile, set the Web Interface Address and the Account Services Address to the Single FQDN.
   
7. That’s all you need to implement Single FQDN. If you made changes to an existing StoreFront deployment, then you might have to remove accounts from Receiver and re-add the account.

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

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

StoreFront Configuration:

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

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

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

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

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

Multiple Datacenters / Farms

If you have StoreFront (and NetScaler Gateway) in multiple datacenters, GSLB is typically used for the initial user connection but GSLB doesn’t provide much control over which datacenter a user initially reaches. So the ultimate datacenter routing logic must be performed by StoreFront.

StoreFront chooses datacenters at the farm level. Thus StoreFront assumes that each datacenter has a separate XenApp/XenDesktop farm.

• Citrix is beginning to add more zone-based features to support single farms stretched across datacenters, but this functionality is not yet fully realized. The current challenge with stretched farms is that SQL is in only one datacenter.

StoreFront can enumerate icons from multiple 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 datacenter (select a farm). This is typically done based on the user’s Active Directory group membership. Farms can be prioritized (active/passive). Or farms can be active/active load balanced.

After the datacenter (farm) is selected, Optimal Gateway directs the ICA connection through the NetScaler Gateway that is closest to the destination VDA. Optimal Gateway requires datacenter-specific DNS names for NetScaler Gateway.

There are two methods of configuring icon aggregation in StoreFront:

• The StoreFront Console can do simple configurations – The console supports a single aggregation group and active/passive configurations for multiple Active Directory user groups. One Active Directory user group could have Farm A as active and Farm B as passive. A different Active Directory user group could have Farm B as active and Farm A as passive. This is also known as “Home Sites”
• Complex configurations can be performed in XML files – For example, you can load balance connections across two identical farms (active/active). See Docs.citrix.com – Set up highly available multi-site store configurations

To configure icon aggregation using the StoreFront Console:

1. In StoreFront Console, go to Stores, right-click your Store and click Manage Delivery Controllers.
   
2. Add multiple farms. Typically, each datacenter is a separate farm.
   
3. After adding multiple farms, the Configure button becomes available. Click it.
   
4. If you are publishing identical resources from multiple farms, click the link to Aggregate resources.
   
5. Select the farms with identical resources and click Aggregate. Click OK when done.
   
6. Click Map users to controllers.
   
7. If you want the same farm failover (active/passive) 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.
   
8. In the Controllers page, click Add.
   
9. Select the farms that these users will have access to and click OK.
   
10. Use the up and down arrow buttons to put the active site 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. Notice there is no Load Balancing across identical farms. Click Create.
    
11. You can click Add to add more user mappings. If you add multiple user groups, you can assign different primary 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.

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

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

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

Optimal Gateway

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

• Multi-site Load Balancing. If the icon selected by the user is published from XenApp/XenDesktop in Datacenter A, then you probably want the ICA connection to go through a NetScaler Gateway Virtual Server in Datacenter A. If the main DNS name for accessing NetScaler Gateway is GSLB load balanced across datacenters, then you need additional datacenter-specific DNS names so you can control which datacenter the ICA connection goes through. Note: Optimal Gateway is applied at the farm/site level or zone level (for stretched 7.7+ farms).
• NetScaler Gateway for internal connections (AppFlow). If you want to force internal users to go through NetScaler Gateway so AppFlow data can be sent to Citrix Insight Center then you can do that using Optimal Gateway even if the user originally connected directly to the StoreFront server. See CTX200129 How to Force Connections through NetScaler Gateway Using Optimal Gateways Feature of StoreFront for more information.
• The NetScaler Gateway Virtual Server requires user certificates. If ICA traffic goes through a NetScaler Gateway Virtual Server that requires user certificates (e.g. Smart Card), then each session launch will result in a PIN prompt. To prevent these extra prompts, build a separate NetScaler Gateway Virtual Server that doesn’t have user certificates as Mandatory. Use Optimal Gateway to force ICA connections through the other NetScaler Gateway Virtual Server. Note: SmartAccess Callback URL also cannot use a NetScaler Gateway Virtual Server where client certificates are set to Mandatory so the extra NetScaler Gateway Virtual Server would be useful for that scenario too.

Optimal Gateway can be configured in the StoreFront Console:

1. Right-click Stores and click Manage NetScaler Gateways.
   
2. Add more Gateways.
   
3. When adding a Gateway, you can designate a Usage or role. The Gateway accessed through GSLB should be set to Authentication and HDX routing. The gateways for Optimal Routing should be set to HDX routing only.
   
   
4. Go to Stores, right-click a store 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 are accessible through this gateway and click OK.
   
8. Repeat for the other datacenter-specific Gateways. The Gateway for the GSLB-enabled DNS name doesn’t need any farms associated with it.
9. If you only want the Gateways to be used for external users, check the boxes for External only. Otherwise the Gateway routing will be used for both internal and external connections.
   
10. Another option for Optimal Gateway selection is zones. In XenApp/XenDesktop 7.7 and newer, you can stretch a farm across datacenters (zones) and use a different Gateway for each zone. Highlight a Gateway. Click Manage Zones and add the zone name. This assumes the zone name has also been specified in the Manage Delivery Controllers dialog box > Advanced Settings.
    
11. Click OK when done.
12. In summary, users will connect to the 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

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

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

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

1. Create datacenter-specific callback DNS names. For example: callbackprod.corp.com and callbackdr.corp.com.
2. The datacenter-specific callback DNS name must match the certificate on the NetScaler Gateway Virtual Server. Here are some options to handle the certificate requirement:
   • On the main NetScaler Gateway Virtual Server, assign a wildcard certificate that matches both the GSLB name and the datacenter-specific callback name.
   • On the main NetScaler Gateway Virtual Server, assign an SSL certificate with Subject Alternative Names for both the GSLB name and the datacenter-specific callback name.
   • Create an additional NetScaler Gateway Virtual Server on the appliance. Bind a certificate that matches the datacenter-specific name.
3. In the StoreFront console, create multiple NetScaler Gateway appliances, one for each datacenter.
   
4. Give each of the gateway objects unique names.
5. Enter the same NetScaler Gateway URL in all of the gateway appliances.
   
6. In the VServer IP address field, enter the Gateway VIP for this particular appliance pair. StoreFront will use this VIP to distinguish one NetScaler appliance from another.
7. The callback URL must be unique for each NetScaler appliance pair (e.g. callbackdr.corp.com). The callback URL must resolve to a NetScaler Gateway VIP on the same appliance pair that authenticated the user.
   
8. Configure name resolution for the datacenter-specific callback DNS names. Either edit the HOSTS file on the StoreFront servers or add DNS records to your DNS servers.
   
9. When enabling Remote Access on the store, select both Gateway appliances. Select one as the default appliance.
   

Related Pages

• Back to StoreFront 3.5
• NetScaler 11