Universal Broker represents the latest cloud-based brokering technology from VMware and is the preferred brokering method for end-user assignments in new deployments. Universal Broker includes several system components that run within participating pods and in the cloud.

For an overview of the key features of Universal Broker, see Introduction to Universal Broker and Single-Pod Broker.

The system architecture of the Universal Broker solution varies slightly based on whether the brokered resources reside on Horizon pods or on pods in Microsoft Azure.

System Architecture of Universal Broker for Horizon Pods

The following components comprise the Universal Broker solution for cloud-based brokering of multi-cloud assignments from Horizon pods.

  • The Universal Broker service is a multi-tenant cloud service that runs within the Universal Broker cloud, which is connected to Horizon Cloud. Each customer connects to the Universal Broker service using a unique, dedicated FQDN that is configured as described in Configure Universal Broker.
  • The Universal Broker client runs within the Horizon Cloud Connector for each of your cloud-connected Horizon pods. The client is part of the OVA file for Cloud Connector 1.5 or later and is automatically installed when you pair the Cloud Connector with your pod.
  • The Universal Broker plugin runs within the Connection Server for every cloud-connected pod that participates in multi-cloud assignments. You must download and install the plugin on each Connection Server instance within a participating pod, as described in Horizon Pods - Install the Universal Broker Plugin on the Connection Server.

The following diagram illustrates how Universal Broker works with the components in your Horizon pod environment to allocate virtual desktops from multi-cloud assignments to your end users.


System architecture of Universal Broker for Horizon pods
  1. From Horizon Client, the end user requests a virtual desktop by connecting to the Universal Broker service through the brokering FQDN. The service uses the XML-API protocol to authenticate the Horizon Client user and manage the connection session.
  2. After determining that Pod 1 in Site 1 is the best available source for the desktop, the Universal Broker service sends a message to the Universal Broker client, which runs on the Horizon Cloud Connector paired with Pod 1.
  3. The Universal Broker client forwards the message to the Universal Broker plugin, which runs on one of the Connection Server instances within Pod 1.
  4. The Universal Broker plugin identifies the best available desktop to allocate to the end user.
  5. The Universal Broker service returns a response to Horizon Client which includes the unique FQDN of Pod 1 (typically the FQDN of the Pod 1 load balancer). Horizon Client establishes a connection with the load balancer to request a protocol session with the desktop.
  6. After passing through the local load balancer, the request goes to the Unified Access Gateway for Pod 1. The Unified Access Gateway validates that the request is trusted and prepares the Blast Secure Gateway, PCoIP Secure Gateway, and tunnel server.
  7. The Horizon Client user receives the specified desktop and establishes a session based on the configured secondary protocol (Blast Extreme, PCoIP, or RDP).

For more information about the ports used for Universal Broker communications, see Horizon Pods - Port and Protocol Requirements for Universal Broker.

System Architecture of Universal Broker for Pods in Microsoft Azure

The following components comprise the Universal Broker solution for cloud-based brokering of VDI and RDSH assignments from pods in Microsoft Azure.

  • The Universal Broker service is a multi-tenant cloud service that runs within the Universal Broker cloud, which is connected to Horizon Cloud. Each customer connects to the Universal Broker service using a unique, dedicated FQDN that is configured as described in Configure Universal Broker.
  • The Universal Broker client runs within each participating pod in Microsoft Azure.

System architecture of Universal Broker for pods in Microsoft Azure
  1. From Horizon Client, the end user requests a virtual resource by connecting to the Universal Broker service through the brokering FQDN. The service uses the XML-API protocol to authenticate the Horizon Client user and manage the connection session.
  2. After determining that Pod 1 in Site 1 has the best available resource for the user's request, the Universal Broker service sends a message to the Universal Broker client running within Pod 1.
  3. The Universal Broker client forwards the message to the active pod manager within Pod 1.
  4. The active pod manager identifies the best available resource to allocate to the end user.
  5. The Universal Broker service returns a response to Horizon Client which includes the unique FQDN of Pod 1 (typically the FQDN of the Microsoft Azure load balancer for Pod 1). Horizon Client establishes a connection with the load balancer to request a protocol session with the resource.
  6. After passing through the Microsoft Azure load balancer, the request goes to the Unified Access Gateway for Pod 1. The Unified Access Gateway validates that the request is trusted and prepares the Blast Secure Gateway, PCoIP Secure Gateway, and tunnel server.
  7. The Horizon Client user receives the specified resource and establishes a session based on the configured secondary protocol (Blast Extreme, PCoIP, or RDP).

For more information about the ports used for Universal Broker communications, see 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.