StoreFront

Configure two URLs for the same NetScaler Gateway

October 25, 2018

Contributed by:

In StoreFront, you can add a single NetScaler Gateway URL from the StoreFront management console in Manage NetScaler Gateways > Add or Edit. It is also possible to add both a public NetScaler Gateway URL and a GSLB (Global Server Load Balancing) URL in Manage NetScaler Gateways > imported from file.

This article shows you how to use PowerShell cmdlets and the StoreFront PowerShell SDK to use an optional parameter, -gslburl, to set the GslbLocation attribute of a gateway. This feature simplifies the NetScaler Gateway administration in StoreFront in the following use cases:

GSLB and multiple NetScaler Gateways. Use GSLB and multiple NetScaler Gateways to load balance remote connections to published resources in two or more locations within a large global Citrix deployment.
Single NetScaler Gateway using a public or private URL. Use the same NetScaler Gateway for external access using a public URL, and for internal access using a private URL.

This is an advanced feature. If you are new to GSLB concepts, see the Related information links at the end of this article.

This feature offers the following benefits:

Support two simultaneous URLs for a single gateway object.
Users can switch between two different URLs to access the NetScaler Gateway without the administrator reconfiguring the StoreFront gateway object to match the gateway URL the user wants to use.
Shorter setup and test times to validate the StoreFront gateway configuration when using multiple GSLB gateways.
Use the same NetScaler Gateway object in StoreFront inside the DMZ for both external and internal access.
Support both URLs for optimal gateway routing. For more information on optimal gateway routing, see Set up highly available multi-site stores.

Deployment considerations when using two Gateway URLs

Important

Before configuring a second gateway URL using the -gslburl parameter, Citrix recommends reviewing what server certificates you have in place and how your organization performs DNS resolution. Any URLs that you want to use in your NetScaler and StoreFront deployment must be present in your server certificates. For more information about server certificates, see Plan gateway and server certificate usage.

DNS

Split DNS. It is common for large enterprises to use split DNS. Split DNS involves using different namespaces and different DNS servers for public and private DNS resolution. Check if you have the existing DNS infrastructure to support this.
Single URL for external and internal access to published resources. Decide if you want to use the same URL to access published resources from both outside and inside your corporate network, or consider if two different URLs are acceptable such as example.com and example.net.

Server certificate examples

This section contains example server certificate deployments when using two Gateway URLs.

Example server certificate for a load balanced StoreFront deployment

A privately signed wildcard server certificate should contain the FQDN *.storefront.example.net.

A privately signed SAN server certificate should contain all the FQDNs needed to load balance three StoreFront servers.

loadbalancer.storefront.example.net

server1.storefront.example.net

server2.storefront.example.net

server3.storefront.example.net

Set the host base URL of the Storefront server group to be the shared FQDN, which resolves to the load balancer IP address.

loadbalancer.storefront.example.net

Example server certificate for a group of XenApp and XenDesktop 7.x Delivery Controllers

A privately signed wildcard server certificate should contain the FQDN *.xendesktop.example.net.

A privately signed SAN server certificate should contain all the server FQDNs needed for a XenDesktop site containing four Controllers.

XD1A. xendesktop.example.net

XD1B. xendesktop.example.net

XD2A. xendesktop.example.net

XD2B. xendesktop.example.net

Example server certificate for a NetScaler Gateway which is accessed both externally and internally using split DNS

A publically signed SAN server certificate for both external and internal access should contain both the external and internal FQDNs.

gateway.example.com

gateway.example.net

Example server certificate for all GSLB Gateways which are accessed externally

A publically signed SAN server certificate for external access through GSLB should contain the FQDNs.

gslbdomain.example.com

emeagateway.example.com

usgateway.example.com

apacgateway.example.com

This allows the user to access the closest gateway using GSLB or to pick a gateway in the location of their choice using its unique FQDN.

Use Case #1: GSLB and multiple NetScaler Gateways

The administrator uses GSLB and multiple NetScaler Gateways to load balance remote connections to published resources in two or more locations within a large global Citrix deployment.

localized image

In this example:

Each location or data center contains at least one gateway, one or more StoreFront servers, and one or more XenApp and XenDesktop Controllers to provide published resources for that location.
Each GSLB service configured on the GSLB NetScalers within the global deployment represents a gateway VPN vServer. All of the StoreFront servers in the deployment must be configured to contain all of the NetScaler Gateway vServers that make up the GSLB layer.
The GSLB NetScaler Gateways are used in active/active mode but can also provide failover if the network connection, DNS, gateway, StoreFront server or XenApp and XenDesktop Controllers at one location fail. Users are automatically directed to another gateway if a GSLB service is unavailable.
External clients are directed to the closest gateway based on the configured GSLB load balancing algorithm such as round trip time (RTT) or Static Proximity when making remote connections.
The unique URL for each gateway allows users to manually select which data center they want to launch resources from by choosing the location-specific URL for the gateway they want to use.
GSLB can be bypassed when GSLB or a DNS delegation is not working as expected. Users can continue to access remote resources at any data center using its location-specific URL until any GSLB related issues are resolved.

