Understanding the Transition Process from Single-Pod Broker to Universal Broker

This topic introduces the broker transition process for your Horizon Cloud tenant and the benefits you can gain from performing the transition. Learn about the differences between a single-pod broker and Universal Broker environment and what you can expect before, during, and after the broker transition.

What is the Broker Transition Process?

When you complete the broker transition, your Horizon Cloud tenant environment changes from using single-pod brokering to using Universal Broker to broker resources from your end-user assignments. As the new tenant-wide broker, Universal Broker manages your users' connection requests and routes them to the best available resource from the requested assignment.

The broker transition process makes the following changes to your end-user assignments.

• VDI desktop assignments are converted to multi-cloud assignments brokered by Universal Broker. A multi-cloud assignment can include VDI desktops from multiple pods.
• Session-based desktop and application assignments remain unchanged. A session-based desktop or application assignment can include resources from a single pod only, but the assignment is now brokered by Universal Broker.

The transition feature is available to you if your environment currently uses single-pod brokering and meets the prerequisites described in Horizon Cloud - System Requirements for Transitioning to Universal Broker.

Why Should You Make the Transition to Universal Broker?

When you transition to using Universal Broker, you gain the following key benefits.

• End-user assignments with VDI desktops from multiple pods

With single-pod brokering, all the desktops in a VDI assignment must come from the same pod. The desktop brokering is done on a per-pod basis.

With Universal Broker, you can create an assignment of VDI desktops from multiple pods, also known as a multi-cloud assignment. An end user can access the assignment and receive a desktop from any pod included in that assignment. For more information, see Introduction to Horizon Service Universal Broker and its subtopics.

You can also continue to use your session-based desktop and application assignments as before. The difference is that the session-based desktops and applications from these assignments will be brokered by Universal Broker instead of a per-pod brokering.

• Single connection FQDN for all remote resources

With single-pod brokering, end users must connect to each pod's fully qualified domain name (FQDN) individually to access assignments from that pod. The brokering is done on a per-pod basis.

With Universal Broker, users can access all assignments by connecting to just one FQDN, which you define in the Universal Broker configuration settings. Through the single FQDN, users can access assignments from all participating pods — including both Horizon Cloud pods in Microsoft Azure and Horizon pods on a vSphere-based SDDC platform — from any site in your environment. No internal networking between your pods is required.

• 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.

Is There Any Reason Not to Make the Transition?

This release of Universal Broker has a few feature limitations. If your use case requires a feature that Universal Broker does not support, you consider keeping your tenant environment using the single-pod brokering until Universal Broker supports the feature. For a list of the current Universal Broker limitations, see Universal Broker - Feature Considerations and Known Limitations.

What Happens During the Broker Transition?

The transition workflow consists of several stages. For detailed step-by-step instructions on performing the transition, see Schedule and Complete the Transition from Single-Pod Broker to Universal Broker).

Here is a high-level overview of the processes that occur before and during the transition.

1. To initiate the workflow, you must first schedule a date and time for the transition to take place. Along with this scheduling task, you define the configuration options that will be used to set up the Universal Broker service during the transition.
2. At least 15 minutes before the scheduled start time, complete all in-progress operations in the console and save any changes that you want to keep. Close all configuration wizards and dialog boxes. Also, ensure that all your pods in Microsoft Azure are online and in a healthy, ready state.
3. When the transition is about to start, you are prompted to log out from the console and log in again.
4. During the first stage of the transition, you can expect the following:

• 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 will be 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 up to one hour if your tenant environment contains a high number of assignments.

When this stage of the transition is complete, you are prompted to log out from the console and log in again.

5. During the second stage of the transition, the Universal Broker service completes its setup process and becomes fully enabled. You can access all edit operations in the console except for creating and editing assignments.

Note: This stage of the transition typically takes up to 30 minutes. However, depending on your system and network conditions and the total number of assignments and dedicated user-to-desktop mappings in your environment, this stage can take several hours to complete.

