So that you can have the best success throughout your journey using Horizon Cloud, keep these known limitations in mind.

All Deployment Types

  • Every pod associated with your Horizon Cloud tenant and connected to Horizon Cloud must have line of sight to the same set of Active Directory domains. If your tenant's pod fleet has a combination of pod types, such as both Horizon 8 and Horizon Cloud types, then in addition to this line-of-sight requirement, a one-way trust or two-way trust is required between all domains registered to that same Horizon Cloud tenant.
    Note: Line of sight in this context means that a given pod must have network access to each domain so that it can reach out to that domain for status checks.
  • The system retrieves the data for the Utilization, Concurrency, Session History, and Top Applications reports once a day, at a specific UTC time. The data for the Utilization and Concurrency reports is retrieved at 2 AM UTC, the data for the Session History report is retrieved at 2:10 AM UTC, and the data for the Top Applications report is retrieved at 2:30 AM UTC. As a result, the reported information that is displayed in the administrative console might not reflect the data collected between the last retrieval time and the time at which you are viewing the reports in the console. As an example, because the logic for the Users and Peak Concurrency data in the Concurrency report is calculated on the daily basis for which the data is retrieved, the data from user activity on April 23 is calculated at the 2 AM UTC time point on April 24 (the following day). After that time point is passed and the system retrieves the collected data, the data from April 23 gets displayed in the report. If one of your end users starts a session after the 2 AM UTC time point on April 23, data for that user's session will not be reflected in the on-screen report until after 2 AM UTC on April 24.

Deployments - Horizon Cloud Pods in Microsoft Azure

