This article describes the requirements that your Horizon Cloud tenant environment must meet before you can schedule and complete your tenant's transition from using single-pod brokering to Universal Broker. It also guides you through the planning and preparation steps for supporting the new connection FQDN for Universal Broker.
To support the transition process and the ongoing operations of multi-cloud assignments brokered by Universal Broker after the transition, verify that your tenant environment meets the following requirements.
- Unless your Horizon Cloud pods meet the criteria for minimum pod manifest and enablement of the RSA SecurID option in your tenant environment, those pods only support RADIUS authentication. (For more information, refer to Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.)
- If the Horizon Cloud pods do not meet that criteria to have RSA SecurID configured on their external gateways, if you want to use if you want to use two-factor authentication with all of your pods in your fleet — both Horizon pods and Horizon Cloud pods, then each pod will have to have an external Unified Access Gateway with RADIUS two-factor authentication configured on it.
Requirements for Horizon Cloud Pods
Verify that your Horizon Cloud pods in Microsoft Azure meet the following requirements.
- Your tenant has at least one Horizon Cloud pod. A Horizon Cloud pod is based on the pod-manager technology, that is running in Microsoft Azure.
- All of your tenant's Horizon Cloud pods are running at pod manifest 2298.0 or later. The following requirements also apply for certain use cases.
Important: Ensure that all your Horizon Cloud pods are online and in a healthy, ready state. The Universal Broker service must communicate with those pods and perform some configuration steps on the pods to complete the transition process. If any of those pods are offline or unavailable, you cannot schedule the transition. If you schedule the transition but any of your pods later go offline or become unavailable while the transition is in progress, the Universal Broker setup fails.
- If you have an existing integration between your Horizon Cloud tenant and Workspace ONE Access, all your pods must be running at manifest 2474.0 or later. After completing the broker transition, you must update the integration to accommodate the use of Universal Broker, as described in Horizon Cloud Environment with Universal Broker - Integrate the Tenant with Workspace ONE Access and Intelligent Hub Services.
- If you want to use the task cancellation feature or the deletion protection feature after the broker transition, all your Horizon Cloud pods must be running at manifest 2474.0 or later. These features are not supported if the pods are running at manifests earlier than manifest 2474.0.
- No pod upgrades are scheduled to occur at the same time as the transition.
- The pod's location is configured by selecting a valid location from the menu options in the pod configuration wizard. If the pod's location was configured by typing it manually into a text field, the transition will fail.
Note: This issue involving a manually typed location is more likely to occur for pods that were initially deployed prior to March 2019 (service release 1.9). Starting in the March 2019 release, locations must be selected by menu from values within the system's world city name database.
To reduce the likelihood of running into this scenario where the transition fails due to the pod's configured location, navigate to the console's Capacity page and examine the Location column's value for each Horizon Cloud pod. If the Location column's value looks like it might be a manually typed name, then use the Edit action on the pod, go to the Pod Details step and edit the Location field to set its value to one of the system's city name values.
- During the transition workflow, if your tenant does not already have Universal Broker settings from any Horizon pods in your pod fleet, the console will prompt you for Universal Broker settings. When you are planning to configure the two-factor authentication settings in the Universal Broker settings, each pod must have an external Unified Access Gateway instance and that instance must be configured with the appropriate two-factor authentication type. (For background information, refer to Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.)
The requirements depend on whether your Horizon Cloud pods meet the criteria for having the RSA SecurID type configured on their external gateways:
- When your Horizon Cloud pods meet the criteria for minimum pod manifest and enablement of the RSA SecurID option in your tenant environment, you would configure all the external Unified Access Gateway instances across all pods to use the same authentication service. That includes all of your tenant's Horizon pods that are in managed state. The resulting outcome is to have all using a matching authentication type — all using RADIUS or all using RSA SecurID.
- When the Horizon Cloud pods do not meet that criteria to have RSA SecurID configured on their external gateways, then if you want to use two-factor authentication with all of your pods in your fleet — both Horizon pods and Horizon Cloud pods, you must configure all the external Unified Access Gateway instances across all pods to use the same RADIUS authentication service. That includes all of your tenant's Horizon pods that are in managed state.
DNS, Ports, and Protocol Requirements to Support Universal Broker
Verify the following requirements.
- Each pod is 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.
- Each pod is 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.
FQDN Requirements to Support Universal Broker
With single-pod brokering, end users connect to each pod's fully qualified domain name (FQDN) individually to access assignments from that pod.
After the transition to Universal Broker, users can access any assignment—from any pod in any site in your environment—by connecting to the one FQDN of the Universal Broker cloud service. Universal Broker routes each user request to the individual FQDN of the most appropriate pod that can fulfill the request.
You designate the Universal Broker FQDN in the Universal Broker configuration settings as described in Schedule and Complete the Transition from Single-Pod Broker to Universal Broker. You can create the FQDN by prefixing your valid subdomain to the standard VMware-provided domain, or you can configure a fully custom FQDN.
Planning and Preparing for the Broker Transition
Since the broker transition involves key changes to your networking and assignment workflow, ensure that you take the necessary actions to prepare your environment and users for the new workflow. Refer to the following planning guide for the appropriate preparation and change management steps based on your transition use case.
|Transition Use Case||Planning and Preparation Steps|
|Your environment consists of a single pod and you want to use that pod's existing FQDN as the Universal Broker FQDN||
|Your environment consists of multiple pods and you want to configure a new FQDN as the Universal Broker FQDN||