This documentation page provides some of the feature considerations related to Universal Broker and a list of the Horizon features that have limited or no support.
- In a pod fleet that contains both Horizon pods and Horizon Cloud pods, each end-user assignment you create must consist of VDI desktops from only one pod type. For example, you can create an assignment consisting of desktops that span multiple Horizon pods or an assignment consisting of desktops that span multiple Horizon Cloud pods. However, you cannot create an assignment consisting of desktops that span a mix of Horizon pods and Horizon Cloud pods.
- Additional considerations apply if you have transitioned your tenant from a single-pod broker configuration to Universal Broker. See What's New in Your Tenant Environment After the Transition to Universal Broker.
Maximum Number of Pods Per VDI Multi-Cloud Assignment Limit
The supported maximum number of pods in a VDI multi-cloud assignment is five (5). This limit applies to both Horizon Connection Server type pods and Horizon Cloud on Microsoft Azure type pods. Using more than five increases the concurrent load on Universal Broker. Increasing that concurrent load can lead to end users encountering failures when they click on the assignment's displayed tile in the client and the service attempts to log in the user to the virtual desktop.
For the brokering of virtual resources, this release of Universal Broker only supports Windows operating systems. Linux-based desktops are not supported.
This release does not support administrator-created shortcuts to desktops and applications.
Horizon HTML Access and Horizon Client for Chrome
End users can make requests for resources to the Universal Broker service by running Horizon HTML Access in a supported web browser or by running Horizon Client for Chrome 5.4 or later. If the Universal Broker service redirects the request to a Unified Access Gateway instance that uses a self-signed certificate, the client application displays an error message indicating that the certificate authority is invalid.
This behavior is according to design. To connect to the requested resource, the user can accept the self-signed certificate by following the prompts in the certificate error message.
This release of Universal Broker supports client user authentication through Windows user name and password, in UPN and NETBIOS formats.
Two-factor authentication through RADIUS or RSA is also supported, depending on the current state of the tenant's pod fleet, as in the following list.
Also review the following section that describes the end-user experience when using Universal Broker in their clients and two-factor authentication is configured. The current behavior is different from the behavior when using a pod's gateway FQDNs directly.
- Horizon pods only
- Both RADIUS and RSA SecurID authentication are supported.
- Horizon Cloud on Microsoft Azure deployments only
- If all pods are manifest 3139.x or later and both the RSA SecurID and RADIUS options are visible for selection when you run the Edit Pod wizard on the pods, then both RSA SecurID and RADIUS authentication are supported. Otherwise, only RADIUS type is supported.
- Mixture of Horizon pods and Horizon Cloud on Microsoft Azure deployments
In a blended fleet, the supported authentication types depend on whether your
Horizon Cloud on Microsoft Azure deployments meet the conditions to have the RSA SecurID option configured on them:
- If your Horizon Cloud on Microsoft Azure deployments do not meet those conditions, then only RADIUS authentication is supported.
- If your Horizon Cloud on Microsoft Azure deployments meet those conditions, then both RADIUS and RSA SecurID authentication are supported.
The conditions to meet are the pods are running manifest 3139.x or later and when you open the Edit Pod wizard on the pods, both the RSA SecurID option and RADIUS options are visible for selection.
When Two-Factor Authentication is Configured
When two-factor authentication is involved, your end users will experience one authentication flow when using the Universal Broker FQDN that is slightly different from the flow when using a pod's gateway FQDN directly.
- In the Universal Broker authentication flow, the end users will be prompted to enter their Windows Active Directory (AD) credentials twice: once when they first connect to the Universal Broker FQDN and then again after successfully completing the two-factor authentication with the configured RADIUS or RSA SecurID system.
- When using a pod's gateway authentication flow, the end users will be prompted to enter their Windows Active Directory (AD) credentials once when they first connect to the pod's gateway FQDN.
Currently Unsupported User Authentication and Access Methods
The following user authentication and access methods are not supported currently.
- Smart card
- SAML authentication (outside of integration with VMware Workspace ONE)
- Log in as the current user
- Anonymous access
When one of the unsupported items qualifies for support, its entry will be removed from the preceding list and the announcement of support will be stated in the page titled For Current Customers with Existing Cloud-Connected Pods — About Horizon Cloud Service Releases. In that page, the statement will be listed in the section that corresponds to the release in which the support was added.
Remote Desktop Features
The following features are not supported in this release of Universal Broker:
- URL content redirection
- Session collaboration
The following features are also not supported in this release of Universal Broker:
- Kiosk mode
- Timing profile (for troubleshooting user sessions )
- OPSWAT-based endpoint compliance checks