A Horizon Cloud pod is the type that is built on the Horizon Cloud pod-manager technology.

  • Due to limitations with how Microsoft Azure VNets handle concurrent subnet creation and deletion operations, running concurrent pod-related operations that require modifying the same VNet at the same time can result in failure to complete those operations. To avoid running into this issue, avoid running pod deployment, pod deletion, or pod edit operations that involve subnets at the same time when those pods are using the same VNet. Here are some examples of concurrent pod-related operations involving modifying the VNet where the chances of experiencing concurrent subnet actions on the VNet can occur, resulting in failures to complete the operations:
    • When you do not create your subnets ahead of time and are having the pod deployer create the subnets using CIDRs, and you initiate creation of two pods concurrently on the same VNet. The subnets are being added to the VNet for both pod creations simultaneously.
    • When one pod is deploying and you initiate deletion of another pod on the same VNet. The subnets are added to the VNet for the deploying pod at the same time the other pod's subnets are being deleted from the same VNet.
    • When you edit a pod to add an external gateway configuration in the pod's VNet using CIDR blocks while another pod is in progress of being deleted. The subnets are added to the VNet for the gateway configuration at the same time the other pod's subnets are being deleted from the VNet.
  • Expanding the size of the pod's subnets after the pod is deployed is not currently supported. Before you deploy a pod, you must ensure the address spaces for the subnets you specify in the deployment wizard are large enough to accommodate your expected usage.
    Note: To workaround this limitation, a new feature made available in pods of manifest 2298.0 and later provides for adding tenant subnets for use by your farms and VDI desktops assignments after the pod is deployed. This feature provides for flexibility to add tenant subnets located in the pod's same VNet or in a peered VNet for use by your farm and desktop VMs after the pod is deployed. For more details, see the Administration Guide.
  • Multiple pods cannot share the same fully qualified domain name that is set on their Unified Access Gateway configurations. Each pod configured with Unified Access Gateway instances needs its own unique fully qualified domain name (FQDN). The FQDN cannot contain underscores.
    Note: As of the December 15, 2020 cloud plane refresh, having different FQDNs for the pod's external gateway and internal gateway configurations is supported. Prior to December 15, 2020, the system enforced having the same FQDN for a pod of manifest 2298 and later. Now it is your choice if you want the pod's gateways to use different FQDNs or the same FQDN. If you want to use the same FQDN on both gateways, after pod deployment, you would configure Split DNS (Split Domain Name System) to resolve the gateway address either to the external gateway or internal gateway depending on the origin network of the end-user client's DNS query. Then the same FQDN used in the end-user client can route to the external gateway when the client is on the Internet and route to the internal gateway when the client is on your internal network.
  • Editing or updating of the proxy settings on a pod after the pod is deployed in Microsoft Azure is currently unsupported. Also, adding a proxy configuration to a deployed pod that was deployed without proxy settings is currently unsupported.
  • The NSX Cloud capabilities in this release are not supported for Microsoft Windows Server 2019.
  • When you deploy a Horizon Cloud pod in Microsoft Azure after you have already configured True SSO for previously deployed pods, the system does not automatically pair the new pod with the Enrollment servers. You must manually repeat the steps to export the pairing bundle and import it into the Enrollment servers. For the steps, see the topic Configure True SSO for Use with Your Horizon Cloud Environment and its subtopics.
  • In workflows that result in the system creating VMs, such as creating farms, images, and assignments, if you try to enter a name that is longer than length supported by the system for the to-be-created item, the system prevents you from entering more than the supported number of characters. The number of characters supported for an item's name depends on the workflow.
  • In a Microsoft Azure multi-pod environment, you cannot reuse names that you used in one pod when creating items in another pod. The reason for this limitation is that pods in the multiple-pod environment share the same Active Directory domain and the same VNet. As a result, if names are shared within such multiple-pod environments, unexpected behavior can occur. This limitation applies to names for image, farms, and VDI desktop assignments. Ensure that unique names are used for your images, farms, and VDI desktop assignments.
  • Follow these rules when entering characters in the administrative console:
    • Use only standard ASCII characters in user names and passwords, and for the password when downloading the DaaS SSL bootstrap file. If you use non-ASCII characters for these items, unexpected results might occur.
    • When entering names for imported images, farms, assignments, and other assets that result in creating a VM in Microsoft Azure, do not enter more than 12 characters for the name.
    • Do not use commas in user passwords.
    • When using the Import VM wizard to create a base image VM from the Microsoft Azure Marketplace:
      • Enter a user name and password that adheres to the Microsoft Azure requirements for VM admin user names and passwords. See the Microsoft Azure FAQ page for details.
      • Do not enter a name for the image that ends with a hyphen (-).
      • Do not include an underscore character (_) in the image name.

Updates of Horizon Cloud Pods in Microsoft Azure

  • When the Horizon Infrastructure Monitoring feature is enabled on a pod and the pod is updated via the blue-green update process, the status of the blue pod manager VMs displays as red or inactive for up to 12-14 hours in the Infrastructure dashboard. After 12-14 hours, those blue pod manager VMs are cleared from the Infrastructure dashboard automatically.
  • During the process of updating a pod from an earlier software level to the latest one, end users who have connected sessions to the updating node will have those active sessions disconnected. No data loss will occur – except for the case where the RDSH farm or VDI desktop assignment serving the sessions has the Logoff Disconnected Sessions set to Immediately. For such farms and VDI desktop assignments, the disconnected sessions are also logged off immediately and in-progress user work is lost in those conditions. After the update process is complete, those users can reconnect. The pod update process typically takes less than a half hour. However, some pod updates might take longer.
  • When pods running on manifests prior to the October 2020 release's 2474 manifest are then updated to 2474 or later, if you had used the Microsoft Azure Portal to manually add tags directly on resources or resource groups created by Horizon Cloud in your subscription — such as creating custom tags on the farm or VDI desktop assignments' resource groups — when those pods are then updated, the pod update process does not preserve those custom tags that you had directly added using the Microsoft Azure Portal. Those custom tags will be removed. After the pod update, you must subsequently use the Horizon Universal Console features to edit the farms and VDI desktop assignments to have the system apply those tags on the resource groups for those farms and VDI desktop assignments. Using the console's Azure Resource Tags feature is the supported method of adding resource tags on the pod-created resource groups for farms and VDI desktop assignments. In each of the following documentation topics, read the descriptions of Azure Resource Tags fields located in them. The same fields are used when editing a farm or VDI desktop assignment.

