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.

Caution: If your tenant's pod fleet contains a mix of Horizon pods already using Universal Broker and Horizon Cloud pods using single-pod brokering, you must take special consideration to make the two-factor authentication settings in the already configured Universal Broker settings match with the Horizon Cloud pods.
  • 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.
    • 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.
    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.
  • 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.
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.

DNS, Ports, and Protocol Requirements to Support Universal Broker

Verify the following requirements.

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.

Note: If you choose to configure a custom FQDN, bear in mind that this FQDN represents your company or organization. Ensure that you are the owner of the domain name specified in the custom FQDN, can provide a certificate that validates that domain, and have the proper authorization to use the custom FQDN. The custom FQDN for Universal Broker must be unique and distinct from the FQDNs of all the Unified Access Gateway instances within your pods.

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
  1. During the configuration stage of the transition scheduling process, designate the pod's existing FQDN as the custom FQDN for the Universal Broker service.
  2. Schedule the transition for a date and time that will cause minimal disruption to your end users' assignment workloads.
  3. Notify and prepare your end users for the upcoming transition. Remind them to save their work and log out from their active connection sessions as the transition time approaches.
  4. Shortly before the transition, assign a new IP address and FQDN to the pod.
  5. After the transition is complete, inform your end users that they can resume their connection sessions using the pod's former FQDN which is now the Universal Broker FQDN.
Your environment consists of multiple pods and you want to configure a new FQDN as the Universal Broker FQDN
  1. Update your runbooks to include the necessary procedures to follow before, during, and after the transition process.
  2. During the configuration stage of the transition scheduling process, configure the new FQDN for the Universal Broker service.
  3. Schedule the transition for a date and time that will cause minimal disruption to your end users' assignment workloads. Allow adequate time for user training and the reconfiguration of client software, in accordance with the scale of your pod deployments.
  4. Notify and prepare your end users for the upcoming transition. Remind them to save their work and log out from their active connection sessions as the transition time approaches.
  5. During or shortly after the transition, reconfigure Horizon Client on your users' client systems to connect to the new Universal Broker FQDN, instead of the individual pods' FQDNs.
  6. Inform your end users that they must now use the new broker connection FQDN and can gain universal access to all the pods in your environment as a result.