Horizon DaaS 9.1.x | 07 JAN 2021

See Revision History below for additions and updates to these release notes.

Links to release notes for other versions: 8.0.0 | 8.0.1 | 9.0.x

What's in the Release Notes

The release notes cover the following topics:

Product Documentation

All product documentation for Horizon DaaS is located on the VMware Horizon DaaS documentation landing page.

Note: The documentation linked from the Service Center and Administration Console interfaces is shared between the two products and is labelled with the Horizon Cloud Service product name. These documents, the Service Provider Administration and Tenant Administration guides respectively, are identical in content to the same documents that you access on the VMware Horizon DaaS documentation landing page.

Compatibility Information

For the most recent information about compatibility between this product and other VMware products, see the VMware Product Interoperability Matrices.

Software Versions Required for Upgrade

Before upgrading to Horizon DaaS 9.1.0, confirm that the service provider and tenant appliances in your environment are running Horizon DaaS 9.0.0 or 9.0.1. These are the versions required for upgrade.

Note Regarding Appliance Restore After Upgrade

Restoring Horizon DaaS platform appliances to previous versions after upgrading to the 21.1.0/9.1.0 release is supported.

To ensure that the platform setup can support anticipated/unexpected restores of any appliances of version 20.2.0/9.0.0/9.0.1, before performing the Restore you must copy the entire directory (/opt/vmware/horizon/link/transfer/ from the 20.2.0/9.0.0/9.0.1 Horizon Air Link appliance to the new 21.1.0/9.1.0 Horizon Air Link appliance at the same path (/opt/vmware/horizon/link/transfer/). This can be done at any point in time after installing the 21.1.0/9.1.0 Horizon Air Link appliance, including after upgrading the platform Management appliances (SPs and RMs).

New Features

Service Provider Administration

  • With this release, security enhancements have been made to harden the management appliances and Horizon DaaS platform services.
  • With this release, the Service Provider, Resource Manager, and Tenant Appliances will be upgraded to Ubuntu 18.04 LTS as part of the Blue/Green upgrade process.

Tenant Administration

  • Tenant Auto Agent Update (AAU) has been enhanced to upgrade persistent desktop assignments and golden images using different Horizon Agent Installer (HAI) versions, based on OS type and version.

  • Tenant Auto Agent Update (AAU) has undergone several enhancements for stability and functionality, including the ability to roll back the agent update for a desktop if that was enabled beforehand.

  • Support for VMware Instant Clone Smart Provisioning, where the provisioning mode (A or B) depends on environmental factors like pool size and image size. has been added. For more information, see https://techzone.vmware.com/?share=video2745.

Top of Page

Best Practices

Knowledge of the following facts is useful before using Horizon DaaS.

Deploying Horizon DaaS at Scale

The following are best practices for building and scaling a Horizon DaaS production deployment:

  • Each Tenant Resource Manager (RM) supports a maximum of 18 tenants (with 12 tenants as the recommended maximum).
  • Each Tenant RM manages only a single vCenter Server instance. 
    • The vCenter Server instance manages a maximum of 10,000 VMs, across multiple clusters.
  • When a tenant requires multiple Desktop Managers (the Tenant Appliance being also a Desktop Manager), each DM must be assigned to a separate vCenter cluster. So for large tenants with two DMs, there must be assigned to two seperate vCenter clusters, but those can be managed by the same Tenant RM which is managing the vCenter Server instance for both clusters. Please keep in mind best practices for vCenter Server scalability (including recommendations when using VMware App Volumes for application lifecycle management). 

Example: A Horizon DaaS production deployment with 60 tenants each needing only the Tenant Appliances, with a single capacity collection assigned to the Tenant, and each Tenant running fewer than 2,000 VMs.

For this environment the recommended setup would be:

  • Datacenter Service Provider appliances pair.
    • The Service Provider connects to a vCenter Server for the management appliances.
    • Although this vCenter is only for the platform management function, it doesn't need to be dedicated to that task and can be used for other management functions. 
    • The Service Provider does not connect directly to vCenter but uses the HAL appliance for the any operations towards vCenter. 
  • Five Tenant RMs, each managing 12 tenants.
  • To support the tenant desktop workloads, five (5) vCenter Servers with clusters, and the number of clusters depending on whether dedicated or partitioned clusters are used.
    • Recommended maximum of 10,000 VMs per vCenter Server.
    • Each Tenant Appliance or Desktop Manager manages a maximum of 2,000 desktops or sessions.
    • For large tenants, it is recommended to dedicate the vCenter Server cluster.
  • 60 Tenant Appliance pairs (and most likely 60 Unified Access Gateway pairs as well).
  • If some of those tenants need another DM, then those DMs can be assigned to an existing Tenant RM, but not to the Tenant RM that is assigned to the Tenant Appliance of the same tenant.
    • Keep in mind the recommended maximum of 12 tenants supported per Tenant RM.    

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.

Creating a Template Desktop VM

When you are creating a template VM, after you have finished configuring it run the following command in Windows PowerShell:


This prevents a possible sysprep issue that leads to image publish failure.

Refreshing Desktop Capacity Information on Tenant Quotas Tab

When editing a tenant, if the Desktop Capacity information on the Quotas tab is not correct, then refresh the page to correct this. In particular, the In Use value for Std Capacity may sometimes display incorrectly and need to be refreshed.

Known Limitations

Customer Appliance Configuration Changes Do Not Persist After Upgrade

After you upgrade your environment, custom configuration settings that you made (for example, modifying disk timeout) do not persist and need to be re-applied manually when the upgrade is complete. 

User Activity License Report - Data Does Not Persist After Upgrade

After you upgrade your environment, data for User Activity License Reports (formerly known as Concurrent Users License Reports) run before the upgrade is no longer available. To avoid this issue, it is recommended that you save any data you want to keep before performing the upgrade.

Horizon Version Manager - Connection to vCenter Server Using FQDN

If your Active Directory and DNS Server are running on the same machine, you may find that Horizon Version Manager cannot reach the vCenter Server by its Fully-Qualified Domain Name (FQDN) while still being able to connect using its IP address. The workaround for this is to add host entries to the /etc/hosts file for the FQDN. For example: vc1dc1.newdaas.local xx.xxx.xx.xx

After Failed Deployment - Manual Clean-Up Required

For security reasons, after a failed Horizon DaaS deployment you are required to perform a manual clean-up of the primary service provider appliance (SP1). During deployment, Horizon Air Link establishes temporary SSH trust between the installing node and SP1 by copying the node's SSH public key to the SP authorized keys list. In a successful deployment these keys are removed automatically after the deployment is complete. But when there is an unexpected deployment failure, you need to remove these keys manually.

Migrating Between Clusters in Multi-DM Environment

In a multi-DM environment with two clusters assigned to different (but linked) vCenters, if you migrate a VM from one cluster to the other, the migrated VM is marked as deleted in the tenant FDB and is not available for use. The workaround for this is to wait for the system to perform a full inventory update. This can take up to 12 hours. [2187188]

Connecting to Administration Console Using Mozilla Firefox

  • Attempting to connect to the Administration Console via Mozilla Firefox can fail with a connection timeout due to a bug in Firefox. The workaround for this is to change the name of certificate file, which is located in the C:\Users\‹username›\AppData\Roaming\Mozilla\Firefox\Profiles\‹filename›.default directory and has a name similar to cert1.db, and then restart the browser.

  • Attempting to connect to the Administration Console via Mozilla Firefox fails when you are using a self-signed certificate (normally in a development environment). You can avoid this issue by using another browser.

DNS Server IP Edits for Domain Join Require Support Ticket

When editing an existing Active Directory Domain, you can no longer directly edit DNS Server IPs in the Administration Console. To change DNS Server IPs, file a ticket with VMware support.

Default Limit of 2,000 Desktops Per Pod

There is now a default limit of 2,000 VMs per pod, both in desktop assignments and in farms. This includes VMs created in earlier versions of the product but does not include Utility or Imported desktops. When you are creating or editing an assignment or farm and the remaining capacity displayed appears to be too low, it may be because this limit has been reached. The default limit of 2,000 can be adjusted on request. For more information, contact your VMware representative.
Note to Service Providers: When registering or editing a tenant, you can change this setting by modifying the value in the new Max Desktop Count Per DM field on the General tab. 

Agent Upgrade to HAI 18.4 Requires Use of BAT File

When you upgrade from an older agent build to the HAI 18.4 using the HAI user interface, the installer creates the HAI-upgrade.bat file and then interrupts the upgrade, prompting you to close the user interface and complete the upgrade using the BAT file.

When the upgrade is complete, the VM will be rebooted automatically. You can prevent this reboot by doing either of the following:

  • Update the command-line options in the HAI user interface before the BAT file is generated, adding /norestart at the end of the command.
  • Manually update the generated HAI-upgrade.bat file, adding /norestart at the end of the command.

Note: The VM must be rebooted sometime after the upgrade in order for the Agent to be usable.

Updating Images Using Console Access

Performing updates to images (such as updating agents) using console access without taking the image offline and then accessing it via the Helpdesk Console (beta feature) is not supported and can cause issues with the image and subsequent pools spun up using this image. Do not attempt to perform image updates this way. Always duplicate the image from the Admin Console and then update it using the HACA Console.

Copying and Pasting Between Client System and VM With HTML Access

Copying and pasting text between a client system and a VM is supported by default when the user is connected via the Horizon Client. When the user is connected via HTML Access, however, you must configure this feature before the customer can use it. For more information, see the VMware Horizon HTML Access documentation.

Users Still Able to Log into Dedicated Desktops After Being removed From User Group

If a user is in an Active Directory group that is assigned to a dedicated desktop assignment, once the user has logged into a particular desktop they will be able to continue logging into that same desktop until the user is unassigned from that desktop in the Administration Console, unless either the user is removed entirely from the Active Directory or the desktop is deleted.

Wait Time for Generating Admin Activity Report

When you initiate an export on the Admins tab of the Activity page (Monitor > Activity > Admins), there is an interval of time as the system generates the report, during which you are not able to perform other tasks in the Administration Console. Depending on the number of records, this interval can be several minutes long. For the maximum report size (50,000 records), the wait time is approximately 10 minutes.

Data Sorting in Exported User Activity Report

When you export data from the Users tab of the Activity page (Monitor > Activity > Users), the data in the generated .csv file is not sorted by date. There are two options for correcting this:

  • Open the .csv file in Excel and set the date format for the cells containing dates to mm/dd/yy hh:mm AM/PM (e.g. 3/14/12 1:30 PM).
  • Create a new blank Excel workbook and then use the data import wizard to import the .csv file.

Converting a Desktop to an Image

If you initiate converting a desktop to an image but cancel before the task finishes, a second attempt to convert the desktop to an image may fail. To avoid this issue, you should power off the desktop and power it on again before attempting to convert it to an image a second time.

Time Interval Before Changes to Settings Take Effect

When you change one of the following settings, it can take up to 5 minutes for the change to take effect.

  • General Settings page (Settings > General):
    • Session Timeout - Client Heartbeat Interval, Client Broker Session, Client Idle User
    • HTML Access - Cleanup credentials when tab is closed
    • Pool/Farm Options - Enable Client Retry
  • Identity Management page (Settings > Identity Management):
    • Select item and click Configure - Force Remote Users to Identity Manager

Service Provider Information

When you change one of the following tenant policies, it can take up to 5 minutes for the change to take effect.

  • desktop.connection.corrective.action.required
  • desktop.connection.retry.count
  • client.retry.enabled
  • element.session.logontiming.enabled
  • jms.agent.allow.mmr
  • jms.agent.allow.usb

Resolved Issues

The following issues have been resolved in this release.

  • When the Active Directory group assigned the Super Administrator role was moved to another OU within Active Directory, Admin users in that group were able to login to the Administration Console but were not able to make changes. This issue has been remedied so that users can make changes as expected. [2554690]

  • When you removed a configured admin group from Active Directory directly before removing the group in the Administration Console, this caused two issues on the Settings > Roles & Permissions page:

    • The deleted group was listed as \unknown\XXXX.
    • If you added a new admin group to the existing list, an error occurred and the group details were not saved.

    This Active Directory problem has been resolved, so that these issues no longer occur. [2543068]

Known Issues

Service Provider Issues

Issues that are new in this release are in bold.

  • When using a vCenter instance supporting multiple tenants, the recommended maximum number of tenants is 12, and the maximum supported is 18. To support more tenants, you must add another Tenant Resource Manager and add another vCenter instance.  

    Workaround: None. This capacity will be expanded in future releases.

  • After upgrade, settings for Unified Access Gateway (UAG) can be lost, preventing users from accessing desktops.

    Workaround: Run the apsetup script on each tenant appliance:

    sudo /usr/local/desktone/scripts/apsetup.sh


  • If you change the name of a tenant in Service Center, the name is not changed in vCenter and upgrading that tenant fails.

    Workaround: Change the tenant name in vCenter and retry the upgrade.


  • During upgrade, the tenant migration can fail with the following error:

    Failed to connect virtual device Ethernet0

    Workaround: Follow the instructions in Knowledge Base article 2093588.


  • If you attempt a rollback to the previous version, you might see a HAL error saying "java.rmi.RemoteException: VI SDK invoke exception:javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake". This can occur when the size of the /opt/vmware/horizon/link/conf/settings.json configuration file is too large.

    Workaround: Clean up any failed/completed jobs along with any unnecessary manifest versions.

  • If you attempt a rollback to the previous version, you might see a HAL error saying "Given final block not properly padded.javax.crypto.BadPaddingException: Given final block not properly padded". This can occur because of a bug in the Java encryption/decryption module.

    Workaround: Remove the jobs manually from the JSON file.

Tenant Administration Issues

Issues that are new in this release are in bold.

The known issues are grouped as follows:

Active Directory - Known Issues

  • It takes up to 15 minutes for the Administration Console to reflect a lockout or unlocked state of the primary bind domain account.

  • 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.  [2009434]

  • 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). 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.


    • Avoid reusing farm names.
    • As described in that Microsoft KB article, deactivate duplicate SPN checks in the Active Directory domain.


