When you initially deployed a Horizon Cloud pod into Microsoft Azure no gateway, or with only one type of gateway, you can later add a gateway configuration to the pod using the Edit Pod workflow. You launch that workflow from the pod's details page.

Tip: The Administration Console is dynamic. It will only make available in the user interface those workflows and toggles and fields that make sense and are appropriate based on the pod's current configuration.

As described in Introduction to Horizon Cloud Pods in Microsoft Azure, a pod can have an external gateway configuration or an internal one or both. You can use this workflow to add the type that the pod does not already have. At the same time that you edit the pod to add a gateway configuration, you can also specify two-factor authentication settings for that gateway.

Important: When modifying the pod using these steps, keep in mind the following points:
  • Keep in mind that the IP setting for an external gateway's load balancer cannot be changed after the external gateway configuration is originally set. When you add an external gateway configuration, you have the option to have it use a private IP address for the gateway's load balancer instead of a public one. The default is to use a public IP.
  • During the time the system is changing the pod's configuration until it is finished, the following limitations apply:
    • You cannot perform administration tasks on the pod.
    • End users who do not have connected sessions to their desktops or remote applications served by the pod and who attempt to connect cannot do so.
    • End users who have connected sessions served by the pod will have those active sessions disconnected. No data loss will occur. After the configuration changes are complete, those users can reconnect.

Prerequisites

Note: If the pod has high availability enabled and one of the pod manager VMs is offline, the system prevents adding a gateway to the pod. The message will appear after you click Save & Exit. You must bring the offline pod manager VM back online using the Microsoft Azure portal before you can add the gateway.

When adding a gateway configuration to an existing pod in Microsoft Azure, to complete the fields in the Edit Pod wizard, you must provide the information as described in Prerequisites When Deploying With a Unified Access Gateway Configuration. If you are also specifying two-factor authentication settings at the same time that you're adding the gateway, you must provide the information described in Prerequisites When Deploying With a Two-Factor Authentication Configuration.

Important: All certificates in the certificate chain must have valid time frames. The Unified Access Gateway VMs require that all of the certificates in the chain, including any intermediate certificates, have valid time frames. If any certificate in the chain is expired, unexpected failures can occur later as the certificate is uploaded to the Unified Access Gateway configuration.

