This article describes the detailed system requirements that your Horizon Cloud tenant environment must meet to support the use of Universal Broker. The requirements differ slightly depending on whether you are configuring Universal Broker for Horizon pods (based on Horizon Connection Server technology) or for Horizon Cloud pods in Microsoft Azure.

Note: For the latest information on any support limitations for Universal Broker, see Horizon Cloud — Known Limitations.

Requirements for Horizon Pods That are Connected to Horizon Cloud by Horizon Cloud Connector

To support the use of Universal Broker for Horizon pods that are connected to the cloud service by Horizon Cloud Connector, your system environment must meet the following requirements.

Software versions of key components:
  • Each pod must be running Horizon Connection Server no earlier than version 7.11, have a valid license, and have the appropriate Universal Broker plugin version installed on that Connection Server, as described in Horizon Pods - Install the Universal Broker Plugin on the Connection Server.

    Each pod and Connection Server must be a valid installation, according to the specific Connection Server version's product documentation: VMware Horizon documentation or the VMware Horizon 7 documentation.

  • Each pod must be cloud-connected to Horizon Cloud using a Horizon Cloud Connector no earlier than version 1.6. Please note that 1.6 is an extremely old version of Horizon Cloud Connector and is not supported for new pod onboardings. That version was the first one for which Universal Broker became available, and so it is mentioned here for completeness. New onboardings are supported using Horizon Cloud Connector version N, N-1, N-2, where N is the latest Horizon Cloud Connector version available as of this writing.
  • Special consideration for version 1.8 or 1.9 of the connector: Universal Broker relies on the Cloud Broker Client Service (CBCS) running in the connector to communicate with the pod. If your Horizon pod is using Horizon Cloud Connector 1.8 or 1.9, Universal Broker is supported if you deployed Horizon Cloud Connector with the Full Feature profile or if you deployed with the Basic Feature profile and then manually activated the Cloud Broker Client Service (CBCS) for the connector. For steps to manually activate CBCS in this setup, see Manually Activate Services in version 1.8 or 1.9.
  • Special consideration for a Horizon pod cloud-connected using Horizon Cloud Connector in a native Amazon EC2 deployment: to use Universal Broker for that pod, you must manually enable use of the Cloud Broker Client Service (CBCS) in that appliance, because that service is inactive by default for a native Amazon EC2 deployment. For more information on how to manually enable use of CBCS in this setup, see Manually Activate Services for Horizon Cloud Connector on Native Amazon EC2.
Requirements per some specific end-user scenarios:
You want to use two-factor authentication with Universal Broker
  • If you want Universal Broker to use two-factor authentication with any of your end users, then you must replace any security server on the Horizon pod with an external Unified Access Gateway appliance, version 3.8 or later.
  • You must also configure that external Unified Access Gateway with the appropriate two-factor authentication service that Universal Broker supports.
  • For a tenant pod fleet that is solely Horizon pods, that authentication service can be either RADIUS or RSA SecurID. However, if your pod fleet is a blend of both Horizon pods and Horizon Cloud pods and the tenant is using Universal Broker for both types, you can use only RADIUS.
  • The reason why Universal Broker plus a blended pod fleet can only use RADIUS is because Universal Broker leverages the same two-factor authentication settings for each pod in the tenant's fleet and Horizon Cloud pods only support RADIUS.
