Schedule and Complete the Transition from Single-Pod Broker to Universal Broker

This topic guides you through the steps of scheduling, preparing for, and completing the transition to Universal Broker. Refer to the following procedure to learn how to set up the Universal Broker service, define a start date and time for the transition, and smoothly navigate the stages of the process for a successful transition.

A notification banner with a Schedule button appears at the top of the Horizon Universal Console when the broker transition is ready to be scheduled.

Note: If the banner shows an error condition preventing the transition from being scheduled, you have likely failed to meet one or more of the prerequisites for the transition. Click View Errors in the banner and then click the error icon next to the Transition Required link in the Broker page to view details about the error condition. You must take the necessary steps to clear the error condition before you can schedule the transition.

Prerequisites

Verify that your tenant environment meets all the prerequisites outlined in Horizon Cloud - System Requirements for Transitioning to Universal Broker.

Procedure

1. Click Schedule in the notification banner for the broker transition.
   
   
   
   This action redirects you to the Broker page. The page indicates that Single-Pod Broker is currently enabled for your tenant and provides a link for scheduling the broker transition.

   
   
   
2. In the Broker page, click the Schedule link.
   The configuration wizard for Universal Broker appears. You must complete the steps of this wizard to set up Universal Broker for your pods in Microsoft Azure and to schedule the transition to Universal Broker.

   
   
   
3. In the FQDN page of the wizard, configure the settings for your brokering connection FQDN. These settings define the dedicated connection address that your end users use to access resources allocated by Universal Broker.
   Note: When you modify a subdomain or FQDN setting, it can take some time for the change to take effect across all your DNS servers.
   1. For Type, select either a VMware Provided or Custom fully qualified domain name (FQDN).
   2. Specify additional settings for the selected FQDN type.
      • If you selected the VMware Provided type, specify settings as follows.

        Setting	Description
        Sub Domain	Enter the unique DNS name of a valid subdomain in your network configuration that represents your company or organization. This subdomain is prefixed to the VMware-provided domain to form the brokering FQDN. Note: Some strings are disallowed or reserved by the system. This category of strings includes generic words like book, well-known company-owned terms like gmail, and protocol. coding, and open-source terms like php and sql. The system also disallows a category of patterns of those strings such as mail0, mail1, mail2, and so on. However, when you type a disallowed name into this field, the system does not validate the entry at that time. Only when you reach the wizard's final summary step does the system validate the name you typed here and display an error if your entry matches one of the disallowed names. If that happens,enter a different and more unique name here.
        Brokering FQDN	This read-only field displays the configured FQDN. The FQDN uses the format https://<your sub-domain>vmwarehorizon.com. Provide this FQDN to your end users to allow them to connect to the Universal Broker service using Horizon Client. Universal Broker manages the DNS and SSL validation of this FQDN.

      • If you selected the Custom type, specify settings as follows.

        Setting	Description
        Brokering FQDN	Enter the custom FQDN that your end users will use to access the Universal Broker service. Your custom FQDN functions as an alias to the automatically generated VMware-provided FQDN that completes the connection to the service. You must be the owner of the domain name specified in your custom FQDN and provide a certificate that can validate that domain. Note: Your custom FQDN, also known as the connection URL, represents your company or organization. Ensure that you have the proper authorization to use this custom FQDN. Note: Your custom FQDN must be unique and distinct from the FQDNs of all Unified Access Gateway instances within your pods. Important: You must create a CNAME record on your DNS server that maps your custom FQDN to the VMware-provided FQDN representing the internal connection address of the Universal Broker service. For example, the record might map vdi.examplecompany.com to <auto-generated string>.vmwarehorizon.com .
        Certificate	Click Browse and upload the certificate (in password-protected PFX format) that validates your brokering FQDN. The certificate must meet all of the following criteria: Certificate must be valid for at least 90 days Certificate must be signed by a trusted CA Either the certificate's Common Name (SN) or any of its Subject Alternative Names (SANs) must match the FQDN Certificate's content must conform to standard X.509 format The PFX file must contain the entire certificate chain and the private key: domain certificate, intermediate certificates, root CA certificate, private key. The Universal Broker service uses this certificate to establish trusted connection sessions with clients.
        Password	Enter the password for the PFX certificate file.
        VMware Provided FQDN	This read-only field displays the VMware-provided FQDN that is automatically generated for the brokering service. The FQDN takes the format https://<auto-generated string>.vmwarehorizon.com. The VMware-provided FQDN is not visible to end users and represents the internal connection address of the Universal Broker service. Your custom FQDN functions as an alias to the VMware-provided FQDN. Important: You must set up an alias association by creating a CNAME record on your DNS server that maps your custom FQDN to the VMware-provided FQDN. For example, the record might map vdi.examplecompany.com to <auto-generated string>.vmwarehorizon.com .

        
        

        

        
        
   3. When you are finished configuring the FQDN settings, click Next to proceed to the next page of the wizard.