Images, Farms, Assignments - Known Issues

  • In large deployments, it is possible for a small number of VMs in a floating desktop assignment to go into an Unknown state because some Windows Services, like the Blast Service on the agent, do not start and the agent heartbeat reports AGENT_ERR_PROTOCOL. In this case, hovering over the Agent Status value for the VM displays a tool tip indicating an agent error.

    Workaround: Restart the VM from the Assignment page or log into the VM via RDP and restart the VMware Blast service from Windows Services. [2406279]

  • When you attempt to update the agent on an image, the convert-to-image task may fail on the cloned VM. 

    Workaround: Delete the clone VM (not the original image) and retry. The clone VM will appear in Utility VMs. If the retry is unsuccessful, save the clone VM, perform the steps below to get the DCT logs, and then contact your VMware representative.

    1. On the clone VM, browse to C:\Program Files\VMware\VMware View\Agent\DCT and open the file 'support.bat'.

      A cmd prompt window opens and prints several messages stating which logs are currently being gathered. This process may take a few minutes to complete.

    2. When prompted to collect dump files enter 'n' unless VMware has requested that you gather dump files.

      A zip file is placed on the desktop containing collected logs.

    For more information on obtaining logs, see the following KB: https://kb.vmware.com/s/article/1017939.


  • When you use the Update Agent feature from an agent version earlier than 18.2.2, the update process can hang on desktops that have a 'run once' pending.

    Workaround: Perform the agent update, adding the following command line argument on the Command Line tab of the Agent Update wizard:


  • When you have two dedicated desktop assignments associated with the same group of users, the following issue can occur. If a user opens a desktop from one of the assignments using the Horizon Client and then a user attempts to open a desktop from the other assignment with the Horizon Client, the second attempt fails with an error indicating the user is not entitled to the desktop.

    Workaround: Open the desktop in the second assignment using the browser instead of Horizon Client. [2201599/1813881]

  • When you push updates for a traditional clone assignment, a small number of VMs may enter a PXE boot error state. For example:

    • PXE-E53 : No boot filename received
    • PXE-MOF: Operating System not Found.

    Workaround: This is a NetApp issue, so there is no workaround in Horizon DaaS.  [1969642]

  • When a user is entitled to a dedicated desktop assignment, that assignment appears under Assignments in the user detail information shown when you click on the user's name in the Administration console. However, after the user launches a desktop from the assignment, it no longer appears in the user detail information.

    Workaround: None.  [1958046]

  • Shrinking an Instant Clone assignment can sometimes fail to delete one of the VMs, which then goes to a powered off state.

    Workaround: Power on the VM. When it is powered on and visible in the assignment, shrink the assignment again. [2027097]

  • If you attempt to create a farm using a Windows Server 2016 image, the VMs may hang at the customization stage.

    Workaround: Deactivate the tiledatamodelsvc service on the Windows Server 2016 image and then create the farm. [2010914]

