check-circle-line exclamation-circle-line close-line

VMware Horizon® Cloud Service™ | Last quarterly release 17 March 2020
VMware Horizon® Cloud Service™ on Microsoft Azure | Version 3
New VMware Horizon 7 Cloud Connector | Version 1.6.1 (Look for the green New further below for details)
VMware Horizon Universal Broker plugin installer | Version 20.1
VMware Horizon Agents Installer | Version 19.4 (Microsoft Azure pod manifests 1763.x)
VMware Horizon Agents Installer | Version 20.1 (For use with Microsoft Azure pod manifests 1976.x. Look for the May 6 update further below for important details. Note: Running the Import VM from Marketplace wizard in a pod of manifest 1976.0 will continue to result in agent level 19.4 installed into the resulting VM because each build of a pod manifest builds into it a specific version of Horizon Agents Installer, and version 19.4 is the version that was built into the manifest 1976.0 when manifest 1976.0 was built back on March 17, 2020. Because one could also manually install Horizon Agents Installer 20.1 into a base VM that resides in a pod of manifest 1976.0, Horizon Agents Installer 20.1 can be used in that scenario.)

Tip: This document is revised periodically when the Horizon Cloud Service itself is refreshed, so that you have current information about the service. Check back for additions and updates to these release notes, and look for green New text or red Update text.

This document applies to the quarterly service release that was pushed into production on March 17, 2020 and the subsequent weekly maintenance refreshes until the next quarterly service release. Access to some of the What's New features depends on factors such as which Horizon Cloud control-place region your customer account is located in, the pod manifest versions supported in that region, the manifest version of your current cloud-connected pods, and so on. For the release notes of previous quarterly releases, use the links listed in the left-hand navigation pane at https://docs.vmware.com/en/VMware-Horizon-Cloud-Service/index.html. Your control-plane region is stated in the Welcome to Horizon Service email sent when the customer account is created, as described in Onboarding to Horizon Cloud for Microsoft Azure, Horizon 7 On-Premises, and Horizon 7 on VMware Cloud on AWS:

  • If your email states your Horizon Cloud control-plane region is USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1), or Australia-2 (PROD1_AUSTRALIAEAST_CP1), new Microsoft Azure pod deployments begin with pod manifest version 1976 and have access to the new features that are available only for pods at that manifest version, including the new control-plane support for extended Windows Virtual Desktop features for Windows 10 Enterprise multi-session farms and Microsoft FSLogix, and Tech Preview support for Windows 7 virtual desktops with Extended Security Updates. For more information, visit vmware.com/go/HorizonWVD and Knowledge Base Article 77559.
  • If your email states your Horizon Cloud control-plane region is USA, Europe (EU_CENTRAL_1), or Australia (AP_SOUTHEAST_2), new Microsoft Azure pods in those regions will deploy at pod manifest version 1763 (December 2019, v2.2). Features listed in What's New that are only available for customer accounts located in other regions, such as the Windows Virtual Desktop features, will be unavailable for use with those pods. See Knowledge Base Article 77559. Features listed in What's New that are agnostic to pod version or control-plane region are available for use with those pods.

Update: September 8, 2020:

Update: The following known issue and work around is added here as of June 27, 2020:

  • Known issue: In the Administration Console's Activity page's Users tab, when All Pods is selected and you click to export the data, the export fails. To work around this issue, when exporting data from the Activity page's Users tab, select a specific pod before exporting the report.

Update: The following known issue and work around is added here as of June 11, 2020:

  • Known issue: After you follow the Administration Guide's steps to manually import a base VM, the VM does not appear on the Imported VMs page. Due to a system issue, when a VM has tags with null values, the VM is not appearing on the page. To work around this issue, in the Microsoft Azure portal, manually add a tag to the VM. The tag can be any value. On the VM's Overview page, where it says Tags (change), click change and add a tag. Then refresh the Imported VMs page.

Update: These items are provided in the service as of June 9, 2020:

  • New The Horizon Cloud control-plane regional names that appear in the Welcome to Horizon Service email are updated to USA, Europe, Australia, USA-2, Europe-2, and Australia-2. Welcome emails sent as of June 9, 2020 reflect these new names. The DNS Requirements documentation topic is also updated with this information.

Update: These items are provided in the service as of May 27, 2020:

  • New The Horizon Cloud login screen has an additional method for authenticating to your Horizon Cloud tenant environment and the Administration Console. You can now use the new VMWARE CLOUD LOGIN button to authenticate using VMware Cloud Services.
  • New Use of VMware Cloud Services federated identity management with your Horizon Cloud tenant is now in Limited Availability. Note: This federated identity management feature is currently certified for use only when the Horizon Cloud tenant's cloud-connected pods are all pods in Microsoft Azure. For more information, please email the VMware Horizon Cloud Service team at horizoncloudservice@vmware.com.

Update: These items are provided as of May 26, 2020:

  • New Version 1.6.1 of VMware Horizon Cloud Connector is now available in VMware Downloads. This update provides stability fixes. Note: If you deploy the prior version appliance 1.6.0 in your environment, a message will display during the Horizon Cloud Connector deployment process that version 1.6.1 is available for download. The message displays after you log in to the Web-based configuration user interface. Although you can proceed with 1.6.0, downloading and deploying the latest 1.6.1 version is recommended to obtain the benefits of the latest fixes. In VMware Downloads, the 1.6.1 version is located at https://my.vmware.com/group/vmware/details?downloadGroup=HCS-CC-161&productId=716&rPId=46538.

