This article is a brief introduction to the Universal Broker, one of the Horizon Control Plane services. The Universal Broker is a cloud-based service that enables the brokering of resources that span multiple pod deployments regardless of the infrastructure they are running on. The service also makes intelligent brokering decisions based on the geographic sites of users and pods.

Overview of Universal Broker

Universal Broker, the latest cloud-based brokering technology from VMware, is available for use when your tenant has one or more of the following:

  • Horizon pods - pods which are based on Horizon Connection Server technology
  • Horizon Cloud on Microsoft Azure pods, and all of those pods are running pod manifest 2298.0 or later.

For detailed information about how the system components of the Universal Broker solution work together to manage users' connection requests to assignments, see System Architecture and Components of Universal Broker.


High-level diagram of Universal Broker system architecture

Key Features

Universal Broker offers the following key features:

  • Single connection FQDN for all remote resources

    End users can access multi-cloud assignments in your environment by connecting to a fully qualified domain name (FQDN), which you define in the Universal Broker configuration settings. Through the single Universal Broker FQDN, users can access assignments from any participating pod in any site in your environment. No internal networking between your pods is required.


    Diagram of single FQDN connection for Universal Broker
  • Global pod connectivity and awareness for optimal performance

    Universal Broker maintains direct connectivity with every pod participating in multi-cloud assignments and stays aware of the availability status of each pod. As a result, Universal Broker can manage end users' connection requests and route them to virtual resources directly from these pods. There is no need for global server load balancing (GSLB) or any interpod network communication which can result in reduced performance and latency issues.

  • Smart brokering

    Universal Broker can broker resources from assignments to end users along the shortest network route, based on an awareness of your geographical sites and pod topology.

Brokering and End-User Desktop Pools and Remote Apps

Assignments are conceptual entities in the Horizon Universal Console. Using the console, assignments are the way you define pools of end-user virtual desktops and remote apps and entitle them to your end users. For example, in the console, you create assignments of VDI desktops or assignments of RDSH resources, and then entitle those assignments to your end users.

The Universal Broker manages a client user's connection request to an entitled assignment and negotiates the connection session to an appropriate resource that fulfills that request. The Universal Broker is aware of geographical locality and pod topology. Using this information, the Universal Broker searches for the best resources to fulfill users' connection requests based on the site configuration and resource availability.

See the following sections for the list of assignment types available, by pod type.

End-User Assignments Using Resources from Horizon Cloud Pods Deployed into Microsoft Azure

With the Universal Broker configuration completed for the Horizon Cloud pods in your pod fleet, these assignment types are possible:

End-User Assignments Using Resources from Cloud-Connected Horizon Pods

With the Universal Broker configuration completed for the Horizon pods in your pod fleet, these assignment types are possible:

Notes

As with almost all software, the current release has some feature considerations and known limitations. For more information, see Universal Broker - Feature Considerations and Known Limitations.

System Architecture and Components of Universal Broker

This article provides a detailed illustration of the system components of Universal Broker that run within participating pods and in the Horizon Cloud control plane. Universal Broker represents the latest cloud-based brokering technology from VMware and is the recommended connection broker for end-user assignments in new deployments.

For an overview of the key features of Universal Broker, see Introduction to VMware Horizon Service Universal Broker.

The system architecture of the Universal Broker solution differs slightly depending on whether the brokered resources reside in Horizon pods (based on Horizon Connection Server technology) or in Horizon Cloud 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 (based on Horizon Connection Server technology).

  • 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 Settings.
  • The Universal Broker client runs within the Horizon Cloud Connector for each of your cloud-connected Horizon pods. Starting with version 1.5 of that connector, the Universal Broker client is part of that connector and is automatically installed when you pair the Horizon Cloud Connector with your pod.
  • The Universal Broker plugin runs within the Horizon 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 manage connection requests from your external end users to remote resources in an assignment.

Note: The depicted scenario involves the Horizon Client located on an external network, outside of your corporate network, with an external Unified Access Gateway configured on the pod.

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 each of the Connection Server instances within Pod 1.
  4. The Universal Broker plugin identifies the best available desktop that fulfills the end user's request.
  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 - DNS, Ports, and Protocol Requirements for Universal Broker.

System Architecture of Universal Broker for Horizon Cloud Pods in Microsoft Azure

The following components comprise the Universal Broker solution for cloud-based brokering of VDI and RDSH assignments from Horizon Cloud 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 Settings.
  • The Universal Broker client runs within each participating Horizon Cloud pod in Microsoft Azure.
Note: The depicted scenario involves the Horizon Client located on an external network, outside of your corporate network, with an external Unified Access Gateway configured on the pod.

System architecture of Universal Broker for Horizon Cloud 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 that fulfills the end user's request.
  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.

Universal Broker - Feature Considerations and Known Limitations

This documentation page provides some of the feature considerations related to Universal Broker and a list of the Horizon features that have limited or no support.

