In this step of the wizard, specify the information required to deploy the pod-manager-based pod with one or more gateways configured. Unified Access Gateway provides the gateway environment for this type of pod.

External gateway configuration
The external gateway configuration gives the ability to provide access to desktops and applications for end users located outside of your corporate network. When the pod has this external gateway configuration, the pod includes an Azure Load Balancer resource and Unified Access Gateway instances to provide this access. In this case, the instances have three NICs each: one NIC on the management subnet, one NIC on the desktop subnet, and one NIC on the DMZ subnet. In the deployment wizard, you have the option to specify the load balancing type as either private or public, depending on whether you want a private IP or public IP address for the load balancer. If you switch off this public IP toggle in the wizard, the wizard displays a field in which you must specify an IP address. In that type of configuration, the PCoIP connections to the gateway from the Horizon clients will use this IP address.

For an external gateway configuration, you also have the option to deploy the configuration into a VNet that is separate from the pod's VNet. The VNets must be peered. This type of configuration gives the ability to deploy the pod into more complex network topologies in Microsoft Azure, such as a hub-spoke network topology.

Note: If you enabled the toggle for having the external gateway using its own subscription in the first wizard step, you must deploy the external gateway into its own VNet, the VNet that is associated with that subscription. If you enabled that toggle, you can optionally select an existing resource group in that subscription for the external gateway's resources. You must have prepared that resource group in advance so that you can select it in this wizard step.
Internal gateway configuration
The internal gateway configuration gives the ability for end users located inside your corporate network to have trusted HTML Access (Blast) connections to their desktops and applications. If the pod is not configured with this internal gateway configuration, end users inside your corporate network see the standard browser untrusted certificate error when they use their browsers to make HTML Access (Blast) connections to their desktops and applications. When the pod has this internal gateway configuration, the pod includes an Azure Load Balancer resource and Unified Access Gateway instances to provide this access. In this case, the instances have two NICs each: one NIC on the management subnet and one NIC on the desktop subnet. By default, this gateway's load balancing type is private.

The following screenshot is an example of the step when it is initially displayed. Some controls are displayed only when you selected at the first wizard step to use a different subscription for the external gateway configuration.


Horizon Cloud on Microsoft Azure: Step 3 of the pod deployment wizard when it initially displays.

Prerequisites

Verify that you have met the prerequisites described in Prerequisites for Running the Pod Deployment Wizard.

Decide what VM 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. 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.

Important: Choose the VM model wisely. In the current service release, the VM model used by the deployed instances cannot be easily changed after the gateway configuration is deployed. Changing the VM model after deployment involves deleting the gateway configuration and re-deploying it.
Important: To complete this step, you must have the required fully qualified domain name (FQDN) which your end users will use to access the service and have a signed SSL certificate (in PEM format) based on that FQDN. The certificate must be signed by a trusted CA. A single PEM file must contain the entire certificate chain and the private key: SSL certificate intermediate certificates, root CA certificate, private key. For details, see Convert a Certificate File to the PEM Format Required for Pod Deployment.

Verify that all certificates in the certificate chain have valid time frames. If any certificate in the chain is expired. unexpected failures can occur later in the pod onboarding process.

This FQDN cannot contain underscores. In this release, connections to the Unified Access Gateway instances will fail when the FQDN contains underscores.

When you will select an external gateway configuration, Horizon Cloud expects that the FQDN specified for the external gateway configuration is publicly resolvable. If you switch off the Enable Public IP? toggle in the wizard 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.

If your tenant is configured with Universal Broker that has two-factor authentication configured, you must configure an external Unified Access Gateway with two-factor authentication settings.

Procedure

  1. If you want the external gateway configuration, complete the fields in the External Gateway 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.
  2. (Optional) In the External Gateway section, optionally configure two-factor authentication for the external gateway.
  3. (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.
  4. In the Internal Gateway section, if you want the internal gateway configuration, switch on the Enable Internal Gateway? toggle and complete the fields that appear.
    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.

  5. (Optional) In the Internal Gateway section, optionally configure two-factor authentication for the internal Unified Access Gateway.
  6. (Optional) In the Azure Resource Tags section, optionally add custom tags to the resource groups that contain all the internal and external Unified Access Gateway instances that you have configured for the pod.
    Option Description
    Inherit Pod Tags

    Switch on this toggle to add the pod's resource tags to the resource groups containing all the Unified Access Gateway instances that you have configured. Each resource group receives the resource tags that you defined in the Pod Setup wizard step.

    Switch off this toggle to define new resource tags for the Unified Access Gateway instances.

    Azure Resource Tags

    This setting becomes visible when you switch off the Inherit Pod Tags toggle. Use this setting to add new resource tags to the resource groups containing the Unified Access Gateway instances that you have configured.

    To create the first tag, enter information in the Name and Value fields. To create an additional tag, click + and then enter information in the Name and Value fields that appear below the existing ones.

    • You can create a maximum of 10 tags.
    • The tag name is limited to 512 characters, and the tag value is limited to 256 characters. For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
    • Tag names cannot contain the following characters: < > % & \ ? /
    • Tag names cannot contain these case-insensitive strings: azure, windows, microsoft
    • Tag names and tag values can only contain ASCII characters. Blank spaces and characters outside the standard 128-character ASCII set (also known as high ASCII or extended ASCII characters) are not allowed.

Results

When you have provided the required information associated with your selected options, you can click Validate & Proceed to continue to the wizard's final step. See Validate and Proceed, and then Start the Pod Deployment Process.