Update: These items are provided in the service as of May 12, 2020:

  • To avoid a Microsoft Azure issue, use of the Microsoft Azure Load Balancer Basic SKU for a pod's gateway configurations is discontinued. The Standard SKU will be used by default for both external and internal gateway configurations. The Load Balancer Type selection field is removed from the New Pod wizard's and Edit Pod wizard's Gateway Settings step. Note: At this time, existing pods that already have gateway configurations in place with the Basic Microsoft Azure Load Balancer are not touched by this change. The VMware team is working on a plan for those pods.

Update: These items are provided in the service as of May 6, 2020:

  • Version 20.1 of VMware Horizon Agents Installer (HAI) is now available in VMware Downloads.
  • When running the Import VM workflow in pods of manifests 1976.1 and 1976.2, the HAI version 20.1 will be installed by default in the resulting VM.
  • For pods of manifest 1976.0, running the Import VM workflow in those pods, the HAI version 19.4 will continue to be installed by default in the resulting VM because the 19.4 version was the one available when manifest 1976.0 was made available. After you convert the VM to an image, the Administration Console's Images page will display a blue dot on the image indicating that the newer 20.1 version is available. You can then use the Image page's Update Agent action to update the image's agent version to 20.1. See Actions You Can Perform on Assignable Images in the Horizon Cloud documentation.

Update: These items are provided in the service as of April 27, 2020:

Update: These items are provided in the service as of April 21, 2020:

  • The VMware Horizon Service Team has re-enabled the following pod features because Microsoft has resolved the Microsoft Azure networking issue described in the March 18, 2020 bullet below. The pod architecture that uses the Azure PostgreSQL Service and provides for the high availability (HA) option, as well as the ability to deploy the external gateway into a separate VNet and into a separate Microsoft Azure subscription are re-enabled for use. Those features' related user interface toggles and fields are available in the Administration Console. Also a new pod deployed after this date will include the Azure PostgreSQL Service and the pod Azure load balancer in its architecture by default.

Update: These items are provided in the service as of April 14, 2020:

  • Horizon Universal Broker support is added for accounts in Horizon Cloud control-plane regions Europe-2 (EU_CENTRAL_1) and Australia-2 (AP_SOUTHEAST_2). See the relevant bullet under Environments, Operating Systems, and Compatibility.
  • Running the automated Import VM from Marketplace wizard when your pod is configured for proxy-based authentication is now supported. The previous limitations that prevented use of the automated Import VM from Marketplace wizard when you have a proxy configured for the pod are addressed.
  • Support for deploying a pod into the Microsoft Azure Germany cloud environment is discontinued. Microsoft has added regions in Germany to their set of standard global regions and discontinued use of their separate Azure Germany cloud environment. As a result, you now can choose one of those German regions in the pod deployment wizard's Pod Configuration step, instead of using a subscription in their original Microsoft Cloud Germany environment. For additional information about using Microsoft Azure Germany, see the Microsoft Azure documentation topic Welcome to Azure Germany.
  • The pod deployer now uses the Azure StorageV2 account type by default. Previously the deployer used the Azure StorageV1 account type. Ensure that your Microsoft Azure Policies do not restrict or deny the creation of content requiring the Azure StorageV2 account type.
  • See above. This item is re-enabled as of the April 21, 2020 service refresh. Update: March 18, 2020 As of March 18, 2020, the VMware Horizon Service Team has temporarily disabled the following pod features in order to mitigate a Microsoft Azure networking issue that results in pod deployment failures. The pod architecture that uses the Azure PostgreSQL Service and provides for the high availability (HA) option, as well as the ability to deploy the external gateway into a separate VNet and into a separate Microsoft Azure subscription are all temporarily disabled. As a result, you will no longer see those features' related user interface toggles and fields. Also a pod deployed after that date will have a single pod manager VM, and the pod will not include the Azure PostgreSQL Service or a pod Azure load balancer in its architecture. See VMware Knowledge Base Article 78263 for details.

What's in the Release Notes

The release notes cover the following topics:

About VMware Horizon Cloud Service

VMware Horizon Cloud Service transforms traditional desktop and application virtualization by providing a cloud-scale architecture that frees you to choose where your virtual desktops and applications reside — in-cloud or on-premises — and manage them all from a single control plane. Pods can reside on-premises, as in a traditional Horizon 7 installation, and pods can reside in clouds such as Microsoft Azure and VMware Cloud on AWS, which gives you the freedom to deploy workloads based on cost, location, geography, and current usage. The Horizon Cloud control plane gives you a single UI to manage all those cloud-connected pods and which gives you visibility into the pods' capacity usage, health monitoring, help desk services, and ability to set up end-user workspace assignments which associate your end users with their entitled virtual desktops and applications. Your overall tenant environment in Horizon Cloud consists of the VMware-hosted cloud service itself and the cloud-connected pods wherever those pods reside — and you manage it all using a single pane of glass, the Horizon Cloud Administration Console.