Imported VMs, Golden Images, Farms, or VDI Desktop Assignments - Horizon Cloud Pods in Microsoft Azure

  • Although the console does not prevent you from using images obtained from origins other than the Azure Marketplace in the console's workflows, use of such images is unsupported. To be supported for use in Horizon Cloud on Microsoft Azure, all imported base images must be built from Windows-based VMs that are sourced from the Azure Marketplace. Even if you try an image obtained from other origins and the console does not prevent you from using it within the console's workflows, use of such images is unsupported.

    Additionally, if a Windows 11 image, it must be sourced directly from the Azure Marketplace and cannot have been subsequently processed. Importing Windows 11 VM from any other sources such as Shared Image Gallery (SIG), Azure Managed Images, Azure VM snapshot, and the like is currently unsupported.

  • Generation 2 Azure VMs are currently supported for use only with Windows 11 single-session operating systems and with Windows 11 Enterprise multi-session operating systems.
  • Currently, the Azure GPU-capable NVv4 VMs that use the AMD Radeon Instinct graphics drivers are supported for use only when they are imported using the custom import method. The custom import method is also referred to as a manual import in this documentation. The automated Import Virtual Machine from Marketplace wizard does not provide this feature currently.

    Also, the service does not currently support use of Windows 11 with these NVv4 VMs and the AMD Radeon Instinct graphics drivers. That use has not been qualified.

  • The service's support for Windows 11 has some known considerations, limitations, and issues. For those details, see Support for Windows 11 Guest Operating System - Considerations, Known Limitations, and Known Issues.
  • Use of True SSO with session desktops, remote applications, or VDI desktops based on images running Windows 10 version 2004, Windows 10 version 20H2, Windows Server version 2004, or Windows Server version 20H2 requires installation of a Microsoft patch on those operating systems. The patch fixes a Microsoft issue that blocks True SSO from authenticating with those operating systems. For details, see VMware KB 79644 which references Microsoft Update KB4598291.
  • Use of the disk encryption feature for farms and VDI desktop assignments is not currently supported for pods in Microsoft Azure Government clouds.
  • Currently, use of the following Horizon Agent features is not supported: VMware Logon Monitor service. By default, the Horizon Agents Installer deactivates the VMware Logon Monitor service in all installations that the installer performs.
  • The USB redirection capability is not supported when using the VMware Horizon Client for Android to access virtual desktops and remote applications served by your Horizon Cloud environment.
  • For GPU-enabled golden images based on server-type operating systems, Microsoft Windows Server versions 2016 and 2019 are recommended to avoid limiting the number of end user sessions. Due to an NVIDIA driver limitation on Windows Server 2012 R2, the maximum number of sessions for each RDS desktop server is 20.
  • If you have an image using Microsoft Windows 10 1709 (RS3) and you want to update it to Windows 10 1803 (RS4) or Windows 10 1809 (RS5), first upgrade that Windows 10 1709 to the latest Horizon Agent version 19.4 before proceeding with upgrading the Windows operating system.
  • By default, when you use the automated Import Virtual Machine from Marketplace wizard to create an image with a Windows 2012 server operating system, the resulting image does not have the Desktop Experience enabled. If you want the resulting image to have the Desktop Experience, you must manually enable the Desktop Experience in the resulting image.
  • If you initiate converting a desktop to an image but cancel before the task finishes, a second attempt to convert the desktop to an image may fail. To avoid this issue, you should power off the desktop and power it on again before attempting to convert it to an image a second time.
  • In a URL redirection customization, URL patterns are treated as case sensitive when they are intercepted by the Horizon Client. For example, URL redirection does not occur for URL patterns specified as *GOOGLE.com and *Google.com, even though the pattern *google.com is redirected. Redirection for the end users does not occur if the specified pattern does not match the actual character case used in the target file systems.

