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 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 current configuration of the pod and the configuration of your overall environment.

As described in Your Horizon Cloud on Microsoft Azure Deployments, 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.
  • When the tenant is configured to use Universal Broker and the broker settings have two-factor authentication enabled, the same two-factor authentication type must be set on the external gateways of all the pods in the fleet.
  • 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: When 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 for the Unified Access Gateway Configurations. 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. If you are adding an external gateway configuration and you want it to use its own subscription, you also need that subscription information and ensure that the VNet that you'll use for that gateway meets the VNet requirements. For those VNet requirements, see Configure the Required Virtual Network in Microsoft Azure.

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 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 Subscription step, if you are adding an external gateway configuration and want it to use a subscription separate from the pod's, enable Use a Different Subscription for External Gateway and enter the subscription information.
  4. Click Next until you reach 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.
  5. 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 Gateway? 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 a Microsoft 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 through Workspace ONE Accesswith its connector appliance integrated directly to the pod managers, or the clients connect directly to the pod managers' load balancer, or they connect through an internal gateway configuration. In the first two scenarios mentioned, of clients connecting through Workspace ONE Access integrated with the pod or connecting directly to the load balancer, some post-deployment steps will be required. In those scenarios, after the pod is deployed, upload SSL certificates to the pod manager VMs by following the steps in Configure SSL Certificates Directly on the Pod Manager VMs.

    FQDN Enter the required fully qualified domain name (FQDN), such as ourOrg.example.com, which the pod deployer will specify in the configuration for the gateway's Unified Access Gateway instances. You must own that domain name and have a certificate in PEM format that can validate that FQDN.

    Horizon Cloud expects that this FQDN specified for the external gateway configuration is publicly resolvable. If you switch off the Enable Public IP? toggle to specify an IP address from your firewall or NAT setup, then you are responsible for ensuring this FQDN is assigned to that IP address in your firewall or NAT setup. This FQDN is used for PCoIP connections to the gateway.

    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 external Unified Access Gateway configuration to use two-factor authentication with a two-factor authentication server that is located outside of the VNet topology into which the Unified Access Gateway instances are deployed, you would specify the address of a DNS server that can resolve the host name of that authentication server. As an example, when your two-factor authentication is located on-premises, enter a DNS server that can resolve the name of that authentication server.

    As described in the deployment prerequisites, the VNet topology used for the Horizon Cloud on Microsoft Azure deployment must be able to communicate with your DNS server that you want providing external name resolution during the deployment of the Unified Access Gateway instances and for their ongoing operations.

    By default, the DNS server that is configured on the VNet into which the instances are deployed is the one used.

    When you specify addresses in DNS Addresses, the deployed Unified Access Gateway instances use those addresses in addition to the DNS server information in your VNet's configuration.

    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 for communication with two-factor authentication servers.

    When configuring this pod to use two-factor authentication with an on-premises authentication server, you must enter the correct route the Unified Access Gateway instances can use to reach that server. For example, if your on-premises authentication 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 Horizon Cloud on Microsoft Azure deployment.

    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.

    Inherit Pod NTP Servers This toggle is enabled by default to have the Unified Access Gateway instances use the same NTP server that is specified for the pod manager instances. Keeping this toggle enabled is strongly recommended.

    Using the same NTP server for the pod manager instances, Unified Access Gateway instances, and your Active Directory servers is a best practice. Time skews can result when these instances use different NTP servers. Such time skews can later result in failures when the gateway attempts to authenticate end user sessions to their desktops and applications.

    When this toggle is enabled and you are deploying the external gateway into its own VNet separate from the pod's VNet, ensure the NTP servers that are specified for the pod manager instances are reachable from the virtual network you select for the external gateway deployment.

    VM Model Select a model to use for the Unified Access Gateway instances. You must ensure that the Microsoft Azure subscription you specified for this pod can provide the capacity for two VMs of the selected model.
    Important: In the current service release, the VM model used by these instances cannot be easily changed after the gateway configuration is deployed in your subscription. Changing the VM model after deployment requires deleting the gateway configuration and re-deploying it. If you anticipate your environment to scale to 2,000 sessions per pod, select F8s_v2. As stated in VMware Horizon Cloud Service on Microsoft Azure Service Limits, the A4_v2 VM model is only sufficient for proofs-of-concept (PoCs), pilots, or smaller environments where you know that you will not exceed 1,000 active sessions on the pod.
    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.
    Blast Extreme TCP Port Select the TCP port to use in the Blast Extreme TCP setting within the Unified Access Gateway configuration. That setting relates to the Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic sent by the client. Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. For those reasons, the wizard has 8443 as the default value. The other choice, 443, is less efficient, less performant, and causes CPU congestion in the instances which can cause observable traffic delays in the end-user clients. The 443 choice should be used only if your organization has set client-side restrictions, such as your organization only permits 443 outbound.
    Note: The UDP port used for Blast Extreme is unaffected by this setting, and is always UDP 8443.
    Cipher Suites Although in almost all cases the default settings do not need to be changed, Unified Access Gateway provides this feature for optionally specifying the cryptographic algorithms used to encrypt communications between clients and the Unified Access Gateway appliances.

    At least one cipher suite must be selected from the on-screen list. The on-screen list displays the cipher suites allowed for the Horizon Cloud on Microsoft Azure deployment.

    Specify the settings for this gateway's Microsoft Load Balancer.

    Option Description
    Enable Public IP? Controls whether this gateway's load balancing type is configured as private or public. If switched on, the deployed Microsoft Azure load balancer resource is configured with a public IP address. If switched off, the Microsoft 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.

    If you switch off this toggle, the field Public IP for Horizon FQDN appears.

    Public IP for Horizon FQDN When you have chosen not to configure the deployed Microsoft Azure load balancer with a public IP, you must provide the IP address to which you are assigning the FQDN that you specified in the FQDN field. Your end users' Horizon clients will use this FQDN for PCoIP connections to the gateway. The deployer will configure this IP address in the Unified Access Gateway configuration settings.

    Specify the external gateway's networking settings.

    Option Description
    Use a Different Virtual Network This toggle controls whether the external gateway will be deployed into its own VNet, separate from the pod's VNet.

    The following rows describe the different cases.

    Note: When you specified to use a different subscription for the external gateway in the first step of the wizard, this toggle is enabled by default. You must choose a VNet for the gateway in that situation.

    When this toggle is switched on and the Inherit Pod NTP Servers toggle is switched on, ensure that the NTP servers that are specified for the pod manager instances are reachable from the virtual network you select for the external gateway deployment.

    Use a Different Virtual Network — Switched off When the toggle is switched off, the external gateway will be deployed into the pod's VNet. In this case, you must specify the DMZ subnet.
    • DMZ Subnet - When Use Existing Subnet is enabled in the Pod Setup 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.
    • DMZ Subnet (CIDR) - When Use Existing Subnet is switched off 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 gateway's Microsoft Azure public load balancer.
    Use a Different Virtual Network — Enabled When the toggle is enabled, the external gateway will be deployed into its own VNet. In this case, you must select the VNet to use and then specify the three required subnets. Enable the Use Existing Subnet toggle to select from subnets that you have created in advance on the specified VNet. Otherwise, specify the subnets in CIDR notation.
    Important: Select empty subnets, ones that have no other resources attached to them. If the subnets are not empty, unexpected results might occur during the deployment process or pod operations.

    In this case, the gateway's VNet and pod's VNet are peered. The best practice is to have the subnets created in advance, and not use the CIDR entries here. See Prerequisites When Deploying With an External Unified Access Gateway Configuration Using its Own VNet or Subscription Separate from the Pod's VNet or Subscription.

    • Management subnet - Specify the subnet to use for the gateway's management subnet. A CIDR of at least /27 is required. This subnet must have the Microsoft.SQL service configured as a service endpoint.
    • Back-end subnet - Specify the subnet to use for the gateway's back end subnet. A CIDR of at least /27 is required.
    • Front-end subnet - Specify the subnet for the front-end subnet that will be configured to connect the Unified Access Gateway instances to the gateway's Microsoft Azure public load balancer.
  6. (Optional) In the Deployment section, use the toggle to optionally select an existing resource group into which you want the deployer to deploy the resources for the external gateway configuration.
    This toggle displays when you have specified to use a different subscription for the external gateway in the first step of the wizard. When you enable the toggle, a field appears in which you can search for and select the resource group.
  7. 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 Gateway? 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 a two-factor authentication server that is located outside of the VNet topology into which the Unified Access Gateway instances are deployed, you would specify the address of a DNS server that can resolve the host name of that authentication server. As an example, when your two-factor authentication is located on-premises, enter a DNS server that can resolve the name of that authentication server.

    As described in the deployment prerequisites, the VNet topology used for the Horizon Cloud on Microsoft Azure deployment must be able to communicate with your DNS server that you want providing external name resolution during the deployment of the Unified Access Gateway instances and for their ongoing operations.

    By default, the DNS server that is configured on the VNet into which the instances are deployed is the one used.

    When you specify addresses in DNS Addresses, the deployed Unified Access Gateway instances use those addresses in addition to the DNS server information in your VNet's configuration.

    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 for communication with two-factor authentication servers.

    When configuring this pod to use two-factor authentication with an on-premises authentication server, you must enter the correct route the Unified Access Gateway instances can use to reach that server. For example, if your on-premises authentication 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.

    Inherit Pod NTP Servers This toggle is enabled by default to have the Unified Access Gateway instances use the same NTP server that is specified for the pod manager instances. Keeping this toggle enabled is strongly recommended.

    Using the same NTP server for the pod manager instances, Unified Access Gateway instances, and your Active Directory servers is a best practice. Time skews can result when these instances use different NTP servers. Such time skews can later result in failures when the gateway attempts to authenticate end user sessions to their desktops and applications.

    VM Model Select a model to use for the Unified Access Gateway instances. You must ensure that the Microsoft Azure subscription you specified for this pod can provide the capacity for two VMs of the selected model.
    Important: In the current service release, the VM model used by these instances cannot be easily changed after the gateway configuration is deployed in your subscription. Changing the VM model after deployment requires deleting the gateway configuration and re-deploying it. If you anticipate your environment to scale to 2,000 sessions per pod, select F8s_v2. As stated in VMware Horizon Cloud Service on Microsoft Azure Service Limits, the A4_v2 VM model is only sufficient for proofs-of-concept (PoCs), pilots, or smaller environments where you know that you will not exceed 1,000 active sessions on the pod.
    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.
    Blast Extreme TCP Port Select the TCP port to use in the Blast Extreme TCP setting within the Unified Access Gateway configuration. That setting relates to the Blast Extreme via Blast Secure Gateway on Unified Access Gateway for data traffic sent by the client. Port 8443 is preferred because it is more efficient, provides better performance, and uses less resources on the Unified Access Gateway instances. For those reasons, the wizard has 8443 as the default value. The other choice, 443, is less efficient, less performant, and causes CPU congestion in the instances which can cause observable traffic delays in the end-user clients. The 443 choice should be used only if your organization has set client-side restrictions, such as your organization only permits 443 outbound.
    Note: The UDP port used for Blast Extreme is unaffected by this setting, and is always UDP 8443.
    Cipher Suites Although in almost all cases the default settings are sufficient, Unified Access Gateway provides this feature for specifying the cryptographic algorithms used to encrypt communications between clients and the Unified Access Gateway appliances.

    At least one cipher suite must be selected from the on-screen list. The on-screen list displays the cipher suites allowed for the Horizon Cloud on Microsoft Azure deployment.

  8. In the section for whichever gateway you are adding, if you want to optionally configure the end users' desktops to use two-factor authentication, follow the steps in Enable Two-Factor Authentication on a Horizon Cloud Pod's Gateways.
  9. In the Azure Resource Tags section, if you want to specify resource tags for the gateway-related resource groups that are different from the ones specified on the pod's other resource groups, deactivate the Inherit Pod Tags toggle and specify the tags in the fields that appear.
    For a description of the Azure Resource Tags fields, see Specify the Horizon Cloud Pod's Gateway Configuration. The same set of tags will be used for both types of gateways on the pod.
  10. Click Save & Exit.
    A confirmation message appears asking you to confirm the start of the workflow.
  11. 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. Also, you cannot perform additional Edit Pod workflow-related activities until the system is finished with its actions to deploy the gateway.

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 How to Obtain the Horizon Cloud Pod Gateway's Load Balancer Information to Map in Your DNS Server for details.
  • If you specified two-factor authentication for the added gateway, you must do these tasks:
    • If the pod's external gateway has two-factor authentication configured and the two-factor authentication server is not reachable within the same VNet topology into which the gateway's Unified Access Gateway instances are deployed, configure that two-factor authentication server to allow communication from the IP address of the external gateway's load balancer.

      In this scenario where the two-factor authentication server is not reachable within the same VNet topology as the gateway deployment, the Unified Access Gateway instances attempt contact with that server using that load balancer address. To allow that communication traffic, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client or a registered agent in your two-factor authentication server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

    • If your two-factor authentication server is reachable within the same VNet topology, configure the two-factor authentication server to allow communication from the appropriate NICs that were created for the deployment's Unified Access Gateway instances in Microsoft Azure.

      Your network administrator determines the two-factor authentication server's network visibility to the Azure VNet topology and its subnets used for the deployment. The two-factor authentication server must allow communication from the IP addresses of the Unified Access Gateway instances' NICs that correspond to the subnet for which your network administrator has given network visibility to the two-factor authentication 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 and its gateways go through an update.

      To support communication traffic between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients or as registered agents in that server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

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