For example, you can use the Horizon Cloud Administration Console for unified health monitoring and multi-cloud assignments (MCAs) with multiple cloud-connected Horizon 7 pods. Such MCAs create global entitlements where users can access their desktops which might reside in any of those cloud-connected Horizon 7 pods. For pods in Microsoft Azure, you can use Horizon Cloud to create master images, from which the pods can provision virtual desktops and remote applications that your end users can securely access from any device.

What's New in this Quarterly Service Release

The March 2020 release is the debut of the headline features listed below. If you are a current customer that has existing cloud-connected pods prior to this release, additional detail is provided in For Current Customers with Existing Cloud-Connected Pods - About this Release.

Key documents updated for this release include:

  • VMware Horizon Cloud Service on Microsoft Azure Requirements Checklist (HTML).
  • VMware Horizon 7 with Horizon Cloud Requirements Checklist (HTML).
  • Deployment Guide (HTML | PDF)
  • Administration Guide (HTML | PDF)

A new document for this release is Managing Images from the Cloud (HTML | PDF). This new document accompanies the new Image Management Service.

What's New for Horizon Cloud Service

  • The Horizon Control Plane is now available and running in Microsoft Azure with instances located in the US, Europe, and Australia regions with support for both Horizon 7 (On-Premises & VMware Cloud on AWS) and Horizon Cloud on Microsoft Azure pods.
  • The Dashboard Sessions tab now shows the total number of provisioned and utilized sessions for each assignment and farm when a pod is selected. The User Usage report now includes CPU and memory consumption details per end-user for easy analysis of the ongoing consumption pattern of a user for both Horizon 7 (On-Premises & VMware Cloud on AWS) and Horizon Cloud on Microsoft Azure pods.
  • Improvements to the Horizon Cloud Help Desk help to protect personal and sensitive end-user information when looking up user-specific information in the Horizon Cloud Help Desk for both Horizon 7 (On-Premises & VMware Cloud on AWS) and Horizon Cloud on Microsoft Azure pods.
  • Simplified proxy configuration for the Horizon Cloud Connector to minimize configuration issues and errors as well as an onboarding diagnostic tool that identifies and remediates errors when onboarding Horizon 7 On-Premises and VMware Cloud on AWS pods.

What's New for Horizon Cloud on Microsoft Azure

  • Horizon Cloud on Microsoft Azure now supports extended Windows Virtual Desktop features for Windows 10 Enterprise multi-session farms and Microsoft FSLogix, and Tech Preview support for Windows 7 virtual desktops with Extended Security Updates. For more information, visit vmware.com/go/HorizonWVD
  • RDSH farms now support per-VM maintenance through the new User Login Mode, which can be set to drain the VM and route connections to other available VMs within the RDSH farm for Horizon Cloud on Microsoft Azure pods.
  • Improved detection of Microsoft Sysprep-related issues and improved error reporting that provides administrators with clear and actionable error messages along with links to VMware KBs for Horizon Cloud on Microsoft Azure pods.
  • External Gateways now support deployments into existing customer-created Microsoft Azure Resource Groups to provide granular, narrow-scope permissions within the Microsoft Azure subscription for Horizon Cloud on Microsoft Azure pods.

What's New for Cloud-Connected Horizon 7 Pods

  • The Image Management Service is now available for Horizon 7 On-Premises pods. Key improvements from the early access version include the ability to delete unused image versions and to download and use the OS Optimization Tool (beta). Please note that OVA file import is no longer available.

For Current Customers with Existing Cloud-Connected Pods - About this Release

