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.
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 Workspace ONE 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 Workspace ONE 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 Workspace ONE Access and Intelligent Hub Services by using the modern features of the integrated Universal Broker and Workspace ONE Access and Intelligent Hub Services instead of the legacy, per-pod Virtual Apps Collections feature. As confirmed by the VMware Workspace ONE Access product team, when Universal Broker is used with your Horizon Cloud on Microsoft Azure deployments, the VMware Workspace ONE 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 Workspace ONE 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.
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.