4. (Optional) In the Authentication page of the wizard, configure two-factor authentication.
   By default, Universal Broker authenticates users solely through their Active Directory user name and password. You can implement two-factor authentication by specifying an additional authentication method. For more information, see Best Practices When Implementing Two-Factor Authentication in a Universal Broker Environment.
   Important: To use two-factor authentication for Universal Broker, you must first configure the appropriate authentication service on each external Unified Access Gateway instance within every participating pod. The configurations of external Unified Access Gateway instances must be identical within and across participating pods.

   For example, if you want to use RADIUS authentication, you must configure the RADIUS service on each external Unified Access Gateway instance across all participating Horizon pods and pods in Microsoft Azure.

   Do not delete any Unified Access Gateway instances within the participating pods. Since Universal Broker relies on Unified Access Gateway for the protocol traffic between Horizon Client and virtual resources, users cannot access provisioned resources from a participating pod if you delete the Unified Access Gateway instance on that pod.

   Setting	Description
   Two-Factor Authentication	To use two-factor authentication, enable this toggle. When you enable the toggle, you are presented with additional options for configuring two-factor authentication.
   Maintain User Name	Enable this toggle to maintain the user's Active Directory user name during authentication to Universal Broker. When enabled: The user must have the same user name credentials for the additional authentication method as for their Active Directory authentication to Universal Broker. The user cannot change the user name in the client login screen. If this toggle is turned off, the user is allowed to type a different user name in the login screen.
   Type	Specify the authentication method that the Universal Broker should use with the end users in addition to the Active Directory user name and password. The user interface displays two choices RADIUS and RSA SecurID. This setting applies tenant wide. The behavior in the end-user client will depend on the composition of the tenant's pod fleet and which two-factor authentication type is configured on the pods' gateways, as follows: Horizon pods only The type you select here is the one used in the client. Horizon Cloud pods only Select the type that matches the one that is configured on the pods' external gateways. Mixture of Horizon pods and Horizon Cloud on Microsoft Azure deployments In a blended fleet, when RADIUS is selected here, users' RADIUS authentication requests are attempted through the Unified Access Gateway instances of both pod types. In a blended fleet, when RSA SecurID is selected here, the client behavior depends on whether your Horizon Cloud on Microsoft Azure deployments are configured with RSA SecurID on their external gateways. If your Horizon Cloud on Microsoft Azure deployments do not have RSA SecurID type configured on their gateways, and RSA SecurID is selected here, users' RSA authentication requests are attempted through the Unified Access Gateway instances of your Horizon pods only. The Active Directory user name and password authentication requests are attempted through the Unified Access Gateway instances of either Horizon pods or Horizon Cloud pods. If your Horizon Cloud on Microsoft Azure deployments have the RSA SecurID type configured on them, then users' RSA authentication requests are attempted through the Unified Access Gateway instances of both pod types.
   Show Hint Text	Enable this toggle to configure a text string that displays in the client login screen to help prompt the user for their credentials to the additional authentication method.
   Custom Hint Text	Enter the text string that you want to display in the client login screen. The specified hint appears to the end user as Enter your DisplayHint user name and password, where DisplayHint is the text string you enter in this text box. Note: Universal Broker does not allow the following characters in the custom hint text: & < > ' " If you include any of these disallowed characters in the hint text, user connections to the Universal Broker FQDN will fail. This hint can help guide users to enter the correct credentials. For example, entering the phrase Company user name and domain password below for results in a prompt to the end user that states: Enter your Company user name and domain password below for user name and password.
   Skip Two-Factor Authentication	Enable this toggle to bypass two-factor authentication for internal network users connecting to the Universal Broker service. Ensure that you have specified the public IP ranges belonging to your internal network, as described in Definte Internal Network Ranges for Universal Broker. When this toggle is enabled, internal users must enter only their Active Directory credentials to authenticate to the Universal Broker service. External users must enter both their Active Directory credentials and their credentials for the additional authentication service. When this toggle is turned off, both internal and external users must enter their Active Directory credentials and their credentials for the additional authentication service.
   Public IP Ranges	This field is visible when Skip Two-Factor Authentication is enabled. When one or more public IP ranges are already specified on the Broker page's Network Ranges tab, this field is read-only and lists those IP ranges. When the Broker page's Network Ranges tab does not have public IP ranges already specified, you can use this field to specify the public IP ranges that represent your internal network, for the purpose of skipping the two-factor authentication prompts for traffic coming from those ranges. Universal Broker considers any user connecting from an IP address within one of these ranges to be an internal user. For more details about the purpose of specifying these ranges, see Define Internal Network Ranges for Universal Broker.

   When you are finished configuring two-factor authentication, click Next to proceed to the next page of the wizard.