In addition to the items listed in the preceding What's New in This Release section, for those of you who have existing cloud-connected pods and have previous experience with Horizon Cloud features and workflows, this section describes what this release's new features and changes might mean to you. The new features related to enhancements of the Horizon Cloud Administration Console are collected at the bottom of the list. For more detailed information, see the Deployment Guide and Administration Guide.

  • Specifically for cloud-connected Horizon 7 pods:
    • Horizon 7 pods are onboarded to Horizon Cloud for two primary use cases: to activate use of a subscription license with those pods and to enable use of cloud-hosted services that Horizon Cloud provides for Horizon 7 pods. Each pod is onboarded using the Horizon 7 Cloud Connector. The origin of onboarding Horizon 7 pods to Horizon Cloud started with Horizon 7 version 7.6 environments and Horizon 7 Cloud Connector 1.0 for activating subscription licenses on Horizon 7. Then with each new version of Horizon 7 combined with a new version of Horizon 7 Cloud Connector, additional cloud-hosted services become available for cloud-connected Horizon 7 pods running the latest Horizon 7 version paired with the latest Horizon 7 Cloud Connector version. This release's Horizon 7 Cloud Connector version 1.6 brings the following new features. We recommend customers having earlier versions of Cloud Connector to upgrade to this latest version to take advantage of new features as well as security and resiliency fixes.
      • A command-line diagnostic tool is provided in Horizon 7 Cloud Connector 1.6.x for you to check the health of required Horizon 7 pod's system components and services that are needed for the Cloud Connector to successfully pair the pod with Horizon Cloud. Before you log in to the web-based configuration portal and run the pod configuration wizard, you can run this diagnostic tool to check for things that might prevent a successful outcome. If there are issues discovered, the tool will report the component name, details, and recommended remediation steps.
  • Specifically for pods in Microsoft Azure:
    • As described in the What's New in This Release section, to support advanced deployment configurations, when using a separate subscription for the external Unified Access Gateway configuration, you can choose to deploy the Unified Access Gateway resources into an existing customer-created resource group, instead of the default one created by the pod deployer. 
      • For an existing pod to take advantage of this new feature, the pod must first be upgraded to at least manifest version 1763 or later (the December 2019 release's manifest). Then you need to meet all the documented requirements for using a separate subscription, VNet, and custom resource group for the external gateway configuration, including peering that VNet with the pod's VNet and creating the resource group in that subscription. Then you must delete the pod's existing external Unified Access Gateway configuration, using the Administration Console's Delete External UAG workflow. When the deletion is completed successfully, then you can run the Edit Pod workflow to add the external gateway using the new option to place the external Unified Access Gateway in your existing resource group.
    • Support for administrators to specify that the names of the dedicated VDI desktop assignments are displayed in the end-user clients after a VDI desktop VM gets assigned to the end user, instead of displaying the desktop VM name. Previously, after an end user claimed a specific VDI desktop VM, their client displayed the name of the desktop VM by default and that behavior was not configurable. Note: This option does not change what is displayed for those end-user connections that are going through VMware Workspace ONE Access. VMware Workspace ONE Access always displays the dedicated VDI desktop assignment name, and when the end user launches the desktop VM from Workspace ONE Access, the desktop name is displayed in their end-user client. Even though you will see this feature's option in the General Settings page, a pod must be running this release's manifest version for it to be able to take advantage of this feature.
    • As described in the What's New in This Release section, this release's pod manifest version supports administrators to put an individual farm VM into a maintenance mode, so that the administrator can perform maintenance actions on the VM. Before you can exploit this feature to set a per-VM maintenance mode, the pod must be running this release's manifest version. Also, due to a known issue in the Administration Console, even though this feature's options are displayed in the farm's Servers tab in the Administration Console, those user-interface options will not set the mode until the agents in the farm's VMs are running version 20.1.0 or later.
  • Additional items of note for current customers with existing cloud-connected pods include:
    • Enhancements in the reports available in the Administration Console's Reports page and Dashboard page. The data in these reports is provided by the Cloud Monitoring Service. Existing pods can take advantage of this feature.
    • As described in the What's New in This Release section, Image Management Service is now available for Horizon 7 On-Premises pods. A new document is released to support use of workflows used in that service: Managing Images from the Cloud (HTML | PDF)

Environments, Operating Systems, and Compatibility

  • Compatibility with other VMware Products: For the most recent information about compatibility between this product and other VMware products, see the VMware Product Interoperability Matrices.
  • Browser Experience: The Administration Console is compatible with recent versions of Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Microsoft Edge. Even though you can try using Apple Safari, use of the Administration Console in Apple Safari is not supported in this release.
  • Microsoft Azure Cloud Support: For Microsoft Azure deployments, the service is currently available in the following Microsoft Azure cloud environments:
    • Microsoft Azure (standard global regions)
    • Microsoft Azure in China
    • Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas)
    • New: April 13, 2020 Support for deploying a pod into the Microsoft Azure Germany cloud environment is discontinued. Microsoft has recently added regions in Germany to their set of standard global regions. As a result, you now can choose one of those German regions in the using the Microsoft Azure Region list in the Pod Configuration step of the pod deployment wizard, instead of using the separate Microsoft Azure Germany cloud environment.

    Note: Currently, the High Availability (HA) feature for pods in Microsoft Azure is only supported for pods deployed in the Microsoft Azure standard global regions. It is not supported for pods in Microsoft Azure in China and and Microsoft Azure Government. The VMware team is working on adding support for the HA feature for pods in those cloud environments. If you have an existing pod in Microsoft Azure in China or Microsoft Azure Government that you want to upgrade to this release's manifest version without the HA feature, please contact your VMware representative for assistance.

  • Supported Microsoft Windows Operating Systems: In the service's Microsoft Azure deployments, the following Microsoft Windows operating system editions and versions in the Azure Marketplace are the ones supported for use in this release, regardless of whether you use the automated or manual method of deploying an image in this release.
  • Supported Horizon Client versions for Microsoft Azure deployments: To see the specific versions of Horizon Clients that are compatible with the desktops and remote applications brokered by your pods in Microsoft Azure, see the VMware Product Interoperability Matrices and select Horizon Cloud Service on Microsoft Azure and VMware Horizon Clients in the drop-down menus. You can obtain the Release Notes for the Horizon Client versions from the VMware Horizon Client Documentation page at docs.vmware.com/en/VMware-Horizon-Client/

    Note: The VMware Horizon HTML Access client does not support certain features when used in mobile browsers. Also, even though the Horizon Client supports copying and pasting text between a client's local system and a VM out of the box, for HTML Access, you must configure this feature before your end users can use it. For more information, see the VMware Horizon HTML Access documentation page and search for the information in the most recent User Guide and Installation and Setup Guide.

  • Microsoft Windows 7 Operating System: As described in this release's What's New in this Release section, this release provides Tech Preview support for Windows 7 virtual desktops with Extended Security Updates. If your Welcome to Horizon Service email indicates that your Horizon Cloud tenant account was created in one of the following regions, you have access to this Tech Preview operating system using your Horizon Cloud Service tenant: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1), Australia-2 (PROD1_AUSTRALIAEAST_CP1). With virtual desktops based on this operating system, you can use the Horizon Windows client, RDP 8.x protocol, and the Horizon remote experience features USB redirection and Help Desk. Use of GPU with NV-series VMs is not supported.

  • Supported NSX Cloud versions with Microsoft Azure deployments:  For pods at this release's manifest version (new pods or upgraded pods), using NSX-T Data Center 2.5 or later is recommended. For pods at the prior release's manifest version, the NSX-T Data Center patch release (patch release 2.3.0.1.0, build 10539383) will continue to work. Note: When using NSX-T Data Center 2.4 or 2.5, additional configuration steps are needed on the forwarding policies for the NSX-managed VMs. For details, see the Administration Guide.
  • Versions for cloud-connected Horizon 7 pods: See VMware Knowledge Base Article 77564 for the matrix of supported versions of Horizon 7 with Horizon 7 Cloud Connector. To get the benefits of advanced features that are only available for cloud-connected Horizon 7 pods, you must have more recent versions of the Horizon 7 Cloud Connector and Horizon 7 software. If you have the required licensing, you can download the latest Horizon 7 Cloud Connector appliance and VMware Universal Broker plugin installer by navigating to the Horizon 7 Cloud Connector section located within the VMware Horizon Cloud Service download page.
    Important: You must use the version 1.6 or later of Horizon 7 Cloud Connector if your Horizon Cloud customer account was created in one of the following regions: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1), Australia-2 (PROD1_AUSTRALIAEAST_CP1). Only versions 1.6.x are compatible with those regions. Your Welcome to Horizon Service email states in which region your account was created.
  • Universal Broker Clients: All Horizon Clients as of their March 2020 release dates work with Horizon Universal Broker. Documentation for client releases is available linked from the VMware Horizon Clients documentation page at https://docs.vmware.com/en/VMware-Horizon-Client/index.html. Horizon HTML Access works for both versions 19.4 and 20.1 of the Universal Broker plugin. Please note that when using Horizon HTML Access, unless the SSL certificate configured on the load balancer of your Unified Access Gateway setup has a common name that precisely matches that load balancer's name and is signed by a well-known Certificate Authority (CA), when the user launches a brokered desktop, their browser will display the standard browser 'unsafe' message. (For information about the relationship between a certificate's common name and the hostname of where the certificate is installed, see https://support.dnsimple.com/articles/what-is-common-name/)
  • Universal Broker Control-Plane Regions: You can make use of Universal Broker only when your customer account is located in a Horizon Cloud control-plane region in which Universal Broker is present. To find your account's control-plane region, refer to the Welcome to Horizon Service email that was sent to you when your account was created. That email states the control-plane region in which your account resides.
    The following table details the presence of Universal Broker by control-plane region name.
    Region Name in Welcome Email Universal Broker
    USA Yes
    EU_CENTRAL_1 Yes
    AP_SOUTHEAST_2 Yes
    PROD1_NORTHCENTRALUS2_CP1 or USA-2 No
    PROD1_NORTHEUROPE_CP1 or Europe-2 No
    PROD1_AUSTRALIAEAST_CP1 or Australia-2 No