When this stage of the transition is complete, the Settings > Broker page shows the Enabled status with a green dot.

At this point, the overall broker transition is complete.

What Can You Expect After the Broker Transition?

For a detailed list of the changes made to your tenant environment after the broker transition, see What's New in Your Tenant Environment After the Transition to Universal Broker.

After you complete the transition, you can start to take advantage of the benefits offered by a Universal Broker environment. The following list provides a short glimpse of what to do next and links to detailed pages.

• 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 allocates resources to your users. For detailed information, see Creating and Managing Assignments in Your Universal Broker Environment and Working with Sites in a Universal Broker Environment.
• If you have an existing integration between your Horizon Cloud tenant and Omnissa 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 Omnissa Access and Intelligent Hub Services.

Note: As confirmed by the Access product team, when Universal Broker is used with your Horizon Cloud on Microsoft Azure deployments, the Access product's Virtual Apps Collections feature is unsupported with that configuration. The reason is because Universal Broker is the more modern brokering technology than the old-style per-pod brokering, which means the integration of Universal Broker with Access supersedes the use of the legacy per-pod Virtual Apps Collections for Horizon Cloud on Microsoft Azure deployments. Therefore, Universal Broker does not have a concept of Virtual Apps Collections for Horizon Cloud on Microsoft Azure deployments at all, which makes use of Virtual Apps Collections with the Universal Broker and Horizon Cloud on Microsoft Azure configurations as not supported.

When Universal Broker is configured for your Horizon Cloud on Microsoft Azure deployments and you plan to use Access and Intelligent Hub services with those Horizon Cloud on Microsoft Azure deployments, in the integration process as part of the console's Clean Up action, you will be required to clean up any existing Virtual Apps Collections those deployments might have. Completing the clean-up activities will make the same apps continue to work in Access and Intelligent Hub services by using the modern features of the integrated Universal Broker and Access and Intelligent Hub services.

Horizon Cloud - System Requirements for Transitioning to Universal Broker

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 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 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.

• 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.

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 system-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	In the configuration stage of the transition scheduling process, designate the pod's existing FQDN as the custom FQDN for the Universal Broker service. Schedule the transition for a date and time that will cause minimal disruption to your end users' assignment workloads. 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. Shortly before the transition, assign a new IP address and FQDN to the pod. 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	Update your runbooks to include the necessary procedures to follow before, during, and after the transition process. In the configuration stage of the transition scheduling process, configure the new FQDN for the Universal Broker service. 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. 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. 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. 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.

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 Omnissa Provided or Custom fully qualified domain name (FQDN).

2. Specify additional settings for the selected FQDN type.

• If you selected the Omnissa 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 system-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.firstgen.omnissahorizon.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 system-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 system-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.firstgen.omnissahorizon.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.
Omnissa Provided FQDN	This read-only field displays the system-provided FQDN that is automatically generated for the brokering service. The FQDN takes the format https://auto-generated-string.firstgen.omnissahorizon.com. This system-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 this system-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 system-provided FQDN. For example, the record might map vdi.examplecompany.com to auto-generated-string.firstgen.omnissahorizon.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 Define 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 Horizon Cloud Support. Note that Horizon Cloud 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 vSphere-based SDDC 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, Horizon Cloud 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 Horizon Cloud 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, open a support request as described in KB article 2006985.

What to do next

• If you have an existing integration between your Horizon Cloud tenant and 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 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.

What's New in Your Tenant Environment After the Transition to Universal Broker

This article describes the changes that you can expect to see in your Horizon Cloud tenant environment after you successfully complete the transition from Single-Pod Broker to Universal Broker. The changes include some new feature behavior and some feature limitations.

For more information about certain feature limitations in a Universal Broker environment, see Universal Broker - Feature Considerations and Known Limitations.

Changes to End-User Assignments