5. In the Settings page of the configuration wizard, configure Durations settings for Horizon Client.
   These timeout settings apply to the connection session between Horizon Client and the assigned desktop allocated by Universal Broker. These settings do not apply to the user's login session to the guest operating system of the assigned desktop. When Universal Broker detects the timeout conditions specified by these settings, it closes the user's Horizon Client connection session.

   Setting	Description
   Client Heartbeat Interval	Controls the interval, in minutes, between Horizon Client heartbeats and the state of the user's connection to Universal Broker. These heartbeats report to Universal Broker how much idle time has passed during the Horizon Client connection session. Idle time is measured when no interaction occurs with the end-point device running Horizon Client. This idle time is not affected by inactivity in the login session to the guest operating system that underlies the user's assigned desktop. In large desktop deployments, increasing the Client Heartbeat Interval might reduce network traffic and improve performance.
   Client Idle User	Maximum idle time, in minutes, allowed during a connection session between Horizon Client and Universal Broker. When the maximum time is reached, the user's authentication period expires, and Universal Broker closes all active Horizon Client sessions. To reopen a connection session, the user must reenter their authentication credentials on the Universal Broker login screen. Note: To avoid disconnecting users unexpectedly from their assigned desktops, set the Client Idle User timeout to a value that is at least double that of the Client Heartbeat Interval.
   Client Broker Session	Maximum time, in minutes, allowed for a Horizon Client connection session before the user's authentication expires. The time starts when the user authenticates to Universal Broker. When the session timeout occurs, the user can continue to work in their assigned desktop. However, if they perform an action (such as changing settings) that requires communication with Universal Broker, Horizon Client prompts them to reenter their Universal Broker credentials. Note: The Client Broker Session timeout must be greater than or equal to the sum of the Client Heartbeat Interval value and the Client Idle User timeout.
   Client Credential Cache	Controls whether to store user login credentials in the client system cache. Enter 1 to store user credentials in the cache. Enter 0 if you do not want to store user credentials in the cache.

   When you are finished configuring the Durations settings, click Next to proceed to the next page of the wizard.
6. In the Schedule page of the wizard, use the controls to specify a Date and Start Time for the broker transition to take place.
   
   

   

   
   
   You can schedule a start time that is at least one hour ahead of your current local time and up to 3 months ahead of the current date. The start time must occur at the top of the hour.
   When setting the start time, allow enough time for the transition to proceed without interruption.
   When you are finished, click Next to proceed to the next step of the Universal Broker configuration wizard.
   Note: If the console displays a message stating that your specified start time is unavailable, return to the Date and Start Time settings to specify a different time for your transition.
7. Review your settings in the Summary page, and then click Finish to save the Universal Broker configuration and the schedule settings.
   A message appears confirming that you have successfully scheduled the transition.
   
   

   

   
   
   After the transition is scheduled:

   • The Broker page displays details about the upcoming transition. If the start time is more than one hour away, you can reschedule the transition by clicking the Schedule link.
   • If you want to cancel a scheduled transition or reschedule a transition that is starting in less than an hour, you must contact VMware Support. Note that VMware Support cannot cancel or reschedule a transition that is starting in less than 15 minutes.
   • The console continues to display a notification banner about the upcoming transition until the start time is reached. Clicking View Details in the banner redirects you to the Broker page.
   • Notification and reminder messages about the upcoming transition are sent to the primary email account registered for your tenant.