Feature Considerations

  • In a pod fleet that contains both Horizon pods and Horizon Cloud pods, each end-user assignment you create must consist of VDI desktops from only one pod type. For example, you can create an assignment consisting of desktops that span multiple Horizon pods or an assignment consisting of desktops that span multiple Horizon Cloud pods. However, you cannot create an assignment consisting of desktops that span a mix of Horizon pods and Horizon Cloud pods.
  • Additional considerations apply if you have transitioned your tenant from a single-pod broker configuration to Universal Broker. See What's New in Your Tenant Environment After the Transition to Universal Broker.

Maximum Number of Pods Per VDI Multi-Cloud Assignment Limit

The supported maximum number of pods in a VDI multi-cloud assignment is five (5). This limit applies to both Horizon Connection Server type pods and Horizon Cloud on Microsoft Azure type pods. Using more than five increases the concurrent load on Universal Broker. Increasing that concurrent load can lead to end users encountering failures when they click on the assignment's displayed tile in the client and the service attempts to log in the user to the virtual desktop.

Virtual Resources

For the brokering of virtual resources, this release of Universal Broker only supports Windows operating systems. Linux-based desktops are not supported.

This release does not support administrator-created shortcuts to desktops and applications.

Note: A specific user can receive at most one assigned desktop from a dedicated assignment brokered by Universal Broker, even if the assignment includes desktops from multiple pods.

Horizon HTML Access and Horizon Client for Chrome

End users can make requests for resources to the Universal Broker service by running Horizon HTML Access in a supported web browser or by running Horizon Client for Chrome 5.4 or later. If the Universal Broker service redirects the request to a Unified Access Gateway instance that uses a self-signed certificate, the client application displays an error message indicating that the certificate authority is invalid.

This behavior is according to design. To connect to the requested resource, the user can accept the self-signed certificate by following the prompts in the certificate error message.

Authentication Methods

This release of Universal Broker supports client user authentication through Windows user name and password, in UPN and NETBIOS formats.

Two-factor authentication through RADIUS or RSA is also supported, depending on the current state of the tenant's pod fleet, as in the following list.

Also review the following section that describes the end-user experience when using Universal Broker in their clients and two-factor authentication is configured. The current behavior is different from the behavior when using a pod's gateway FQDNs directly.

Horizon pods only
Both RADIUS and RSA SecurID authentication are supported.
Horizon Cloud on Microsoft Azure deployments only
If all pods are manifest 3139.x or later and both the RSA SecurID and RADIUS options are visible for selection when you run the Edit Pod wizard on the pods, then both RSA SecurID and RADIUS authentication are supported. Otherwise, only RADIUS type is supported.
Mixture of Horizon pods and Horizon Cloud on Microsoft Azure deployments
In a blended fleet, the supported authentication types depend on whether your Horizon Cloud on Microsoft Azure deployments meet the conditions to have the RSA SecurID option configured on them:
  • If your Horizon Cloud on Microsoft Azure deployments do not meet those conditions, then only RADIUS authentication is supported.
  • If your Horizon Cloud on Microsoft Azure deployments meet those conditions, then both RADIUS and RSA SecurID authentication are supported.

The conditions to meet are the pods are running manifest 3139.x or later and when you open the Edit Pod wizard on the pods, both the RSA SecurID option and RADIUS options are visible for selection.

When Two-Factor Authentication is Configured

When two-factor authentication is involved, your end users will experience one authentication flow when using the Universal Broker FQDN that is slightly different from the flow when using a pod's gateway FQDN directly.

  • In the Universal Broker authentication flow, the end users will be prompted to enter their Windows Active Directory (AD) credentials twice: once when they first connect to the Universal Broker FQDN and then again after successfully completing the two-factor authentication with the configured RADIUS or RSA SecurID system.
  • When using a pod's gateway authentication flow, the end users will be prompted to enter their Windows Active Directory (AD) credentials once when they first connect to the pod's gateway FQDN.
Note: To eliminate seeing two AD prompts when using Universal Broker, consider integrating with VMware Workspace ONE Access and configure the two-factor authentication in VMware Workspace ONE Access.

Currently Unsupported User Authentication and Access Methods

The following user authentication and access methods are not supported currently.

  • Smart card
  • Certificate
  • SAML authentication (outside of integration with VMware Workspace ONE)
  • Log in as the current user
  • Anonymous access

When one of the unsupported items qualifies for support, its entry will be removed from the preceding list and the announcement of support will be stated in the page titled For Current Customers with Existing Cloud-Connected Pods — About Horizon Cloud Service Releases. In that page, the statement will be listed in the section that corresponds to the release in which the support was added.

Remote Desktop Features

The following features are not supported in this release of Universal Broker:

  • URL content redirection
  • Session collaboration

Other Features

The following features are also not supported in this release of Universal Broker:

  • Kiosk mode
  • Timing profile (for troubleshooting user sessions )
  • OPSWAT-based endpoint compliance checks