Things to Know Before Using this Release

Review this information as you prepare to consume this release of VMware Horizon Cloud Service.

Knowledge of the following facts is useful before using Horizon Cloud Service with any of the deployment types.

  • Login authentication into the Horizon Cloud Administration Console relies on My VMware account credentials. If the My VMware account system is experiencing a system outage and cannot take authentication requests, you will not be able to log in to the Administration Console during that time period. If you encounter issues logging in to the Administration Console's first login screen, check the Horizon Cloud System Status page at https://status.horizon.vmware.com to see the latest system status. On that page, you can also subscribe to receive updates.
  • Each of the pods paired with the Horizon Cloud control plane and associated with the same customer account must have line of sight to the Active Directory domains connected to those pods and have one-way or two-way trust configured along with that line of sight. For example, when you have three pods where one pod is in Microsoft Azure, one pod is on-premises, and one pod in VMware Cloud on AWS, each of those pods must have line of sight and one-way or two-way trust configured to the same set of Active Directory domains.

Knowledge of the following facts is useful before using Microsoft Azure deployments.

  • Subscriptions and Number of Pods: Be mindful about the number of pods you deploy into a single Microsoft Azure subscription, especially if you plan to have each pod running at a large scale. Even though multiple pods can be deployed into a single Microsoft Azure subscription, whether all into one region or spread across multiple regions, Microsoft Azure imposes certain limits within a single subscription. Because of those Microsoft Azure limits, deployment of many pods into a single subscription increases the likelihood of hitting those limits. Numerous variables, and combinations of those variables, are involved in reaching those limits, such as the number of pods, the number of farms and assignments within each pod, the number of servers within each pod, the number of desktops within each assignment, and so on.
    If you plan to have pods running at a large scale, consider adopting the approach of having multiple subscriptions with those multiple subscriptions under one Microsoft Azure account. Microsoft Azure customers can, and often prefer, this approach because it provides some benefits for ongoing management of the subscriptions. Using this approach, you would deploy a single pod per subscription, roll up those subscriptions in a single "master account", and avoid the chances of hitting the Microsoft Azure limits that are imposed on a single subscription.
  • Outbound Internet access is required on the Microsoft Azure Virtual Network (VNet) that is connected to the node's temporary jump box VM and pod manager VM (or plural VMs for the case where high availability is enabled on the pod). Proxy-based authentication is supported in this release. You must provide your proxy details in the pod deployment wizard. For pod deployment, specific DNS names must be reachable using specific ports and protocols. See VMware Horizon Cloud Service Deployment Guide for the connectivity requirements.
  • Subnet sizing: Expanding the size of the pod's subnets after the pod is deployed is not currently supported. As a result, for production environments, you should use subnet sizes that are large enough to accommodate the following requirements:
    • Management subnet: When deploying a pod, as of March 2019, the pod's management subnet is required to have a minimum of CIDR /27, where in previous releases a lower minimum CIDR of /28 was allowed. This change was made to reduce the occurrence of issues that can happen during pod updates due to lack of available IP addresses in the subnet. A CIDR of /27 provides for 32 IP addresses.
    • Desktop (tenant) subnet: Use a CIDR in the range of /24 to /21 to accommodate the VMs for your VDI desktops, the RDS images, and every server in the pod's RDS farms. For example, if you want your production pod to support up to 2,000 VDI desktop VMs, the minimum CIDR that will accommodate that is /21 (2048 IP addresses)
    For the feature to deploy the external gateway into its own VNet, the VNets must be peered. As a result, you must create the subnets manually in advance of running the deployment wizard. For the external gateway's VNet, its management subnet and back-end subnet must each adhere to the same minimum CIDR /27.