Deployments - Horizon Pods

A Horizon pod is the type that is based on the Horizon Connection Server software. For background information on the various deployment architectures used for Horizon pods, see Horizon Pod Deployment Architectures. For detailed information about the various cloud-plane services, see the administration guide.

The following limitations apply in the current release and are updated as applicable for each Horizon Cloud Service release.

  • The automated update feature of Horizon Cloud Connector is only supported for Horizon pods deployed on premises. To update a Horizon Cloud Connector instance that is paired with a Horizon pod deployed in a cloud environment, follow the instructions in Manually Update the Horizon Cloud Connector Virtual Appliance.
  • The Horizon Image Management Service (IMS) is currently supported for use only with a subset of the Horizon deployment models that are described in VMware Tech Zone's Horizon Reference Architecture. For information about the specific deployment models currently supported by IMS, refer to IMS System Requirements. As more models from the Horizon Reference Architecture are qualified for IMS support, the newly supported ones are added to the list.

Workspace ONE Hub Services and Universal Broker - Integration

  • This feature is available for VMware Workspace ONE® Access™ Cloud only. It is not supported for VMware Workspace ONE Access on premises.
  • With this integration, end users can access their Horizon Cloud desktops and applications from the Hub catalog. Ensure that you configure the required settings for VMware Workspace ONE® Intelligent Hub, as described in Workspace ONE Access - Configure Intelligent Hub for Integration with Horizon Cloud.
  • In this release, this integration supports end-user access using these clients: browser-based Hub catalog, Workspace ONE Intelligent Hub for Windows, and Workspace ONE Intelligent Hub for macOS. The minimum version of the Windows and macOS desktop apps required for this support is 21.05.
  • Password caching is not turned on by default in new Workspace ONE Access tenants. If True SSO is not enabled in your Horizon environment, you can enable password caching to cache users’ passwords so that they are not required to enter their passwords again while starting Horizon Cloud desktops and applications. For more information, see Configuring Password Caching for Virtual Apps (Workspace ONE Access Cloud Only).
  • Access policies set in Workspace ONE Access do not apply to applications and desktops from a Horizon Cloud environment that has Universal Broker enabled.

Horizon Universal Console - Related Caveats and Limitations

  • The console does not fetch the currently effective names of your Active Directory users and groups which are already specified in an assignment's details. When you change the name of a user or group in your Active Directory, the console continues to display the prior name of the user or group in the assignment's details from when that user or group was initially added to the assignment. While editing an assignment and searching for a user or group in the search field, the current effective names of the users or groups are displayed in the console. However, even after saving the updated assignment, you will continue to see the old initial name displayed in the assignment's details. There is no functional impact of this limitation.
  • The Web-based administrative console is not supported in the Apple Safari browser. Some user interface features might not work correctly. In a Mac OS, instead of Apple Safari, you can use Chrome or Firefox browsers.
  • Your authenticated (logged in) session into the console will time out after the time setting that is configured in the console's General Settings page. The default is 30 minutes. If you have at least one cloud-connected pod, you can change the default to a value ranging from 30 minutes to 180 minutes. In most cases, when the configured time is up, the system will automatically explicitly log you out and present a message that you must log back in. However, sometimes the system ends your authenticated session and does not explicitly log you out. When that happens, when performing certain tasks in the console, error messages might be displayed which do not accurately reflect the current state, such as the node deployment wizard fails to validate your subscription entries, values are not displayed in drop-down menus, and the Farms page reports no node is available in which to create a farm and error messages stating "No service_sessions of type identity_node were provided". If you start to see such behavior and you have been using the console for 30 minutes or more, manually log out and then log back in.

Horizon Infrastructure Monitoring - Related Caveats and Limitations

  • Horizon Infrastructure Monitoring is currently unsupported for use with Horizon Cloud on Microsoft Azure pods in Azure China regions because access to the required packages.cloud.google.com site is disallowed from Azure China regions at this time.