This topic lists known issues that you might encounter when using the service and known workarounds, if any.
This documentation topic includes the known issues for Horizon Cloud Connector. However, even though you use the Horizon Cloud Connector to connect Horizon pods to Horizon Cloud, for the known issues for the software running inside those Horizon pods, refer to the release notes at the following locations, according to the pod's Connection Server software version:
- Version 7.13 - available at Horizon 7 Documentation.
- VMware Horizon 8 versions - available at Horizon Documentation.
For Image Management Service (IMS) known issues involving IMS features that are available in production for all Horizon Cloud customers, see the known issues page in Management Horizon Images from the Cloud.
Login Related Known Issues
- Even though you successfully created a password for your My VMware account that contains a backslash (\), logging in to Horizon Cloud using those credentials fails (2595757)
- When you use My VMware credentials to login to Horizon Cloud, passwords which contain a backslash are not supported. To see the list of supported special characters, log in to my.vmware.com and navigate to your profile's Change Password section. That page will display the supported special characters. Workaround: Reset your My VMware account password to a new one and ensure the new one does not contain a backslash (\).
Active Directory Related Known Issues
- Primary bind account lockout is not detected until you perform an action involving Active Directory in the administrative console. (2010669)
- Due to this issue, an administrator logged into the Web-based administrative console will not see a primary bind account lockout notification until an action involving Active Directory is performed in the user interface, such as when searching Active Directory to add users to assignments. The underlying services only detect a locked-out service account when they make a request to talk to Active Directory for either authenticating or searching (user or group). Workaround: None.
- It takes up to 15 minutes for the Web-based administrative console to reflect a lockout or unlocked state of the primary bind domain account. (2009434)
- The system's connection object to Active Directory is cached for 15 minutes. As a result, it might take 15 minutes from the time point when the primary bind account goes to locked state and the system raises the notification to the administrator. Conversely, after the administrator clears the locked-out condition of the account, it might take up to 15 minutes for the system to stop notifying about the now-cleared account. Workaround: None.
- For farms in a pod in Microsoft Azure, reusing the same farm name with a different domain in the same Active Directory forest can lead to domain join failures due to duplicate service provider names (SPNs). (1969172)
Due to a new feature for domain controllers in Microsoft Windows Server 2012 R2 and higher, a duplicate SPN check on the domain controller causes domain join failures. See the Microsoft KB article
- Avoid reusing farm names.
- As described in that Microsoft KB article, turn off duplicate SPN checks in the Active Directory domain.
- When using Azure AD Domain Services, the Active Directory registration workflow fails at the domain join step with an error that the Reset Password permission is lacking. (2218180)
- The Horizon Cloud team has verified that adding the required domain join account permissions works the same when using Azure Active Directory (AD) Domain Services with your pod as for other Active Directory domain deployments. See the Microsoft documentation topic Create an Organizational Unit (OU) on an Azure AD Domain Services managed domain that describes the built-in container AADDC Computers and see also the Important note at the beginning of that topic about enabling password hash synchronization to Azure AD Domain Services. Before setting the permissions on the domain join service account, it is important that you follow the Microsoft documentation about enabling password hash synchronization to Azure AD Domain Services for the domain join service accounts. If you continue to experience a domain join permissions error in the Register Active Directory workflow after following the Microsoft documentation, please contact VMware support and reference problem report number 2218180.
Microsoft Azure Subscription Related Known Issues
- After using the Horizon Universal Console to update the secret key for a pod's Azure subscription settings, the pod manager VMs must be restarted for the new credentials to take effect (2979394, 3007687)
Due to this known issue, after you edit and save the
Application Key setting in the console's Manage Subscription window, the newly entered secret key does not take effect on the pod manager VMs until the management service is restarted in the VMs' operating systems. If the management service is not restarted, API calls used by the service to work with resources in the subscription will begin failing. Workaround: If your pod is in this situation where its subscription secret key needs updating for some reason, such as an approaching or past expiration date, please open a service request for assistance from VMware Support and
Horizon Cloud Operations teams to ensure the sequence of steps is performed successfully. At a high-level, the steps are:
- In the Azure Portal, generate a new secret key.
- In the Horizon Universal Console, follow the standard steps to update the secret key that is used by the pod or pods associated with the old key, as described in the page Change, Modify, and Update the Subscription Information Associated with Deployed Horizon Cloud Pods.
- Ask VMware Support to perform the restart of the management service in both pod manager VMs.
The specific command to restart the management service is not suitable for public posting here because only the VMware teams will be able to run that command. Those teams can reference internal issue 3007687-update-9.
Cloud Connector Related Known Issues
- Certificate expiry issue (3083444)
- A certificate in the Horizon Cloud Connector has been found to have a one-year expiry from the time of deployment of the appliance. When this certificate expires, the Horizon Cloud Connector will no longer be able to contact the Horizon Cloud control plane, rendering inoperable the cloud-based services provided by Horizon Cloud Connector. Please see KB 90505 for more details and steps to remediate.
- The no-proxy host configuration specified in the No Proxy For field when deploying the OVF template is not saved to the deployed appliance (2454245, 2466306, 2467017, DPM-5388)
- This issue is resolved in Horizon Cloud Connector Version 1.6 or later. When running the Deploy OVF Template workflow in your vSphere environment, you have the option to specify a no-proxy host configuration in the No Proxy For field. However, due to this known issue, the entered settings do not get captured in the deployed appliance's configuration files. As a result, the deployed appliance does not honor the specified no-proxy host setting.
Horizon Cloud Pods' Gateway Configuration Related Known Issues
- The Horizon Universal Console feature for enabling syslog server settings in the gateway configuration is switched off by default. (3005985, 3023935, 3026855)
- Due to an identified issue with the system's API call to update the Unified Access Gateway configuration with syslog server information, the previously released feature is switched off from use in the console. Workaround: None.
Universal Broker Related Known Issues
- The Horizon Universal Broker client on the Horizon Cloud Connector does not consume proxy-related updates that you make in the connector appliance after the appliance is initially deployed (HD-35551)
- This issue is resolved in Horizon Cloud Connector Version 1.6 or later. The Horizon Universal Broker client in the connector appliance picks up proxy details during the first-time boot of the appliance. Because the first-time boot runs only during the very first time the appliance is powered on after deploying the OVF template, any subsequent changes to the appliance's proxy configuration settings are not consumed by the Horizon Universal Broker client. Taking this known issue together with the above known issue about the no-proxy configuration during OVF template deployment means that any hosts related to the Horizon Universal Broker cannot be set as non-proxy hosts.
- Error message 'Failed to connect to the Connection Server' is displayed when your Horizon Client or Horizon HTML Access in the browser starts to connect to the Universal Broker (2714266)
This issue affects
Horizon Cloud pods in Microsoft Azure that are running manifest 2632.x, in tenants configured to use Universal Broker for brokering end user desktops. Another manifestation of this issue is you observe both of the following occurring at the same time:
- In the pod details page for the pod where the desktop VM resides, you see the pod manager VM health is reported as Error for all of the pod's pod manager VMs.
- Error message 'This desktop is currently not available. Please try connecting to this desktop again later, or contact your system administrator.' is displayed when the Horizon Client or Horizon HTML Access in the browser starts to connect to the Universal Broker.
For pods at manifest 2747.x and later, this issue is resolved.
Images, Farms, Assignments Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- During the image publishing process, a timeout error occurs and the VM remains powered on, and prevents the publish flow from successfully completing (2954270, 2962049)
This issue is the result of an issue in the Microsoft Azure hypervisor that occurs when running the sysprep step of the publishing process. The issue occurs in some Azure VM models. For additional details, refer to VMware Knowledge Base article
Based on the Microsoft Azure team's recommendation, to provide a resolution for Horizon Cloud customers, the default Azure VM model used by the service's automated Import VM from Marketplace wizard is changed in the service's v2204 release to use the Standard_DS2_v2 model for the automated import of non-GPU Windows 10 VMs (both single-session and multi-session):
- For single-pod images, the automation's default VM model is changed from the previously used Standard_D4_v3 VM model to use Standard_DS2_v2.
- For multi-pod images, the automation's default VM model is changed from the previously used Standard_D2_v2 model to use Standard_DS2_v2.
As of the v2204 release, please include quota for the Azure DSv2-series in your pod's Azure subscriptions.
- VMs and their related resources might not delete completely in the Microsoft Azure subscription. (2824239, 2681761, 2750176)
- This issue is resolved for pod manifests 2915.x or later. If or when this issue occurs in pods of earlier manifests, issues such as problems expanding VDI assignments can occur. This issue is due to an issue in Microsoft's Azure Resource Manager (ARM) and delays in replicating the resources' status across the multiple regions of the Microsoft Azure cloud. Due to this Microsoft ARM issue, some of those VM-related resources might be left undeleted, and therefore unattached to a VM in the Azure subscription. Examples of such unattached items that might occur are disks and NICs. Workaround: This issue is resolved for pods running manifests 2915.x or later. If you encounter this issue, please file a service request (SR) to request assistance with clearing the stale data and to schedule your pod upgrade to prevent recurrence of the issue. See KB article 2006985 for SR filing steps.
- For pods deployed into Microsoft Azure Government cloud subscriptions, using the disk encryption feature in farms and desktop assignments fails. (2572579)
When your pod is located in Microsoft Azure Government clouds and you try to create a farm or VDI assignment with the disk encryption feature selected, the creation process fails with error
Azure error encrypting the VM. Workaround: None.
- In the Servers tab for an existing farm, all of the User Login Mode choices give an error message that the Horizon Agent must be updated. (2528295)
- Use of the administrative console to set the User Login Mode depends on detecting agent version 20.1.0 running in the farm VM. However, that version of the agent might not yet be available in the cloud control plane for you to use to update the agents in your existing farm VMs. Workaround: None. When the 20.1.0 version of the agent is available in the cloud plane and your pods are updated to the manifest version that can consume that agent version, then you can update the farm VMs to that agent to use the User Login mode choices.
- Sometimes some desktop VMs out of a large floating VDI desktop assignment report unknown agent status. (DPM-3201)
- In floating VDI desktop assignments with large numbers of desktop VMs, due to a known issue, a small number of those desktop VMs can go into an unknown agent state because some Windows services, like the Horizon Agent's Blast service or the Microsoft Azure service, do not start or are slow to start. As a result, in the administrative console, the Agent Status column for those desktop VMs shows "Unknown" state, with reported agent errors. Workaround: In the console, use the Restart action to restart those VMs.
- The Import VM from Marketplace wizard creates Windows Server 2012 images without the Desktop Experience enabled. (2101856)
- Due to a known issue, when you use the automated Import VM from Marketplace wizard to create an image with a Windows Server 2012 operating system, the resulting image does not have the Desktop Experience enabled. Workaround: If you want the resulting image to have the Desktop Experience, you must manually enable the Desktop Experience in the resulting image. Note also that for the Windows Server 2012 operating system, to install the Horizon Agent with the Scanner Redirection option requires the Desktop Experience be enabled in the operating system.
- When publishing (also known as sealing) an imported VM, the process might result in a timeout or other failures to publish due to sysprep failures. (2036082, 2080101, 2120508, 2118047)
After you click
Convert to Desktop on an imported VM and
Publish to make it a published (sealed) image, a number of operations are performed on the VM. These operations include running the Windows System Preparation (sysprep) process, shutting down the VM and powering it off, and so on. Due to industry-known issues with the Windows sysprep process and customizing virtual machines, sometimes the publishing process fails for various reasons. On the Activity page, you see messages like "Timeout Error Waited 20 minutes for virtual machine to power off.", and other sysprep failure message.
Generally speaking, you can avoid such sysprep issues when you create the VM using the Import Virtual Machine from Marketplace wizard and select Yes for the wizard's Optimize Windows Image toggle. If you are seeing this error for an imported VM in which you did not use that option, or if you manually created that VM, refer to Microsoft KB 2769827, Microsoft MVP article 615 for best practices in configuring your image VM to minimize likelihood of having sysprep issues when you go to publish the image. If you continue to get sysprep issues, see the information in the articles Deciding to Optimize the Windows Image When Using the Import Virtual Machine from Marketplace Wizard and Using the Remove Windows Store Apps Option When Using the Import Desktop Wizard for ways that the automated Import VM from Marketplace wizard uses to reduce the changes of sysprep issues. If you see the timeout errors in the Activity page, you can try this workaround: on the Images page, use the Convert Image to Desktop action on the image. When the Activity page indicates converting the image to a desktop is successful, navigate to the Imported VMs page. Connect to the VM and apply the best practices described in the KBs. After you see the Imported VMs page reports the VM is powered on, select the VM and click Convert to Image to run the publishing process again.
- During farm creation, sometimes the server VMs are stuck at the customization step. (2010914, 2041909)
- Sometimes during the sysprep process on the farm's server VMs, a Windows service named tiledatamodelsvc prevents sysprep from accessing Windows files that it needs to complete the sysprep customization process. As a result, the farm's server VMs do not move past the customization step. The sysprep error log contains the line "Error SYSPRP setupdigetclassdevs failed with error 0". Workaround: If you encounter this issue and see that error message in the sysprep error log file, try stopping and deactivating the tiledatamodelsvc service in the image. Then create the farm.
- Agent status might display as 'undefined' on the Imported VMs page after duplicating an image or manually creating an image in Microsoft Azure. (2002798)
- When you use the Duplicate button on the Images page to clone a published image or when you manually create an image VM in Microsoft Azure, the resulting VM is listed on the Imported VMs page. Due to this issue, even when the VM is fully powered-on, the agent status might be displayed as 'undefined'. However, when you select the VM and choose Convert to Image to publish it, the user interface reports the agent in 'Active' state. Workaround: None. If the Reset Agent Pairing or New Image or Convert to Image workflows report the agent as 'Active', you can ignore the 'undefined' status on the Imported VMs page.
App Volumes on Pods in Microsoft Azure Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- Uploading application packages (.vhd files) with the same file name to the same location (file share), captured at different times, can prevent the App Volumes service from attaching applications to the VDI Desktops when the user logs in (2783560)
Every time App Volumes captures an application package (.vhd file), the system generates a unique GUID to identify the volume or capture session. When you try to upload an application package to the staging fileshare of Horizon Cloud Azure pods with a (.vhd) filename that was uploaded previously, a mismatch occurs between the GUIDs already present in the Horizon Cloud Azure pods and the cloud services.
The App Volumes Manager service running on the Horizon Cloud Azure pods periodically imports the application packages from the fileshare. When you try to import the applications from the importpage of the Horizon Universal Console, newly imported application packages and their corresponding GUIDs are mismatched with the GUIDs present in the App Volumes Manager service running the Horizon Cloud Azure pods. Because of this mismatch, assigned applications do not attach to the entitled users.
- Removing some users or groups from an App Volumes assignment in the console might remove the entitlements from some of the remaining users or groups in the assignment (2704889)
Due to this issue, in the scenario where you have created an App Volumes assignment that contains a set of applications and specified users or groups, and then you edit that assignment and remove some of those specific users or groups, some of the users and groups that remain configured in that assignment find they do not see the applications in their entitled desktops.
Although this issue is resolved in pod manifest 2747 and later, you might encounter this issue in pods of earlier manifest versions. If you encounter this issue, you can work around it by creating a new App Volumes assignment with the required applications and users and groups, and delete the previously created App Volumes assignment.
- When your environment has multiple pods in Microsoft Azure, the Capture process can sometimes go into an unknown state after the process has completed. (2600573)
- When your environment has multiple pods with which you are using App Volumes, sometimes after running the capturing process, the console indicates the capture is in an unknown state even though the capture process on the VM has completed. To work around this issue, re-import the application package using . As a result, the application package is successfully imported as a separate application and the subsequent assignment and application launch works.
- In a Microsoft Windows 10 Enterprise multi-session deployment, a print job might terminate when another user logs in to the same machine.
- In this environment, when a user with a app package assignment containing a printer driver logs in for the first time, an ongoing print job for another user on that multi-session machine might enter an error state. To work around this issue, wait a few minutes, or longer, after the print job terminates and attempt the print job again. See the Administration of Your Horizon Cloud Tenant Environment and Your Fleet of Onboarded Pods guide for related best-practices information.
- In a Microsoft Windows 10 Enterprise multi-session deployment, users not assigned an app package receive aspects of the application
In this environment, occasionally, when you do not turn off auto updates for an application during provisioning, the updated portion of the app inadvertently becomes visible to all users (not just those assigned the application) on the multi-session desktop, such as in the form of a desktop shortcut and application binaries. To work around this issue, for applications with auto update services, add the application service name to the multi-string svservice registry configuration DisableAppServicesList to ensure that the auto update services are not started. See the Administration of Your Horizon Cloud Tenant Environment and Your Fleet of Onboarded Pods guide for related best-practices information.
Agent Update Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- When you attempt an agent update on an image that has a Windows update pending, the update process might fail. (2234964)
- If the image needs an update to the Windows OS, as opposed to a minor non-OS update, this can cause OS resources to be offline and not available for the agent update. Workaround: Wait until the Windows update is complete and retry the agent update. To confirm that all Windows updates are complete, you can take the image offline, perform all pending updates, and re-publish the image before initiating the agent update.
Reports and Monitoring Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- In the User Activity report, the displayed weekly average (hrs) is not intuitive. (1817065)
- Due to this issue, the weekly statistics fluctuate along the time because the calculation logic is dividing the current week's duration by seven (7) and not rounding up to a whole week. For example, when you select the last 30 days, the data for completed weeks is unchanged but the data for the current week is divided by seven (7). The current logic is weekly average (hrs) = daily average (hrs) * 7 days, resulting in the last 30 days weekly average = (total duration / 30 days) * 7 days. Workaround: None
- The Desktop Health report does not reflect a newly updated farm or VDI desktop assignment name until an hour after the name change. (1756889)
- If you change a farm's name or VDI desktop assignment's name, it takes an hour for the Desktop Health report's Assignment drop-down menu and Assignment column to reflect the new name. Workaround: Wait an hour before expecting the new name to appear in the report.
- The formatting in some of the CSV files that you can export from the Reports user-interface screens do not match the on-screen tables. (2015500)
- Some of the Reports page's subscreens provide an export feature to export the displayed data in CSV format. Due to this issue, the formatting in the CSV files exported from the Desktop Health, Concurrency, and Session History reports do not precisely match the ones you see displayed on the screen. For example, the column headings might be different and the CSV files might have more columns of data than in the on-screen tables. Workaround: None.
Identity Management, Workspace ONE Access, True SSO Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- When a pod of manifest versions prior to 1763 is updated to manifest 1763 or later, and that pod has two-factor RADIUS configured on its Unified Access Gateway instances and is also integrated with Workspace ONE Access, you see that launching a desktop from Workspace ONE Access using the browser will display the RADIUS login form with the user name field prefilled with the user's UPN. (2248160)
- This symptom occurs because of a change that was released in VMware Horizon HTML Access 4.10. When your pod in Microsoft Azure from a previous Horizon Cloud release is configured with Unified Access Gateway instances and two-factor RADIUS authentication and you configure that pod to use Workspace ONE Access, previously when launching a desktop from Workspace ONE Access using the browser, the RADIUS login form prompts for the user name and passcode. The end user would type the user name and passcode in the form. However, due to this issue, after upgrading that pod to this release, using the same desktop launch steps, the RADIUS login form has the user name field prefilled with the domain user's UPN. This behavior only occurs when using the browser to launch the desktop. It does not occur when using Horizon Client. Workaround: If this situation is encountered, the end user can clear the prefilled user name field and enter their information. Generally, for most environments that are integrated with Workspace ONE Access, the two-factor authentication would be configured in Workspace ONE Access and not on the underlying Unified Access Gateway instances, in which case this issue would not be encountered.
- Launching a second desktop from Workspace ONE Access using the Horizon Client can fail with the error 'You are not entitled to that desktop or application'. (1813881, 2201599)
- This symptom occurs in the following situation. The user has entitlements to two dedicated VDI assignments through a group entitlement. Both dedicated VDI desktop assignments are listed in Workspace ONE Access when the user logs in. The user launches the first desktop using Horizon Client. That desktop connects. Then the user tries to launch the other desktop from the other assignment, also using the Horizon Client. The launch of that other desktop fails with an error indicating the user is not entitled. However, this issue is seen only for the first attempt on the second desktop. If the user launches the second desktop using the browser, subsequent attempts to launch the second desktop using Horizon Client succeed. Workaround: If you encounter this situation, try launching the second desktop using the browser.
- Workspace ONE Access does not display the remote applications' display names that you set in the Horizon Cloud administrative console. (2131583)
- This issue is resolved by using Workspace ONE Access Connector version 19.03. Due to a known issue in versions of Workspace ONE Access Connector prior to 19.03, when Workspace ONE Access displays the remote applications that you sync from Horizon Cloud, Workspace ONE Access does not display the display names that you set for those remote applications in Horizon Cloud. Even though Horizon Cloud sends the display names to Workspace ONE Access, Workspace ONE Access uses the remote applications' launchIDs instead. As a result, Workspace ONE Access displays the basic names for the remote applications.
User Interface Related Known Issues
Unless otherwise noted in the known issue text, the known issues listed here apply to pods deployed in Microsoft Azure.
- The Logon Segments chart displayed in the session dashboard has no data.
- This issue applies to all types of pods. The VMware Logon Monitor service provides the data for the Logon Segments chart that appears in the session dashboard. However, this release does not support use of the VMware Logon Monitor service and by default, the Horizon Agents Installer deactivates the VMware Logon Monitor service in all installations that the installer performs. As a result, even though no data is reported that the Logon Segments chart can display, you see the Logon Segments chart is still visible in the session dashboard. Workaround: None.
- When using the administrative console in one browser tab, if you try to launch a disconnected desktop that you have in another browser tab in the same browser, the HTML Access portal is also logged off and you must log back in to the HTML Access portal itself. (2118293)
- Usually when you launch a desktop and disconnect from it without logging out of the desktop, you stay logged in to the HTML Access portal itself and you can reconnect to the disconnected desktop without having to enter credentials to the HTML Access portal. Due to this issue, if you are in a browser window where you are logged in to the console in one browser tab and use another browser tab to log in to the HTML Access portal and launch a desktop, when you disconnect from that desktop and try to reconnect to it, the HTML Access portal logs off. Then you must re-enter credentials to the HTML Access portal before you can reconnect to that desktop. Workaround: To avoid this issue, log in to the administrative console using a separate browser window from where you have the HTML Access portal. This behavior only occurs if you are also logged in to the console in a browser tab in the same browser window in which you are also using the HTML Access portal.
- In the User Card screen for a specific user, VDI dedicated desktop assignments are removed from the Assignments tab after the user's first launch of the dedicated desktop from that assignment. (1958046)
When a user is specified in a VDI dedicated desktop assignment as an individual user, not through an Active Directory group, that VDI dedicated desktop assignment appears in the Assignments tab in the User Card screen for that user only until the user's first launch of a dedicated desktop from that assignment. After the user's first launch of a VDI dedicated desktop from that assignment, the user card's Assignments tab no longer displays that VDI dedicated desktop assignment for that user. The user's first launch results in that user claiming a specific dedicated desktop from the underlying pool defined by that assignment and the system maps that specific dedicated desktop to that particular user. When that mapping is made, that specific dedicated desktop gets the Assigned state, and it is listed on the user card's Desktops tab for that user.
Workaround: Instead of relying on the user card's Assignments tab in this case, to see the already launched VDI dedicated desktops assigned to a specific user, you can use the Desktops tab. If you need to locate the specific VDI dedicated desktop assignment in which that user-desktop mapping is made, obtain the desktop name from the user card's Desktop tab and use the search by VMs feature of the top banner search to list that specific desktop VM. In the results from the search by VMs, click the name to open the specific assignment page that has that particular dedicated desktop. Then you can locate the user in the assignment's details.
- The What's New screen appears even though you previously selected the option not to continue showing it. (2075825)
- This issue applies to environments with any pod type. Due to this issue, if you clear your browser cache or you use a different browser than the one in which you previously selected the option to not show the What's New screen, the screen might appear when you log in to the administrative console. The flag for whether to show the What's New screen is stored in the browser's local cache, instead of per user. Workaround: None.
- Even though the image creation process has not fully completed, the Getting Started screen displays Completed for the Create Image step. (2100467)
- Due to this issue, the Create Image step is marked as completed prematurely. Workaround: Use the Activity page to verify that the image creation process has completed.
- When using the administrative console, you might see placeholders instead of the actual text strings or you click a button on a page and nothing happens. (2045967)
- This issue applies to environments with any pod type. VMware periodically updates the in-cloud management environment that hosts the Web-based console. This issue can occur when static content has been cached in the browser prior to the latest in-cloud update. It is a temporary issue that will clear when the browser cache is cleared. Workaround: Try logging out of the console, clearing the browser cache, restarting the browser, and then logging back in to the console.
- Application names are displayed in lowercase characters when end users access them using Workspace ONE Access. (1967245)
- When your Horizon Cloud environment is integrated with Workspace ONE Access, your end users access their assigned desktops and applications using Workspace ONE Access. Due to this know issue, the users see the application names displayed with lowercase characters, regardless of the actual case used in the application names. This limitation is due to the way Workspace ONE Access creates launch IDs from Horizon Cloud by using older Horizon Cloud REST APIs. Workaround: None.
- The memory usage percentages reported for desktop health reports and used for the desktop health alerts are based on percentage of committed memory, which equals physical memory plus pagefile size, and not on percentage of only physical memory. (2015772)
- Committed memory for a desktop VM is calculated as physical memory plus pagefile size. When calculating the percentage of memory usage in a desktop, the system takes the percentage used of that total (physical memory plus pagefile size). Both the desktop health alerts and the memory usage report in the desktop health reports use that percentage calculation. However, when you log into a desktop VM and open the Windows Task Manager to view the memory usage in the desktop's Windows operating system, the Windows Task Manager displays percentage based on physical memory only. As a result, the memory usage percentage that the desktop's Windows Task Manager displays does not match the memory usage percentage displayed in the Desktop Health reports or in the desktop health alert. Workaround: Keep in mind this difference if you decide to make a comparison between the memory usage percentage reported by a desktop's Windows Task Manager and the memory usage percentage reported in the console's Desktop Health report and desktop health alerts for that desktop.
- If a desktop VM's CPU usage is at or close to 100%, the desktop alert is not triggered. (1446496)
- If an application or something in the desktop VM causes the VM's CPU usage to reach 100%, the desktop agent fails to send as many data samples as it usually sends to Horizon Cloud because the CPU is very busy. As a result of the low sample count returned, the calculation the system uses to trigger the desktop alert is affected. Workaround: None.
End User, Horizon Agent, Horizon Client Related Known Issues
The known issues listed here apply to pods deployed in Microsoft Azure.
- Launching a dedicated desktop from a Horizon Client using an open recent option (or an equivalent option, based on the client type) might not correctly launch the dedicated desktop (SR23422432704, HCS-39121)
Various Horizon Clients provide mechanisms whereby the client remembers a previously launched desktop or remote app, and the end user can launch those previously opened desktops or published apps without going to the full list of desktops and applications which they are entitled to.
For example, in the Horizon Client for iOS and Horizon Client for Android, their screens labeled Recent provide access to such previously launched desktops and remote apps. As described in the Horizon Client for Mac documentation, the Horizon Client for Mac provides two ways to open recent desktops and remote apps: using the client's option, and if the client is added to the Dock, using the icon on the Dock. As described in the Horizon Client for Windows documentation, the Horizon Client for Windows has a GPO setting for what is called jump list integration, typically enabled by default, which enables users to connect to recent desktops and published applications using the Horizon Client icon on the Windows taskbar.
In the case of a dedicated desktop provisioned by Horizon Cloud on Microsoft Azure, after the initial desktop launch, the Horizon Client might not store the correct identity of the desktop as a recent launch.
Due to this issue, when the end user subsequently uses one of the above described clients' recent mechanisms to open that desktop again, the desktop might not launch.
This issue can also occur if Workspace ONE Access is used with the Horizon Cloud on Microsoft Azure deployment and the Horizon Client redirects the user to Workspace ONE to orchestrate the launch of the dedicated desktop. When the end user had previously launched the desktop directly from the Workspace ONE portal, and then the user tries to use one of the client's recent mechanisms to launch the desktop, when the client redirects to Workspace ONE to orchestrate the launch, the desktop might not launch due to this issue.Workaround: To avoid encountering this issue, always launch the desktop by either directly selecting the desktop from the full desktop list in the client, or where the environment is configured to require all launches to be performed from the Workspace ONE portal, initiating the launch by selecting the desktop within the Workspace ONE portal. Avoid using a client's recent mechanism (avoid using or the Recent list or any of the recent mechanisms offered by the clients).Note: When Workspace ONE redirection is enabled for the Horizon Cloud on Microsoft Azure deployment and an end user uses a recent mechanism and the desktop fails to launch, a Workspace ONE audit event is written to indicate the failed launch.
- For a VM running Microsoft Windows 10 Enterprise multi-session 2004 or later, the DPI Synchronization and Display Scaling features have issues (2587685, DPM-6352)
- Due to an inability to query the current DPI in VMs running Microsoft Windows 10 Enterprise multi-session 2004 or later, these features with those VMs do not work as documented in the Horizon Client documentation. The DPI Synchronization and Display Scaling features do not work for PCoIP session reconnections. The DPI Scaling feature does not work for Blast session reconnections. Workaround: Log out of the session and log back in again.
- For a VM running Microsoft Windows 10 Enterprise operating system 1903 or later, the DPI Synchronization and Display Scaling features have issues (2589129)
- Due to an inability to query the current DPI in VMs running Microsoft Windows 10 Enterprise client operating system 1903 or later, when reconnecting a PCoIP or Blast session, the features do not work as documented in the Horizon Client documentation. Workaround: Log out of the session and log back in again.
- Sometimes when launching a VDI desktop using VMware HTML Access, an error message about being disconnected appears, and then subsequently the launch is successful. (2243471)
- VDI desktop virtual machines have a default session connection timeout, and when that timeout is reached, the session is disconnected. Sometimes, when launching a desktop, if the end user's HTML Access session has timed out at the time the desktop's default session connection timeout is reached, the desktop will initially throw that error, and then continue launching the desktop. Workaround: None.
- When a VDI desktop assignment has disk encryption selected and a one- or two-core VM model, and a desktop's underlying VM is powered off, the Horizon Client's automatic retry option might fail to make a connection. (2167432)
- When a VDI desktop VM is powered off due to the VDI desktop assignment's power management settings, the VM has to power on and get ready before an end user connection can be made to that desktop. When an end user's client tries to connect to a VDI desktop assignment's VM and the VM is powered off, the system starts powering on that VM. For non-encrypted VMs, the VM is typically ready to accept a client connection in under 10 minutes. However, an encrypted VM with one or two cores usually takes longer than 10 minutes to get ready to accept a connection. The Horizon Client's Client Retry option has an upper limit of 12 minutes. Because of this upper limit of the Client Retry option, when the end user has the client automatically retry the connection while the desktop's underlying VM is getting powered on and ready but the connection is not made within 12 minutes, the client's automatic retry gives up. Because an encrypted VM usually takes longer than 12 minutes until it is ready to take the client connection, the end user might see that Horizon Client's automatic retry fails to complete the connection to their encrypted desktop VM. Workaround: When you want to have disk encryption for a VDI desktop assignment, select a VM model that has more than two cores. Otherwise, if your VDI desktop assignment has disk encryption and has a VM model with one or two cores, inform your end users that they might experience this issue with using the Client Retry option with these encrypted desktop VMs.
- For a virtual desktop from a dedicated VDI desktop assignment, the shortcut link on the Horizon client's Recent page might not launch the desktop. (1813881, HD-3686, DPM-1140)
- The iOS and Android versions of the Horizon clients have a Recent page which displays links to recently launched desktops. When the user does the initial launch of a dedicated pool virtual desktop, the desktop launches as usual, and the client creates a launch icon on the Recent page. However, when the user disconnects from the desktop and then tries later to launch the desktop from the Recent page, the desktop fails to launch because the launch icon is using a shortened version of the desktop name. Workaround: Launch the desktop from the client's main page, and not the Recent page.
- Pods at 1976.0 manifest version and farm VMs running agent level 19.4: Users get disconnected after one hour from their desktops or remote application sessions when using HTML Access (Blast) and PCoIP protocols. (2519400)
This issue is due to an issue in Microsoft terminal services in Microsoft Windows 10 Enterprise multi-session systems. For session-based desktops and remote applications provisioned from RDSH farms based on the Microsoft Windows 10 Enterprise multi-session operating system, when an end user reconnects to an existing desktop or remote application session using either HTML Access (Blast) or PCoIP protocol, after an hour has passed, the user's session is forcefully disconnected. There is no data loss. Even though the user can reconnect again and the session is in the same state it was at the disconnect time, this behavior repeats and the reconnected session is again forcefully disconnected after an hour.
This issue is resolved using Horizon Agents Installer (HAI) 20.1 or later. When your 1976.0 pod is updated to manifest 1976.1 or later, the Import Virtual Machine from Marketplace wizard will automatically install the agent software that has this fix. If your pod is still at 1976.0 manifest level, running the wizard will still install the agent software with the issue. However, when you seal the VM, the Images page will show the blue dot, signifying that you can use the Update Agent feature to update the agent to the level with the fix.
- Pods at manifest versions earlier than 2298: When switching protocols in the client, if you choose the Connect choice instead of Log Out and Reconnect, the client might become unresponsive. (2528014)
- This issue is resolved in pods that are updated to manifest 2298 or later. This issue happens when switching protocols in the client after establishing a session to an RDSH farm using one protocol. When you launch the desktop or application using one protocol, disconnect that session, use the client's menu to switch to a different protocol, launch the same desktop or application, the client presents a dialog box saying "This desktop is open on the server but is running a different protocol." and presents a choice to connect or to log out and reconnect. If you select the Connect button, the dialog appears a second time, and if you select Connect again, the client becomes unresponsive.
- When using the Update Agent feature to update images that have an agent version earlier than 18.2.2, the update process might fail (2200962)
- Images that you created on nodes at manifest level earlier than 965 might experience this issue. Sometimes the image has RunOnce registry values that block completion of the agent update process. Workaround: Perform the agent update again, adding the following command line argument on the Command Line tab of the Agent Update wizard: VDM_SUPPRESS_RUNONCE_CHECK=1