Knowledge of the following facts is useful before connecting Horizon Cloud to pods installed on-premises or in VMware Cloud on AWS.

  • If your Horizon Cloud tenant account was created on or after March 17, 2020 in one of the following regions: USA-2 or PROD1_NORTHCENTRALUS2_CP1, Europe-2 or PROD1_NORTHEUROPE_CP1, Australia-2 or PROD1_AUSTRALIAEAST_CP1, you must use Horizon 7 Cloud Connector version 1.6 or later to connect those pods to Horizon Cloud. The date on your Welcome to Horizon Cloud Service email is the date to use to determine if your tenant account was created after March 17, 2020. The email also states the region in which your account is created. Earlier versions of the Cloud Connector will have compatibility issues when used with tenant accounts created on or after March 17, 2020 in those regions.
  • Before connecting a second Horizon 7 pod to Horizon Cloud, you should log in to the Horizon Cloud Administration Console and complete the Active Directory domain registration process after connecting your first Horizon 7 pod to Horizon Cloud using the Cloud Connector's onboarding process. When you pair multiple Horizon 7 pods with Horizon Cloud before completing that Active Directory domain registration, unexpected results might occur when you eventually log in to the Administration Console to attempt the domain registration process.
  • Due to a known issue, when you are using an on-premises Active Directory domain to service a pod in VMware Cloud on AWS, slow access times might occur due to network latency or network congestion between that on-premises Active Directory domain and the pod in VMware Cloud on AWS which results in calls to the domain timing out. Symptoms of this latency typically include the Active Directory login screen failing to complete the login before timing out. If you experience such symptoms, configuring a writable domain controller in each in-cloud software-defined data center (SDDC) might help.

Product Documentation and Additional Helpful Resources

To access the product documentation for all deployment models of Horizon Cloud, see the VMware Horizon Cloud Service documentation landing page.

Visit the community site for helpful tips and to ask any questions. White papers are also available in the Resources section of the Horizon Cloud product page.

Known Limitations

The following limitations apply to all deployment types.

  • The Administration 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.

New Horizon Image Management Service has the following limitations.

  • Horizon Image Management Service only supports vCenter Server authentication based on user name and password credentials.
  • You can only have three import or publish operations in progress at a time. For example, importing can be in progress for one image while publishing is in progress for two images. Attempting to have more than three operations run simultaneously will result in images getting stuck in an In Progress state.
  • Horizon Image Management Service does not support the management of images for linked-clone workspace assignments. In addition, this release requires that you disable Horizon View Composer on any pods that you want to manage. You cannot publish images successfully when Horizon View Composer is enabled.
  • Horizon Image Management Service requires the privileges of the full, built-in Windows administrator to create a directory and install Horizon Agent on the virtual machines (VMs) cloned from managed images. For more information, see the Microsoft documentation topic Enable and Disable the Built-in Administrator Account.
  • If you import images from a cloud-connected pod and then use Horizon 7 Cloud Connector to unplug that pod, the imported images remain displayed on the Settings > Images page.
  • Topology with shared vCenters within pods is not currently supported.