• All your pods in Microsoft Azure are added to a site named Default-Site.
• 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.

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.

Important: If a user previously received multiple assigned desktops from a dedicated assignment in a Single-Pod Broker environment, they cannot access these desktops after the transition to a Universal Broker environment. To access the assigned desktops, the user can connect directly to the pod's FQDN instead of using the Universal Broker FQDN.

• Session-based desktop and application assignments are now brokered by Universal Broker.

Changes to Desktop Pools with Identical Names

If any desktop pools across your pods had the same name before the broker transition, they are edited to have distinct names. This change ensures that you can add uniquely named desktop pools from different pods to a single assignment brokered by Universal Broker.

For example, suppose that you had the following scenario before the broker transition:

• Pod1 contained a pool named TestPoolName.
• Pod2 contained a pool also named TestPoolName.

After the transition, the example pool names change as follows:

• In Pod1, the pool name stays TestPoolName.
• In Pod2, the pool is renamed to TestPoolName1.

Changes to the VM Names Prefix

In a Single-Pod Broker environment before the transition, the VM names prefix of a pool can have a maximum of 11 customizable characters. To form the pool name, a sequential number (with a maximum of four digits) is appended to the 11-character prefix.

After the transition to Universal Broker, the VM names prefix can consist of at most nine customizable characters. Any VM names prefixes that were previously longer than nine characters are automatically truncated after the transition.

To form the pool name in a Universal Broker environment, the following characters are appended to the nine-character prefix: two random alphanumeric or alphabetic characters, followed by a sequential number (with a maximum of four digits).

If multiple assignments use the same VM names prefix, you can encounter an error when you attempt to edit one of the assignments. To resolve the error, change the VM names prefix of the assignment in the Edit wizard.

Note: If a desktop pool is configured with the Max Desktops option set to 0, the VM name prefix and pool name appear unchanged in the Horizon Universal Console after the transition. To update the console to display the new VM name prefix and pool name, make an update to the transitioned assignment using the Edit wizard.

Feature Considerations After the Transition

The following considerations apply to certain features after the transition to Universal Broker.

• Customization assignments (also known as URL Redirection assignments) are not supported.
• The task cancelation feature is not supported if your pods are running at earlier than manifest 2474.0. To use this feature, you must upgrade your pods to manifest 2474.0 or later.
• If the Horizon Cloud on Microsoft Azure deployments have an existing pre-transition integration with Access, then you must update the integration to a post-transition state to accommodate the use of Universal Broker. For complete instructions, see Horizon Cloud Environment with Universal Broker - Integrate the Tenant with Omnissa Access and Intelligent Hub Services.

Please note that when you update that integration, you will be required to use the Horizon Universal Console Clean Up workflow to clean up any existing Virtual Apps Collections those deployments might have. The clean-up workflow will make the same apps continue to work in Access and Intelligent Hub services by using the modern features of the integrated Universal Broker and Access and Intelligent Hub services instead of the legacy, per-pod Virtual Apps Collections feature. As confirmed by the Access product team, when Universal Broker is used with your Horizon Cloud on Microsoft Azure deployments, the Access product's Virtual Apps Collections feature is unsupported with that configuration. The reason is because Universal Broker is the more modern brokering technology than the old-style per-pod brokering, which means the integration of Universal Broker with Access supersedes the use of the legacy per-pod Virtual Apps Collections. Therefore, Universal Broker does not have a concept of Virtual Apps Collections for Horizon Cloud on Microsoft Azure deployments at all.

Important: The deletion protection feature for inventory outages is not supported if your pods are running at earlier than manifest 2474.0. To use this feature, you must upgrade your pods to manifest 2474.0 or later.

For example, if your pods were running at earlier than manifest 2474.0 and had deletion protection enabled before the transition, the feature ceases to function after the transition. If you then upgrade your pods to manifest 2474.0 or later, the deletion protection feature becomes functional again.