When a deployed Horizon Cloud pod in Microsoft Azure has a gateway configuration, you must create a CNAME record in your DNS server that maps the fully qualified domain name (FQDN) that the service configured on that gateway configuration to the pod gateway's deployed Azure load balancer information. You can obtain the Azure load balancer information from the pod's details page in the Horizon Universal Console, or console for short.
This CNAME mapping supports the name resolution needed by the Horizon Clients and Horizon HTML Access (the web client) and their connections to reach the end user's entitled pod-provisioned resources. The pieces of information you need for this mapping are displayed in the pod's details page, to which you can navigate using the console's Capacity page.
When the appropriate mappings are set, the Horizon Clients and the web client can successfully resolve the domain names at the times the clients need to resolve those names to connect to the end user's entitled, pod-provisioned resources.
- In an environment configured with Universal Broker, an end user uses your Universal Broker brokering FQDN in their client — as a server address in the Horizon Client or in the web client. The client then connects to the Universal Broker for authentication and to obtain that end user's entitlements. Then in the authenticated client, when the user clicks a specific entitled desktop or remote app to access it, the client is directed to the FQDN that the service configured in the pod's gateway configuration, the FQDN you specified in the pod deployment wizard or gateway deployment wizard.
- In an environment configured with single-pod brokering, for the server addresses in their Horizon Clients or in the web client, an end user uses the FQDN that you specified in the pod deployment wizard for the pod's gateway. This FQDN is the one that the Horizon Clients and Horizon HTML Access (the web client) will use to access the entitled virtual desktops and remote apps from the pod. The client connects to that specific gateway and pod for authentication, to obtain that end user's entitlements, and to access an entitled desktop or remote app.
When the service's deployer code configures the gateway configuration, it uses the fully-qualified domain name (FQDN) that was specified in the gateway configuration fields in the wizard, for example, ourOrg.example.com or ourApps.ourOrg.example.com. When the gateway configuration is an external gateway configuration, that FQDN must be a publicly resolvable FQDN. The Horizon Cloud control plane stores the information about the FQDN that was entered for the external gateway deployment and communicates with that FQDN over the Internet. As a result, the Horizon Cloud control plane must be able to resolve that name and connect to that address. This requirement is especially important to meet when your tenant environment is configured with Universal Broker. In such environments, the Horizon Cloud control plane must connect to that FQDN to fetch authentication information from the Unified Access Gateway instances in that external gateway configuration. The service uses this information to validate that the two-factor authentication settings configured on the gateway configuration's Unified Access Gateway instances match those of the Universal Broker configuration and of all other Unified Access Gateway instances within participating pods.
- External gateway configuration deployed with the Enable Public IP toggle switched on (the default)
-
When your pod deployment wizard or external gateway deployment wizard specified enabling a public IP address for the external gateway configuration, the service configures the deployed
Unified Access Gateway instances with an Azure load balancer resource that has a public IP address and an auto-generated public FQDN. The form of the auto-generated public FQDN is in the pattern
vmw-hcs-ID-uag.region.cloudapp.azure.com, wherevmw-hcs-IDmatches the pattern within the name of the resource group in which the Unified Access Gateway instances reside, and region is the Microsoft Azure region where the pod is located. For this type of deployment, in your DNS server, you map the FQDN that you entered in the deployment wizard to that auto-generated public FQDN. - External gateway configuration deployed with the Enable Public IP toggle deactivated, switched off
- This scenario of deploying the pod's external gateway configuration with a private load balancer IP address is used when you have a firewall or NAT configured in front of the external gateway configuration's Azure load balancer for the purpose of controlling Internet-based traffic prior to allowing access to the external gateway configuration's Unified Access Gateway appliances. When your pod deployment wizard or external gateway deployment wizard had the Enable Public IP toggle switched off, the service configures the deployed Unified Access Gateway instances with an Azure load balancer resource that has a private IP address. In your DNS server, you map the FQDN that you entered in the deployment wizard to the gateway's Azure internal load balancer resource's private IP address. In addition to that CNAME mapping in your DNS server, you must ensure that your firewall or NAT setup provides for a public IP address and the same FQDN is publicly resolvable to that public IP address that is provided by that firewall or NAT.
- Internal gateway configuration
- For an internal gateway deployment , the service configures the deployed Unified Access Gateway instances with an Azure load balancer resource that has a private IP address. Your DNS server would map the FQDN that was specified in the pod deployment wizard or internal gateway deployment wizard for the internal gateway configuration to the deployed Azure load balancer's private IP address.
The pod's details page lists the information you need for this mapping. Use these steps to locate the appropriate information in the pod's details page.
Prerequisites
The pod must be successfully deployed into your Microsoft Azure environment, according to the pod deployment steps covered in Perform an Automated Deployment of a Pod into Microsoft Azure.
Procedure
- On the Summary tab, scroll down towards the bottom of the page and locate the sections labeled Internal UAG and External UAG.
Note: The page includes a section only when the pod has the corresponding gateway configured. If the pod only has an internal gateway, then only the Internal UAG section appears and not the section for the external one. If the pod has both configurations, then both sections appear in the page.
The following screenshot shows the portion of the page for a pod that has both types of configurations, internal and external.