Microsoft Azure deployments have the following known limitations.

  • 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.
  • This release does not support use of the following Horizon Agent features: VMware Logon Monitor service. By default, the Horizon Agents Installer disables the VMware Logon Monitor service in all installations that the installer performs.
  • During the ten-minute 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.
  • 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. The same FQDN can be used in both the external and internal Unified Access Gateway configurations on the same pod.
  • Your authenticated (logged in) session into the Administration Console will time out after the time setting that is configured in the Administration 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 Administration 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 Administration Console for 30 minutes or more, manually log out and then log back in.
  • 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 master 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.
  • The NSX Cloud capabilities in this release are not supported for Microsoft Windows Server 2019.
  • 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 Desktop 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.
  • 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 this release's Administration Guide.
  • 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.
  • 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 Administration Console might not reflect the data collected between the last retrieval time and the time at which you are viewing the reports in the Administration 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.
  • 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 master images, farms, and VDI desktop assignments.
  • Follow these rules when entering characters in the Administration 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 wizard to create a master 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.
  • 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.

Known Issues

Note: Known issues for Horizon 7 7.12 itself and earlier versions of Horizon 7 are contained in the release notes for the Horizon 7 software product. Horizon 7 7.12 documents are linked from the VMware Horizon 7 Documentation page. Even though you connect Horizon 7 pods to the cloud, the known issues for Horizon 7 itself reside in the Horizon 7 release notes.

The known issues are grouped as follows. Note: The numbers in parentheses stated next to each known issue refer to VMware internal issue-reporting tracking systems such as Bugzilla and Jira.

Active Directory Related Known Issues

  • New: When you remove a configured admin group from Active Directory directly before removing the group in the Administration Console's Roles & Permissions page, the following issues occur on the Roles & Permissions page. (2537147)
    You use the Settings > Roles & Permissions page to grant Horizon Cloud administrative roles to AD groups from your AD domain. If you remove an AD group from the AD domain before removing the group from the Horizon Cloud role:
    • The deleted group is listed on the Roles & Permissions page for that role as \unknown\XXXX
    • If you try to edit the Roles & Permissions page to add a new AD group while that \unknown\XXXX is displayed, an error occurs and the group details are not saved.
    Workaround: If you see \unknown\XXXX displayed for a role on the Settings > Roles & Permissions page, edit the role to remove the \unknown\XXXX group from the role before adding new AD groups to that role.
  • Primary bind account lockout is not detected until you perform an action involving Active Directory in the Administration Console. (2010669)
    Due to this issue, an administrator logged into the Administration 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 Administration 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 3070083.
    Workarounds:
    - Avoid reusing farm names.
    - As described in that Microsoft KB article, disable duplicate SPN checks in the Active Directory domain.

Cloud Connector, Universal Broker Plugin Installer Related Known Issues

  • When upgrading both Cloud Connector and Connection Server for a pod, make sure to monitor and verify the health of the pod during the upgrade process. Monitoring the pod's health can help with troubleshooting any issues that might arise. (2405911)
    Upgrading the Connection Server on a cloud-connected pod can sometimes result in problems with the health of that pod. If you then try to upgrade Cloud Connector on the unhealthy pod, the upgrade fails.
    Workaround: After upgrading Connection Server, verify that the pod is in good health. To view the pod's health status, first perform an Active Directory domain bind, which allows you to access the Capacity page in the Horizon Cloud Administration Console. On the Capacity page, verify that the pod shows a health status of Online or Ready. If the pod shows an unhealthy status, contact VMware Support to get help with resolving any connectivity issues involving the pod before you attempt the Cloud Connector upgrade.

Images, Farms, Assignments Related Known Issues

Note: The known issues listed here apply to pods deployed in Microsoft Azure.

  • 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 Administration 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 is not yet available in the cloud control plane for updating the agents in your existing farm VMs.
    Workaround: None. When the 20.1.0 version of the agent is available in the cloud plane, 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 Administration Console, the Agent Status column for those desktop VMs shows "Unknown" state, with reported agent errors.
    Workaround: In the Administration Console, use the Restart action to restart those VMs.
  • The Import Desktop wizard creates Windows Server 2012 images without the Desktop Experience enabled. (2101856)
    Due to a known issue, when you use the automated Import Desktop 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.
    Workaround: Generally speaking, you can avoid such sysprep issues when you create the master VM using the Import Desktop from Marketplace wizard and select Yes for the wizard's Optimize Windows Image toggle. If you are seeing this error for a master VM in which you did not use that option, or if you manually created that master VM, refer to VMware KB 2079196, Microsoft KB 2769827, Microsoft MVP article 615, as well as the VMware Horizon Cloud Service Administration Guide for best practices in configuring your master VM to minimize likelihood of having sysprep issues when you go to publish the image. 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 by following the steps in the Administration Guide, and apply the best practices described in the KBs. After you have On the Imported VMs page, 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 disabling the "tiledatamodelsvc" service in the image and then creating 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 a master image 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.

Agent Update Related Known Issues

Note: 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

Note: 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, True SSO Related Known Issues

Note: The known issues listed here apply to pods deployed in Microsoft Azure.

  • When your pod from a previous manifest version is updated to this release and that pod has two-factor RADIUS configured on its Unified Access Gateway instances and is also integrated with Workspace ONE Access, launching a desktop from the Workspace ONE Access portal using the browser displays 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.
  • 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.

