Configuring Universal Broker for HorizonHorizon 7 on vSphere
Horizon 8 on vSphere
Purpose of this Guide
This guide explains the Universal Broker, a component of the Horizon Service, and how to start using it in your existing VMware Horizon® environment.
Horizon customers have been leveraging different methods to present a single UI to display all their user entitlements:
- Single-pod brokering via a Connection Server or multiple connection servers.
- Cloud Pod Architecture along with Global Assignments which are accessed either via the Horizon Client or the Web Client.
- VMware Workspace ONE® Access™ through a web client or the Hub client.
- A combination of the items in this list.
The introduction of Universal Broker enables a new, modern, cloud-based option to broker users to their entitlements. Depending on the configuration you already use, you may want to consider evolving your Horizon deployment to leverage the Universal Broker. This guide helps you understand the reasons for changing and the results of the changes.
This guide is intended for IT administrators and product evaluators with existing Horizon environments. For example, Horizon administrators who are using the previously listed methods to present a single place to go to access desktop environments and Horizon administrators who are using Cloud Pod Architecture or perhaps have a single pod and are looking to expand it to a multiple pod configuration. Perhaps they have on-premises Horizon and want to try out Universal Broker without making significant changes to what they are doing today.
Familiarity with networking and storage in a virtual environment, Active Directory, identity management, and directory services is assumed. Knowledge of other technologies, such as cloud-based applications is useful.
What is a Connection Broker?
A broker is a component of a remote desktop solution that handles authentication, determines what assignments a user has, and presents them to the user. After the user selects a resource, the broker allocates and directs the user to that resource.
Horizon Connection Server or Horizon Cloud Pod Manager
Both the Horizon Connection Server and the Horizon Cloud on Microsoft Azure pod manager VM have brokering functionality built into each service respectively. Users can directly connect with either and get access to desktop or application resources. See for more details.
Figure 1: Horizon Components
Cloud Pod Architecture
Cloud Pod Architecture is a brokering solution that can be used with Horizon 7 and Horizon 8 pods regardless of infrastructure type. Cloud Pod Architecture (CPA) introduces the concept of a global entitlement (GE) through joining multiple Horizon pods together into a federation. Pods can be in the same physical site or location or in different sites and locations. CPA allows a resource to span multiples sites for availability and load. The user sees a single global entitlement that points to federated pods. There is a global data layer that keeps the remote Horizon pods in sync.
Figure 2: Horizon Cloud Pod Architecture
Horizon Universal Broker
The Horizon Universal Broker is a cloud-based brokering technology that allows you to broker desktops and applications to end users across all cloud-connected Horizon pods, regardless of the infrastructure that they run on. Users are presented with a single set of entitlements that can span multiple Horizon deployment types.
Figure 3: Universal Broker Architecture
The Universal Broker simplifies hybrid Horizon deployments with a few key features.
- A single connection FQDN (fully qualified domain name) for all remote resources. Users can connect to a single FQDN to access any assignment in any Horizon pod.
- The Universal Broker provides connectivity awareness of Horizon pods, which allows for redirection of requests for resources from an unavailable pod to another pod with sufficient resources to handle the request.
- Smart Brokering functionality can deliver desktops from multi-cloud assignments to end users along the shortest network route.
The Universal Broker is aware of geographical locality and pod topology. Using this information, the Universal Broker can make better resource-matching decisions and deliver desktops from multi-cloud assignments to end users along the shortest network route.
Resources (Desktop and Published Applications) in Universal Broker are assigned to users with Multi-Cloud Assignments within the Horizon Cloud console. Multi-Cloud Assignments are managed within the Assign Desktops & Apps section of the Horizon Cloud Console. Cloud-connected Horizon 7 and Horizon 8 resources are assigned in the VDI & App Volumes section. After that is selected, select New | VMware SDDC to create assignments for Horizon 7 and Horizon 8 to be used with Universal Broker.
Figure 4: Creating Assignments for Horizon 7 and Horizon 8 resources
Moving the brokering function from each individual pod to a broker that is aware of all deployments simplifies the network components of brokering. Universal Broker is a cloud-based brokering technology that has visibility into each Horizon pod and can make better brokering decisions based on that visibility. Instead of reaching out to a Unified Access Gateway to determine if the resource exists on a pod, the Universal Broker already knows which pod to direct the user to.
Universal Broker can make decisions on where to service user resource requests from using rules or policies built into Horizon components. Policies are configured with multi-cloud assignments. Metadata assigned to Horizon components helps Universal Broker make an intelligent decision on how best to broker a resource request to a user.
- Locations – Physical location setup to represent pods on the Dashboard map of the world.
- Sites – Logical association for a group of pods to a physical location
- Home Sites – Logical association for a group of users to a specific default site to be brokered resources from.
This metadata helps Universal Broker make decisions on where to broker a user request for a resource from.
For example, suppose you want a user to access resources from their home site by default unless a specific location is not available because of an outage at a given site. You can configure a multi-cloud assignment to source resources from multiple pods, and then Universal Broker will automatically route a user from their home site to another site if the home site is unavailable. In addition, if the user is traveling and there is a closer pod available, Universal Broker will route the user to that pod.
How to start with Universal Broker?
There are two easy methods to try out Universal Broker that we cover in this section.
- Modify an existing Horizon pod to use Universal Broker.
- Add a new pool or modify an existing pool.
- Add a new pod and configure it to use Universal Broker.
After you have decided on which method is right for you, then you need to follow the prerequisites, implement the Horizon Connector to gain access to the Horizon Service, and implement the Universal Broker for the desired Horizon environment.
Modify an Existing Horizon Pod
Implementing Universal Broker is non-destructive with your Horizon deployment. Multiple production Horizon pods set up with either Single-Pod brokering or Cloud Pod Architecture can be used to try out Universal Broker. To do this, there are a few considerations to keep in mind.
- Existing users with existing entitlements can continue to use Horizon as before. The URL that is used to access the pod or the CPA assignments will continue to work even with the additional configuration of Universal Broker. Trial or test users can additionally use the URL associated with Universal Broker to access cloud-managed assignments as well (see point 2).
- The Universal Broker can only leverage cloud-managed assignments. Local entitlements are created in each respective Horizon pod tied to the multi-cloud assignment automatically but can only be managed from the Horizon Universal Console instead of the Horizon Console. For users that will trial Universal Broker, you must modify existing pools or create new local pools of infrastructure to entitle those users to. Follow the steps outlined in the product documentation to , for existing infrastructure, and manage tied to those pools.
Set up a New Horizon Pod
Set up a separate Horizon pod that is cloud-connected and managed by Universal Broker. You can leverage the to help you set up and configure a new Horizon Pod for testing purposes. The Horizon Universal License allows you to implement as many Horizon pods as you want.
After you have set up a separate pod, you will need to create or import an image or images from another Horizon pod and use them to create VDI pools. Details on creating pools for VDI can be found in the . After you create the pools in Horizon, you need to create a Multi-Cloud Assignment, to allow Horizon 7 and Horizon 8 users to access the resources through Universal Broker.
You can also create farms to host application entitlements. Unlike VDI assignments which can leverage pools of resources from multiple Horizon pods, application or shared desktop entitlements are single-pod only through the multi-cloud assignments. This feature must be enabled on the Horizon Control Plane before it can be used. When the feature is enabled, a Cloud Brokered option will be available in the settings for RDS desktop and application pools.
Figure 5: Requirements for Cloud Enabling an existing Horizon 8 Pool
To gain access to the Horizon Service, you must already be entitled via a Horizon subscription license. You cannot take advantage of the Horizon Service with the perpetual keys that may be in use from an existing Horizon environment.
Connect to Horizon Service and Domain Join
Before you can set up separate authentication configurations with Universal Broker, you must first connect to Horizon Cloud Services and join the domain.
To use Universal Broker, you must use the Horizon Service, and the pods must be “managed” by the Horizon Service.
- Adding a Cloud Connector to Horizon 8 Pod
- First Login to Horizon Service
- Adding a Pod to Horizon Service
- Domain Join
Using Universal Broker with Horizon
The Universal Broker is a component of the Horizon Service. For an overview of Universal Broker and how it works, review the guide. To use Universal Broker, you need to have a few critical environmental components prepared.
Universal Broker with Horizon in SDDC capacity or in a Private Data Center
First, you need to have the pods configured to use the Horizon Service. For Horizon deployments in an SDDC-based infrastructure or a private data center (running vSphere), you need to set up and configure a Horizon Connector Appliance. Each pod using Universal Broker must be “managed”. Currently, Universal Broker has been tested and certified to run in a private data center (vSphere), Azure VMware Solution, and VMware Cloud on AWS.
Universal Broker is also certified and configured as the default broker for all Horizon Cloud on Microsoft Azure deployments.
The Horizon Service and Universal Broker use the Horizon Connector to communicate with each managed pod to match users to entitlements and to monitor capacity and availability of each pod.
You must also install the Universal Broker plugin that 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 .
Set up Universal Broker from the Horizon Universal Console
Select a Brokering Method
Your Horizon pod is now connected to the Horizon Service. Next, you can choose a brokering method.
Figure 6: Selecting a brokering method in Universal Broker
For details, see . There are several components to help you make this decision. After you have selected Universal Broker, then you can leverage it and multi-cloud assignments for your Horizon environment.
Note: If you are using Horizon Cloud on Microsoft Azure, you must choose either Single-Pod brokering or Universal Broker before creating assignments. This choice is made at the Horizon Service level and will impact all Horizon Cloud on Microsoft Azure Pods included in each Horizon Service account.
The single-pod broker is used for island configurations, distributed and localized users, and is supported on all Horizon deployments.
If you use a single-pod broker, you don’t have anything else to do. You may have chosen to use CPA, which also works with Single-Pod Broker on Horizon deployments.
Figure 7: User Traffic flow for Single-Pod Broker configurations
Horizon Universal Broker Initial Configuration
The following steps detail how to set up Horizon Universal Broker for on-premises Horizon environments.
There are several prerequisites to configure the Horizon Universal Broker for it to operate properly. Some critical prerequisites are listed in this section.
You should double-check to make sure that the Horizon Cloud Connector appliance is compatible with each of the Horizon pods you want to leverage with Universal Broker. You can find a list of compatible versions at the site. You should use the most recent / supported Horizon Connector version match for your pod deployment, as it will have the most up-to-date feature enhancements.
Install the Universal Broker Plugin to Horizon Pods
Configure Unified Access Gateways Tied to Horizon Pod
If you are using Unified Access Gateway, follow the procedure outlined in to configure the JSON Web Token settings in each Unified Access Gateway instance to support the tunnel server and protocol redirection required by Universal Broker.
Configure Sites for your Horizon Pods
A site is a collection of cloud-connected pods in the same physical location, typically in a single data center.
Each pod must be associated with a site before it can participate in multi-cloud assignments brokered by Universal Broker. When you select Universal Broker as the brokering method for your Horizon Cloud pods in Microsoft Azure, it creates a default site called Default-Site. Participating Horizon Cloud pods in Microsoft Azure are automatically added to the Default-Site. Later, you can configure new sites and move pods from the Default-Site to a configured site.
You can use the Sites tab on the Capacity page to configure sites for Universal Broker. When you change a Horizon pod on a VMware SDDC-based platform from monitored to managed state, you are prompted to associate the pod with a new or existing site. For more details, see .
Configure Home Sites for your Users
You can also associate a user or a group of users with a specific site, called a home site. Home sites are the default site selected for each user or group of users that Universal Broker will try to service resource requests from. For more details, see .
Sites can serve as a useful part of a disaster recovery solution. For example, you can add pods in different data centers to different sites and entitle users and groups to an assignment that spans those sites. If a data center in one site becomes unavailable, Universal Broker can identify desktops from an available site to fulfill user requests.
Set up Horizon Pods to be Managed
After you have set up and configured all the necessary prerequisites, you can select which Horizon pods you want to be managed by Universal Broker. Setting a pod to be Managed enables you to leverage more capabilities of the Horizon Control Plane Services, including Universal Broker and Multi-Cloud Assignments.
There are multiple ways to entitle users to resources from different Horizon pods.
Multi-Cloud Entitlements are a feature in Horizon Service that allow you to entitle users to resources across multiple pods residing on the same infrastructure type.
For example, you can set up an entitlement for users to leverage resources from multiple Horizon 7 or Horizon 8 pods. However, you cannot currently entitle users for cross-platform entitlements combining Horizon 7 or 8 and Horizon Cloud on Microsoft Azure pods in a single entitlement.
Multi-cloud assignments do not require multiple pods to work. You can set up a multi-cloud assignment to only leverage a single pod for capacity.
Remember, you cannot entitle users to resources from both Horizon and Horizon Cloud on Microsoft Azure in the same entitlement.
Global Entitlements for Horizon 7 and Horizon 8
Cloud Pod Architecture (CPA) introduces the concept of a global entitlement (GE) through joining multiple Horizon pods together into a federation. Pods can be in the same physical site or location or in different sites and locations. Global Entitlements allow you to provide users and groups with a global entitlement that can contain desktop pools or RDSH-published applications from multiple different pods that are members of this federation construct.
Configure Horizon Pods to use Multi-Cloud Assignments
Multi-Pod Assignments with Horizon on vSphere-based Infrastructures
If you are going to leverage Universal Broker and multi-cloud assignments to provide end users with virtual desktops provisioned by cloud-connected Horizon pods, even from different, vSphere-based, cloud infrastructures, you create a multi-cloud assignment. Assignments created with the Horizon Universal Broker can be configured to leverage capacity from multiple pods to match resources to users. The desktop pools in an assignment can span one or more cloud-connected Horizon pods that are in a managed state.
Multi-Pod Assignments with Horizon Cloud on Microsoft Azure
After Universal Broker is enabled for your Horizon Service account, all Horizon Cloud on Microsoft Azure pods, and only Horizon Cloud on Microsoft Azure pods, can create multi-cloud assignments that leverage capacity from multiple Horizon Cloud on Microsoft Azure pods.
Summary and Additional Resources
This guide covered the Universal Broker, a component of the Horizon Service, and how to start using it in your existing Horizon environment.
- The is a guide to getting started with the Horizon service. This page of curated content will point you to relevant content to help you on your journey.
- The page on Tech Zone contains a list of resources targeted on Universal Broker.
- Documentation on Universal Broker is in the .
- Documentation on each release of VMware Horizon can be found in .
The following updates were made to this guide.
Description of Changes
About the Author and Contributors
This document was written by:
- , Senior Staff Architect, End-User Computing, VMware
- , Staff Technical Marketing Architect, End-User Computing, VMware
- , Staff Technical Marketing Architect, End-User Computing, VMware
- , Director, End-User-Computing Technical Marketing, VMware