Use Case #2: Single NetScaler Gateway using a public or private URL

The administrator uses the same NetScaler Gateway for both external access using a public URL, and also internally using a private URL.

localized image

In this example:

The administrator wants all access to published resources and HDX launch traffic to pass through a NetScaler Gateway even if the client is internal.
The NetScaler is located in a DMZ.
There are two different network routes to the NetScaler Gateway through the two firewalls on either side of the DMZ.
The public-facing, external namespace is different from the internal namespace.

PowerShell cmdlet examples

Use the PowerShell cmdlets Add-STFRoamingGateway and Set-STFRoamingGateway with the parameter, -gslburl, to set the GslbLocation attribute on the StoreFront gateway object. For example:

Add-STFRoamingGateway -Name "EMEAGateway" -GatewayUrl "https://emeagateway.example.com" -GSLBurl "https://gslb.example.com" -SubnetIPAddress "10.0.0.1" -CallbackUrl "https://emeagateway.example.com" -LogonType "DomainAndRSA" -SmartCardFallbackLogonType "None" -Version "Version10_0_69_4" -SecureTicketAuthorityUrls "https://emea-controller.example.com/scripts/ctxsta.dll,https://us-controller.example.com/scripts/ctxsta.dll,https://apac-controller.example.com/scripts/ctxsta.dll"
Set-STFRoamingGateway -Name "EMEAGateway" -GatewayUrl "https://emeagateway.example.com" -GSLBurl "https://gslb.example.com"
Get-STFRoamingGateway -Name "EMEAGateway" (returns just the EMEA gateway object)
Or
Get-STFRoamingGateway (returns all gateway object configured in StoreFront)

For use case #1, you can remove the GSLBurl from the “EMEAGateway” by setting its GslbLocation to NULL. The following PowerShell modifies the gateway object $EMEAGateway stored in memory. Set-STFRoamingGatway can then be passed $EMEAGateway to update the StoreFront config and remove the GSLBurl.

$EMEAGateway = Get-STFRoamingGateway

$EMEAGateway.GslbLocation = $Null

Set-STFRoamingGateway -Gateway $EMEAGateway

For use case #1, the following gateways are returned using Get-STFRoamingGateway:

Name: EMEAGateway
 Location: https://emeagateway.example.com/ (Unique URL for the EMEA Gateway)

GslbLocation: https://gslb.example.com/ (GSLB URL for all three gateways)
 
Name: USGateway
 Location: https://USgateway.example.com/ (Unique URL for the US Gateway)

GslbLocation: https://gslb.example.com/ (GSLB URL for all three gateways)
 
Name: APACGateway
 Location: https://APACgateway.example.com/ (Unique URL for the APAC Gateway)

GslbLocation:  https://gslb.example.com/ (GSLB URL for all three gateways)

For use case #2: the following gateways are returned using Get-STFRoamingGateway:

Name: EMEAGateway
 Location: https://emeagateway.example.com/ (Public URL for the Gateway)

GslbLocation: https://emeagateway.example.net/ (Private URL for the Gateway)

For use case #1, Optimal Gateway Routing is returned using Get-STFStoreRegisteredOptimalLaunchGateway:

$StoreObject = Get-STFStoreService -SiteId 1 -VirtualPath "/Citrix/<YourStore>"

Get-STFStoreRegisteredOptimalLaunchGateway -StoreService $StoreObject
 
Hostnames:       {emeagateway.example.com, gslb.example.com}
Hostnames:       {usgateway.example.com, gslb.example.com}
Hostnames:       {apacgateway.example.com, gslb.example.com}

GSLB URL or Internal URL for each Gateway is stored in the Roaming service web.config file

StoreFront does not display the GSLB URL or internal URL for each Gateway within the StoreFront management console, however it is possible to view the configured GSLBLocation path for all GSLB gateways by opening the roaming service Web.Config file location in C:\inetpub\wwwroot\Citrix\Roaming\web.config on the StoreFront server.

Use Case #1 Gateways in Roaming web.config file

Use Case #2: Gateways in Roaming web.config file

The official version of this content is in English. Some of the Citrix documentation content is machine translated for your convenience only. Citrix has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Citrix product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Citrix, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Citrix will not be held responsible for any damage or issues that may arise from using machine-translated content.

Configure two URLs for the same NetScaler Gateway

October 25, 2018

Contributed by:

October 25, 2018

Contributed by:

Configure two URLs for the same NetScaler Gateway

Deployment considerations when using two Gateway URLs

Use Case #1: GSLB and multiple NetScaler Gateways

Use Case #2: Single NetScaler Gateway using a public or private URL

PowerShell cmdlet examples

In this article