User Interface Related Known Issues

Note: Unless otherwise noted in the known issue text, the known issues listed here apply to pods deployed in Microsoft Azure.

  • New 2020-Sep-8: The Administration Console's Help > About window is not accurate.
    When you click Help > About in the console, the information in the window is not accurate. Due to this issue, the text is hard-coded to always display Version 2.2 instead of stating something accurate and relevant about the tenant environment or about the cloud control plane environment in which you are working.
    Workaround: None
  • The Logon Segments chart displayed in the session dashboard has no data.
    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 disables 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. This issue applies to all types of pods.
    Workaround: None.
  • When using the Administration 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 Administration 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 Administration 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 Administration 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 Administration 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 Administration 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 Administration 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 Administration Console, clearing the browser cache, restarting the browser, and then logging back into the Administration 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 Administration 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 Client Related Known Issues

Note: The known issues listed here apply to pods deployed in Microsoft Azure.

  • Users get disconnected after one hour from their desktops or remote application sessions when using HTML Access (Blast) and PCoIP protocols. Also, when switching protocols in the client, if you choose the Connect choice instead of Log Out and Reconnect, the client might become unresponsive. (2519400, 2528014)
    Two inter-related issues are described here. The first 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.
    The second 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.
    Workaround: When the first issue of the forced disconnect occurs, the user can manually reconnect to their session and use it for an hour until the next forced disconnect. To avoid experiencing these forced disconnects in the session, connect using the RDP protocol. Note: Some Horizon 7 clients do not support the RDP protocol. Also, application farms only support Blast and PCoIP protocols. See also VMware Knowledge Base Article 78242. You can find the documentation for the Horizon Client versions from the VMware Horizon Client Documentation page at docs.vmware.com/en/VMware-Horizon-Client/
    To avoid the second issue of the client going unresponsive, you must select the Log Out and Reconnect choice when presented with that dialog box and your session is to an RDSH farm (session desktop or remote application).
  • 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.

Updates to Pods in Microsoft Azure Related Known Issues

Note: The known issues listed here apply to pods deployed in Microsoft Azure.

  • While a pod is undergoing an update, active end user sessions to that pod are disconnected. (HD-12577)
    During the ten-minute process of updating a pod from an earlier software level to the latest one, end users who have connected sessions to the updating pod will see those active sessions disconnected. However, 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.
    Workaround: None. After the update process is complete, those users can reconnect. To prevent data loss for end users, before running the update, make sure the settings in the pod's farms and VDI desktop assignments do not have Logoff Disconnected Sessions set to Immediately.

Horizon Image Management Service Known Issues

  • New When you delete an image version, it is not removed from the Content Library in vCenter Server. To delete it from the Content Library, you can log into the vCenter Server and follow the instructions in the VMware vSphere documentation. This issue will be resolved in the next release. (2565248)
  • New If you have two pods in the same vCenter Server, the system prompts you twice for the vCenter Server credentials during the import process and then replicates the image on the vCenter Server when you publish it. The VMware team is actively working on a resolution for this issue. (2468092)

Localization Related Known Issues

Note: The known issues listed here apply to pods deployed in Microsoft Azure.

  • When you are adding or editing locations in the Administration Console, location names are not localized. (2366913, DPM-3282)
    Workaround: None.
  • When non-ASCII or high-ASCII characters are used in the True SSO template name, retrieving the template fails. (1951143)
    Due to this known issue, if your True SSO template name contains non-ASCII or high-ASCII characters, you cannot successfully configure True SSO with your Horizon Cloud environment.
    Workaround: To avoid this issue, use only ASCII characters in the names of your True SSO templates.
  • Some of the strings in the Desktop Health page's desktop health alerts are not localized. (2019363)
    Workaround: None.

Previous Issues Resolved in this Release

This release resolves the following issues reported in the previous release:

Resolved Cloud Connector, Universal Broker Plugin Installer Related Issues

  • 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)
    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.
    This issue is resolved in Version 1.6 of the Horizon 7 Cloud Connector.
  • 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)
    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.
    This issue is resolved in Version 1.6 of the Horizon 7 Cloud Connector.

Resolved Images, Farms, Assignments Related Issues

  • If the number of servers in a farm is changed to 0, it causes any future attempt to edit the farm to fail with an Unknown Error. (2461088, 2463147)
    It is possible to edit the number of servers in a farm in the Administration Console (Inventory › Farms › ‹farm name› › Servers). If all of the servers listed on this tab are deleted, it sets the number of servers at 0. If you later try to make changes to the farm, the value of 0 will be submitted and rejected by the system as invalid. This causes the edit to fail and return an Unknown Error.
    Workaround: This issue is resolved in this release.

Resolved Image Management Service Related Issues

  • New  When you import a new image into your environment, it gets stuck at the "deploying VM" step. (2557389)
    Workaround: This issue is resolved in this release.
  • New  When are performing actions on images, the images can be stuck in "in progress" state for a long time, without showing either success or failure of the action. (2523399)
    Workaround: This issue is resolved in this release.