8. Ensure that you complete the following preparation tasks at least 15 minutes before the transition is scheduled to start. During the transition, you cannot access any of the console's edit operations.
   • Complete all in-progress operations in the console and save any changes that you want to keep.
   • Close all configuration wizards and dialog boxes.

   Important: Ensure that all your Horizon Cloud pods in Microsoft Azure are online and in a healthy, ready state for the duration of the transition. The Universal Broker service must communicate with the pods and perform some configuration steps on the pods to complete the broker enablement stage of the transition. If any of the pods are offline or unavailable, the transition fails.

   Important: If you have a hybrid environment consisting of both Horizon Cloud pods in Microsoft Azure and Horizon pods on a VMware SDDC-based platform, the Universal Broker service is unavailable for your Horizon pods for the duration of the transition. Also, you cannot change the state of a Horizon pod from monitored to managed during this time.
9. Shortly before the transition begins, follow the instructions in the on-screen prompt to log out from the console and log in again.
   
   

   

   
   
10. Allow the first stage of the transition to proceed without interruption.
    During this stage of the transition:

    • You cannot access any of the console's editing controls and the console displays a banner stating that the transition is in progress.
      
      
      
      
    • All your pods in Microsoft Azure are added to a site named Default-Site.
    • Your VDI desktop assignments are converted to multi-cloud assignments brokered by Universal Broker. In the default assignment settings, the connection affinity is set to Nearest Site and the scope is set to Within Site.
    • Your session-based desktop and application assignments remain unchanged. After the transition, the resources in these assignments are brokered by Universal Broker.
    • All assignments remain available to your end users and all active user sessions remain open and fully operational during this time.
    Note: This stage of the transition typically takes around 10 minutes, but can take longer if your tenant environment contains a large number of assignments. You can monitor the progress by clicking View Status in the notification banner. If this stage does not complete within one hour, the transition times out and is marked as a failure.

    The following message appears when this stage of the transition is complete.
    

    

    
    

    Note: If a failure occurs during this stage of the transition, VMware Support receives an automatic notification and will investigate and remediate the cause of the failure. You can view more information in the Broker page and in the notification messages sent to the primary email account registered for your tenant. After VMware Support remediates the cause of the failure, you can use the link in the Broker page to reschedule the transition.
11. After you log back in to the console, allow the Universal Broker service to complete its setup process and become fully enabled.
    It typically takes up to 30 minutes for the configuration settings to take full effect in the Universal Broker service, as DNS records are propagated across the DNS servers in all global regions. However, depending on your system and network conditions and the total number of assignments and dedicated user-to-desktop mappings in your environment, this process can take several hours to complete. If the process does not complete within four hours, the transition times out and is marked as a failure.

    During this stage of the transition, you can access all edit operations in the console except for creating and editing assignments. Also, the Universal Broker service is unavailable during this time for the brokering of assignments.

    When the setup is completed successfully, a notification message appears in the console under the bell icon and the Settings > Broker page shows the Enabled status with a green dot.

    Your assignments are now brokered by Universal Broker and the transition is complete.

    
    
    

    Important: If the Universal Broker setup fails, the Settings > Broker page shows the Error status with a red alert icon. To remediate the configuration failure and set up the Universal Broker service, contact VMware Support as described in VMware Knowledge Base (KB) article 2006985.

What to do next

• If you have an existing integration between your Horizon Cloud tenant and Workspace ONE Access, you must update the integration to accommodate the use of Universal Broker. For complete instructions, see Horizon Cloud Environment with Universal Broker - Integrate the Tenant with Workspace ONE Access and Intelligent Hub Services.
• Modify your site and multi-cloud VDI assignment settings to make full use of the Universal Broker capabilities. For example, you can add more pods to an existing assignment or adjust the site settings to fine-tune how Universal Broker brokers assignments. For detailed information, see Creating and Managing Multi-Cloud Assignments in Your Horizon Cloud Tenant Environment and Working with Sites in a Universal Broker Environment.