Procedure

  1. In the Administration Console, navigate to Settings > Capacity and click the pod's name to open its details page.
  2. In the pod's details page, click Edit.
  3. In the Edit Pod window, click Next to move to the Gateway Settings step.
    This step has a section for the external gateway configuration and a section for the internal gateway configuration. The user interface reflects the pod's current configuration and the gateway settings it already has.
  4. To add an external gateway, switch on the Enable External UAG? toggle and complete the fields in the External UAG section.
    Option Description
    Enable External UAG? Controls whether the pod has an external gateway configuration. The external configuration allows access to desktops and applications for users located outside of your corporate network. The pod includes an Azure load balancer resource and Unified Access Gateway instances to provide this access.
    Note: Leaving the default enabled setting is recommended.

    When this toggle is switched off, clients must either connect directly to the pod and not through Unified Access Gateway, or they connect through an internal gateway configuration. In the case of clients connecting directly to the pod and not through Unified Access Gateway, some post-deployment steps are required. In this case, after the pod is deployed, follow the steps in Upload SSL Certificates to a Horizon Cloud Pod for Direct Connections.

    FQDN Enter the required fully qualified domain name (FQDN), such as ourOrg.example.com, which your end users will use to access the service. You must own that domain name and have a certificate in PEM format that can validate that FQDN.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
    DMZ Subnet

    DMZ Subnet (CIDR)

    When Use Existing Subnet is enabled in the preceding wizard step, DMZ Subnet lists the subnets available on the VNet selected for Virtual Network. Select the existing subnet that you want to use for the pod's DMZ subnet.
    Important: Select an empty subnet, one that has no other resources attached to it. If the subnet is not empty, unexpected results might occur during the deployment process or pod operations.

    When Use Existing Subnet is disabled in the preceding wizard step, enter the subnet (in CIDR notation) for the DMZ (demilitarized zone) network that will be configured to connect the Unified Access Gateway instances to the deployed public load balancer.

    DNS Addresses Optionally enter addresses for additional DNS servers that Unified Access Gateway can use for name resolution, separated by commas. When configuring this external Unified Access Gateway configuration to use two-factor authentication with your on-premises RADIUS server, you would specify the address of a DNS server that can resolve the name of your on-premises RADIUS server.

    As described in the deployment prerequisites, a DNS server must be set up internally in your subscription and configured to provide external name resolution. The Unified Access Gateway instances use that DNS server by default. If you specify addresses in this field, the deployed Unified Access Gateway instances use the addresses in addition to the prerequisite DNS server that you configured in your subscription's virtual network.

    Routes Optionally specify custom routes to additional gateways that you want the deployed Unified Access Gateway instances to use to resolve network routing for the end user access. The specified routes are used to allow Unified Access Gateway to resolve network routing such as to RADIUS servers for two-factor authentication.

    When configuring this pod to use two-factor authentication with an on-premises RADIUS server, you must enter the correct route the Unified Access Gateway instances can use to reach the RADIUS server. For example, if your on-premises RADIUS server uses 10.10.60.20 as its IP address, you would enter 10.10.60.0/24 and your default route gateway address as a custom route. You obtain your default route gateway address from the Express Route or VPN configuration you are using for this environment.

    Specify the custom routes as a comma-separated list in the form ipv4-network-address/bits ipv4-gateway-address, for example: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Certificate Upload the certificate in PEM format that Unified Access Gateway will use to allow clients to trust connections to the Unified Access Gateway instances running in Microsoft Azure. The certificate must be based on the FQDN you entered and be signed by a trusted CA. The PEM file must contain the entire certificate chain and the private key: SSL certificate intermediate certificates, root CA certificate, private key.
    Enable Public IP? Controls whether this gateway's load balancing type is configured as private or public. If switched on, the deployed Azure load balancer resource is configured with a public IP address. If switched off, the Azure load balancer resource is configured with a private IP address.
    Important: In this release, you cannot later change the external gateway's load balancing type from public to private, or from private to public. The only way to make that change would be to delete the gateway configuration entirely from the deployed pod and then edit the pod to add it back with the opposite setting.
  5. To add an internal gateway, switch on the Enable Internal UAG? toggle and complete the fields in the Internal UAG section.
    Option Description
    Enable Internal UAG? Controls whether the pod has an internal gateway configuration. The internal configuration provides trusted access to desktops and applications for HTML Access (Blast) connections for users located inside of your corporate network. The pod includes an Azure load balancer resource and Unified Access Gateway instances to provide this access. By default, this gateway's load balancing type is private. The load balancer is configured with a private IP address.
    FQDN Enter the required fully qualified domain name (FQDN), such as ourOrg.example.com, which your end users will use to access the service. You must own that domain name and have a certificate in PEM format that can validate that FQDN.
    Important: This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.
    DNS Addresses Optionally enter addresses for additional DNS servers that Unified Access Gateway can use for name resolution, separated by commas. When configuring this internal Unified Access Gateway configuration to use two-factor authentication with your on-premises RADIUS server, you would specify the address of a DNS server that can resolve the name of your on-premises RADIUS server.

    As described in the deployment prerequisites, a DNS server must be set up internally in your subscription and configured to provide name resolution. The Unified Access Gateway instances use that DNS server by default. If you specify addresses in this field, the deployed Unified Access Gateway instances use the addresses in addition to the prerequisite DNS server that you configured in your subscription's virtual network.

    Routes Optionally specify custom routes to additional gateways that you want the deployed Unified Access Gateway instances to use to resolve network routing for the end user access. The specified routes are used to allow Unified Access Gateway to resolve network routing such as to RADIUS servers for two-factor authentication.

    When configuring this pod to use two-factor authentication with an on-premises RADIUS server, you must enter the correct route the Unified Access Gateway instances can use to reach the RADIUS server. For example, if your on-premises RADIUS server uses 10.10.60.20 as its IP address, you would enter 10.10.60.0/24 and your default route gateway address as a custom route. You obtain your default route gateway address from the Express Route or VPN configuration you are using for this environment.

    Specify the custom routes as a comma-separated list in the form ipv4-network-address/bits ipv4-gateway-address, for example: 192.168.1.0/24 192.168.0.1, 192.168.2.0/24 192.168.0.2.

    Certificate Upload the certificate in PEM format that Unified Access Gateway will use to allow clients to trust connections to the Unified Access Gateway instances running in Microsoft Azure. The certificate must be based on the FQDN you entered and be signed by a trusted CA. The PEM file must contain the entire certificate chain and the private key: SSL certificate intermediate certificates, root CA certificate, private key.
  6. In the section for whichever gateway you are adding, if you want to optionally configure the end users' desktops to use RADIUS two-factor authentication, follow the steps in Enable Two-Factor Authentication on a Horizon Cloud Pod's Gateways.
  7. Click Save & Exit.
    A confirmation message appears asking you to confirm the start of the workflow.
  8. Click Yes to start the workflow.

Results

Until the system is finished deploying the elements for the gateway, the pod summary page's section for that configuration type shows Pending status.

When the workflow is completed, the status will show as Ready and the load balancer FQDN will be displayed in the page.

Note: When running this workflow for a pod in Microsoft Azure China, the process can take longer than an hour to complete. The process is subject to geographic network issues that can cause slow download speeds as the binaries are downloaded from the cloud control plane.

What to do next

Important: Before your end users can start using the newly added gateway, you must complete the following tasks.
  • For the newly added gateway configuration, ensure you have a CNAME record in your DNS server to map the configuration's deployed load balancer to the FQDN that you entered in the deployment wizard. See Obtain the Pod Gateway's Load Balancer Information to Map in your DNS Server for details.
  • If you specified RADIUS two-factor authentication for the added gateway, you must do these tasks:
    • If you configured an external gateway with RADIUS settings and that RADIUS server is not reachable within the same VNet as used by the pod, configure that RADIUS server to allow client connections from the IP address of the external gateway's load balancer. In an external gateway configuration, the Unified Access Gateway instances attempt contact with the the RADIUS server using that load balancer address. To allow the connections, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client in your RADIUS server configuration.
    • If you configured an internal gateway, or an external gateway and your RADIUS server is reachable within the same VNet as used by the pod, configure the RADIUS server to allow connections from the appropriate NICs that were created in the gateway's resource group in Microsoft Azure that must communicate with the RADIUS server. Your network administrator determines the RADIUS server's network visibility to the pod's Azure Virtual Network and subnets. Your RADIUS server must allow client connections from the IP addresses of those gateway NICs that correspond to the subnet for which your network administrator has given network visibility to the RADIUS server. The gateway's resource group in Microsoft Azure has four NICs that correspond to that subnet, two that are currently active for the two Unified Access Gateway instances and two that are idle and will become the active ones after the pod goes through an upgrade. To support connectivity between the gateway and the RADIUS server both for ongoing pod operations and after each pod upgrade, ensure the IP addresses of those four NICs are specified as clients in the RADIUS server configuration.

    For information on how to obtain those IP addresses, see Update Your RADIUS System with the Required Horizon Cloud Pod Gateway Information.