So that you can have the best success throughout your journey using Horizon Cloud, keep these known limitations in mind.
Limitations that Apply to All Deployment Types
- 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.
- Every pod associated with your Horizon Cloud customer account and connected to Horizon Cloud must have line of sight to the same set of Active Directory domains and have one-way or two-way trust configured along with that line of sight.
- Your authenticated (logged in) session into the Web-based administrative 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 lists, 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.
- 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.
Limitations Related to Deployments of 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:
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 typing in 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 username and password that adheres to the Microsoft Azure requirements for VM admin usernames 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.
Limitations Related to Updates of Horizon Cloud Pods in Microsoft Azure
- 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 than that.
- 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.
- Create a Farm
- Create a Dedicated VDI Desktop Assignment Provisioned by a Single Pod in Microsoft Azure
- Create a Floating VDI Desktop Assignment Provisioned by a Single Pod in Microsoft Azure
- Horizon Cloud Pods in Microsoft Azure - Create a VDI Multi-Cloud Assignment in Your Horizon Cloud Tenant Environment
Limitations Related to Imported VMs, Golden Images, Farms, or VDI Desktop Assignments in Horizon Cloud Pods in Microsoft Azure
- Use of True SSO with session desktops, remote apps, 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, even though the pattern
*google.comis 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.
Limitations Related to Deployments Involving Horizon Pods
A Horizon pod is the type that is based on the Horizon Connection Server software.
- For Horizon pods deployed in Google Cloud VMware Engine (GCVE), the only Horizon Cloud service supported at this time is the subscription license service, also known as the Horizon Universal License.
- 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-hosted SDDC, follow the instructions in Manually Update the Horizon Cloud Connector Virtual Appliance.