Reports - Known Issues

  • When CPU usage on a desktop is very high--for example, when an application is using 100%--the Desktop Health alert notification does not display on the Desktop Health tab of the Reports page.

    Workaround: None.  [2015486]

  • When IPv6 is enabled on an image, the abnormal IP notification may not display on the Desktop Health tab of the Reports page.

    Workaround: Deactivate IPv6 for the image.  [2017500]

User Interface - Known Issues

  • The Administration Console displays as blank.

    Workaround: Contact your VMware representative, who can resolve this issue for you.

    Service Provider information - Since default edb/avdb failover is now deactivated by default, TA1 will always be master and TA2 will always be secondary, even when TA1 is offline. In the past TA2 could be accessed once auto failover occurred following an outage on TA1 which was greater than 5 minutes. Now that auto failover does not take place, admins will reach a blank web page when attempting to open the horizonadmin portal. If TA1 is not brought back online, you will need to force a manual failover of the fdb and edb via the Maintenance page in Service Center. Once this failover has taken place full user and admin functionality will be restored. [2209292]

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

    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. [2015772]

  • Some pages in the Administration Console do not display correctly in the Safari browser.

    Workaround: Use a different browser to access the Administration Console. [1956356/1956348 ]

App Volumes - Known Issues [these are in SP Release Notes only]

  • After the App Volumes agent is installed on an image VM, the App Volumes agent is not able to communicate with the App Volumes Manager until the DaaS agent pairing process is completed. The following error message is displayed: "Connection Error, Unable to contact App Volumes Manager. Virtualization is disabled".


    1. Prior to installing App Volumes agent, ensure that the DaaS agent pairing process is completed.
    2. If DaaS Agent pairing occurs after the App Volumes agent is installed, ignore the connection error and click OK. If the DaaS agent is paired later, the connection is set up automatically.


Localization - Known Issues

  • When non-ASCII or high-ASCII characters are used in the True SSO template name, retrieving the template fails and True SSO cannot be configured successfully.

    Workaround: Use only ASCII characters in the names of your True SSO templates.  [1957829]

  • Some text on the Desktop Health tab of the Reports page is not being localized.  

    Workaround: None   [2019363]

Revision History

Date Description
07 JAN 2021
  • Initial release
23 MAR 2021
  • Added Required Versions - 2733701
check-circle-line exclamation-circle-line close-line
Scroll to top icon