You have all internal users and want to use direct connect with them
If you plan to have all user access from your internal network always, you can use Universal Broker for what is called direct connect. In direct connect, sessions for such end users are established directly between the user's Horizon Client or web client and the virtual desktops and remote applications (VDI and RDSH). In this case, no Unified Access Gateway instances are required as long as you also specify IP addresses using the console's Broker > Network Ranges feature so that Universal Broker knows that end-user traffic is coming from your internal network. If you do not specify those IP addresses and you have all internal end users, the pod must have an internal Unified Access Gateway appliance, version 3.8 or later, to connect the sessions. Either way, a security server is not needed and you can remove any security server that the pod might have.
You have both internal and external users and you want to configure two-factor authentication in Universal Broker
If you specify IP addresses using the Broker > Network Ranges feature, Universal Broker can determine when a connecting user is on the internal network and will consider that as a direct connection for that user. Otherwise, if you do not specify the IP addresses in Broker > Network Ranges, the Universal Broker will treat all the end-user connections as external and will send the connections to the external Unified Access Gateway appliance.
Per the preceding scenarios, when a Unified Access Gateway is involved:
  • Configure each Unified Access Gateway instance as the proxy server for connection requests to its paired Connection Server. Ensure that each Unified Access Gateway instance is paired with only one pod.
  • If a pod includes only an internal Unified Access Gateway instance (no external one), Universal Broker overrides the IP ranges specified in Broker > Network Ranges and routes all users to that internal Unified Access Gateway instance, regardless of their IP address. If zero IP ranges are specified in Broker > Network Ranges, the virtual desktop and remote application launches rely on that internal Unified Access Gateway.
The Unified Access Gateway product documentation is located at https://docs.vmware.com/en/Unified-Access-Gateway/index.html.
DNS names, ports, protocols:
  • Each pod must be configured with the required ports and protocols as described in Horizon Pods - DNS, Ports, and Protocol Requirements for Universal Broker.
  • To support Universal Broker routing end-user traffic appropriately in the scenarios where a Unified Access Gateway is required, when your pod is configured with a Unified Access Gateway, you must ensure all of the DNS names are mapped appropriately in your internal and external DNS servers. If the pod has configured both an internal and external Unified Access Gateway, the internal and external configuration can specify different FQDNs, or they can be configured with the same FQDN and the pod's load balancer configured with split DNS zones.
Desktop pools:
To launch end-user sessions, desktop pools must be configured on the participating pods and based on virtual machines running the Windows operating system. In addition, the pool configuration settings must meet the requirements of Universal Broker, as described in Horizon Pods - Prepare an Existing Desktop Pool for Use in a Multi-Cloud Assignment.

Requirements for Horizon Cloud Pods in Microsoft Azure

To be used with Universal Broker, each participating Horizon Cloud pod in Microsoft Azure:

  • Must be deployed new in Microsoft Azure at the July 2020 release's manifest (2298.0) or later
    Note: Universal Broker is available only if you have deployed all your Horizon Cloud pods at manifest 2298.0 or later. If you deployed any of your Horizon Cloud pods at earlier than manifest 2298.0, Universal Broker is not an available brokering option for your Horizon Cloud pods.
  • If you want to have end-user connections from the Internet or you want to use two-factor authentication, an external Unified Access Gateway configuration is required on the pod.
    Note: Ensure that each Unified Access Gateway instance is paired with only one pod.
    Note: If a pod includes only an internal Unified Access Gateway instance, Universal Broker overrides the networking policy defined on the Broker page's Network Ranges tab and routes all users to that Unified Access Gateway instance, regardless of their IP address.

    To support specific use cases, the pod must meet additional requirements:

    • To route internal and external network traffic from Universal Broker to their respective internal and external DNS servers, each pod must be configured with both internal and external Unified Access Gateway instances. The internal and external Unified Access Gateway instances can be configured with different FQDNs, or they can be configured with the same FQDN and the pod's load balancer configured with split DNS zones.
    • To use two-factor authentication for Universal Broker, the pod must have at least one external Unified Access Gateway instance configured with the appropriate RADIUS authentication service. You must configure all the external Unified Access Gateway instances across all participating pods to use the same RADIUS authentication service.
    For more information, see Specify the Horizon Cloud Pod's Gateway Configuration.
  • Configured such that the required DNS names for your regional Universal Broker instance are resolvable and reachable. See the "Pod Deployment and Operations DNS Requirements" table in DNS Requirements for a Horizon Cloud Pod in Microsoft Azure.
  • Configured with the required ports and protocols, as described in the "Ports and Protocols Required by Universal Broker" section in Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later
  • In a healthy state. On the Capacity page, a healthy pod shows a green dot under the Status column, indicating that the pod is online and ready.

Client Requirements

For client requirements related to Universal Broker, see the Horizon Client information provided within the topic Horizon Cloud - Available Environments, Operating System Support, Tight Integration Within the VMware Ecosystem, and Compatibility Information.