VMware Horizon® Cloud Service™ on Microsoft Azure | 20 September 2018
These release notes apply to node manifest versions 965 and later. For the release notes of earlier node manifest versions, see the release notes for product version 1.6, located from the VMware Horizon Cloud Service on Microsoft Azure documentation landing page.
The contents of this document was last changed on: 20 SEP 2018 for the go-live date of this service release.
Check for additions and updates to these release notes.
What's in the Release Notes
The release notes cover the following topics:
- About VMware Horizon Cloud Service on Microsoft Azure
- What's New
- Environments, Operating Systems, and Compatibility
- Before You Begin
- Best Practices
- Product Documentation and Additional Helpful Resources
- Known Limitations
- Known Issues
- Previous Issues Resolved in this Release
About VMware Horizon Cloud Service on Microsoft Azure
With VMware Horizon Cloud Service on Microsoft Azure, your end users can securely access their virtual desktops and remote applications from any device. The environment combines the management simplicity of the Horizon Cloud control plane with the economics of Microsoft Azure. The overall environment consists of the VMware-hosted cloud service, your provided capacity in the Microsoft Azure cloud, and VMware software deployed into that capacity. You connect your Microsoft Azure subscription to Horizon Cloud to manage and deliver VDI desktops, session-based desktops, and remote applications. Setting up the environment involves deploying the required VMware software into your Microsoft Azure capacity. The deployed VMware software creates an appropriately configured entity, called a Horizon Cloud node, which pairs with the control plane. After the node is deployed, then you use the control plane to create RDSH farms, VDI desktop assignments, and entitle virtual desktops and applications to your end users.
The VMware Horizon Cloud Service on Microsoft Azure 1.7 release includes the following new features. For details, see this release's Administration Guide.
- Support for additional Microsoft Azure VM types for VDI desktops and RDS farm servers. Note: With this new support, after you update your existing nodes to this release level, the Administration Console's Create Farm and Create Desktop Assignment workflows will display the names of the Microsoft Azure VM types and no longer display the descriptive labels used in previous releases such as Small, Medium, Large or Standard, Enterprise, Enterprise Plus.
- Ability to use Microsoft Azure encrypted disks for VDI desktops and RDS farm servers.
- Support for using Microsoft Windows 10 Pro Version 1803 and Pro N Version 1803 for VDI images.
- Ability to automatically optimize the master image when using the Import Desktop from Marketplace wizard. This optimization helps avoid Microsoft Sysprep issues that can occur during the image sealing (publishing) workflow.
- Support for deploying a node using Microsoft Azure VNet subnets created in advance.
- Ability to deploy a node with an internal Unified Access Gateway configuration. This configuration enables end users within your corporate network to have trusted HTML Access (Blast) connections to their desktops and remote applications. You can also add an internal Unified Access Gateway configuration to a node that was initially deployed without one. If the node has a manifest earlier than 935, you must first upgrade the node before you can add the new internal Unified Access Gateway configuration to the node.
- Ability to have the node deployer create a VMware Identity Manager™ tenant when deploying a node. Note: This feature is available during the workflow of deploying a new node at this release's node manifest level. The Administration Console does not provide for the VMware Identity Manager™ tenant creation workflow on an existing node. When you have used this option during creation of a node at this release level, the VMware Identity Manager™ tenant is associated with your Horizon Cloud customer record and you can configure the integration of the new tenant with the nodes that exist for the same Horizon Cloud customer record.
- Ability to have the update agent workflow on a VDI dedicated assignment skip those dedicated desktops that have with disconnected active sessions, and optionally have the system automatically retry the skipped VMs.
- Ability to use the Administration Console to reset the Active Directory domain information connected with your Horizon Cloud customer record. Previously, only the VMware Operations team could reset the Active Directory domain in your customer record. This feature is available when you have only one node associated with your customer record, only one associated Active Directory domain, and the node has no artifacts such as imported VMs, images, farms, VDI desktops, or True SSO configurations.
- Support for changing the number of sessions per RDSH server after a farm is created.
- Change to the Import Desktop from Marketplace workflow to use VMs from the Dv3 family instead of Dv2 VMs.
- Ability to customize the power-off protect time used in the system's power management feature for VDI desktop assignments. Previously, this time was 30 minutes by default and not customizable.
- Support for using the GPO policy 'Domain controller: LDAP server signing requirements' set to 'Require signing' to have secure Active Directory bind between the node and your Active Directory.
- Enhancements to the user card to see historical session data. The user card provides the help-desk-related features for troubleshooting disconnected and logged-off sessions.
- Improved error handling and messaging during the node deployment process and during the image import process.
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: The service is currently available in the following Microsoft Azure cloud environments:
- Microsoft Azure (standard global regions)
- Microsoft Azure in China
- Microsoft Azure Germany
- Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas)
Supported Microsoft Windows Operating Systems The following Microsoft Windows operating systems are the ones that can be deployed in this release of Horizon Cloud Service on Microsoft Azure. These are the Microsoft Windows editions and versions in the Azure Marketplace that are supported for use in this release, regardless of whether you use the automated or manual method of deploying an image in this release. No Windows versions other than the ones listed below are supported in this release.
- For RDS images used in farms: Microsoft Windows Server 2012 R2 Datacenter Edition and Microsoft Windows Server 2016 Datacenter Edition
- For VDI images: Microsoft Windows 10 Pro Versions 1709 and 1803, Microsoft Windows 10 Pro N Versions 1709 and 1803
- Supported Horizon Client versions This release supports the use of the following Horizon Client versions with the desktops and remote applications delivered by the environment, as listed below. 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/
- With RDS-based session desktops and remote applications: Horizon Client versions 4.7, 4.8, and 4.9
- With VDI desktops: Horizon Client version 4.8 and 4.9.
- The VMware Horizon HTML Access client does not support certain features when used in mobile browsers. See features listed in the note on this topic page in the VMware Horizon HTML Access User Guide 4.9: docs.vmware.com/en/VMware-Horizon-HTML-Access/4.9/html-access-user/GUID-20F0C9F6-7DE9-4D3D-8095-391C9F795F54.html . 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 topic at docs.vmware.com/en/VMware-Horizon-HTML-Access/4.9/html-access-installation/GUID-649151B0-070F-463B-B7FD-12B500973BF0.html.
Before You Begin
Review this information as you prepare to deploy this release of VMware Horizon Cloud Service on Microsoft Azure.
- Set-Up Prerequisites: Review the set-up prerequisites before you start creating a Horizon Cloud node in your Microsoft Azure cloud. See the following documents:
- Software Downloads: Review the software downloads you might want for your environment from My VMware®. Even though these downloads are optional to have before you get started with your deployment, you might want to review them prior to deploying. See the VMware Horizon Cloud Service on Microsoft Azure 1.7 download page.
- User Settings Persistence: You can provide persistence of user profiles using VMware User Environment Manager™ with folder redirection. You can download the User Environment Manager software that is supported for use with this release from the VMware Horizon Cloud Service on Microsoft Azure 1.7 download page.
Knowledge of the following facts is useful before using VMware Horizon Cloud Service on Microsoft Azure.
Subscriptions and Number of Nodes: Be mindful about the number of nodes you deploy into a single subscription, especially if you plan to have each node running at a large scale. Even though multiple nodes 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 a large number of nodes 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 nodes, the number of farms and assignments within each node, the number of servers within each node, the number of desktops within each assignment, and so on.
If you plan to have nodes 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 node 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 node manager VM. Proxy-based authentication is supported in this release. You must provide your proxy details in the node deployment wizard. For node deployment, specific DNS names must be reachable using specific ports and protocols. See Getting Started with VMware Horizon Cloud Service on Microsoft Azure for the connectivity requirements. Note: When you have a proxy configured for the node, you must use the manual steps to create your base master VMs. You cannot use the automated Import Image wizard when your node is configured for proxy-based authentication.
- 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.
- Subnet sizing: This release does not support expanding the size of the node's subnets after the node is deployed. As a result, for production environments, you should use subnet sizes that are large enough to accommodate the following requirements:
- Management subnet: Use a CIDR of /28 to accommodate running a node that has both external and internal Unified Access Gateway configurations and upgrading that node when a node upgrade is made available. A CIDR of /28 provides for 16 IP addresses. Because Microsoft Azure reserves 5 IP addresses on a subnet for its use, and a node with both Unified Access Gateway configurations has 5 VMs on the management subnet, and the upgrade process requires a parallel set of 5 VMs and a temporary jump box VM while the upgrade is in progress, a CIDR of /28 (16 IP addresses) accommodates having enough IP addresses available during future node upgrades.
- 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 node's RDS farms. For example, if you want your production node to support up to 2,000 VDI desktop VMs, the minimum CIDR that will accommodate that is /21 (2048 IP addresses)
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.
- This release does not support expanding the node's subnets after the node is deployed. Before you deploy a node, you must ensure the address spaces for the subnets you specify in the deployment wizard are large enough to accommodate your expected usage.
- Due to a known issue in VMware Identity Manager, when Workspace ONE displays the remote applications that you sync from Horizon Cloud, Workspace ONE does not display the display names that you set for those remote applications in Horizon Cloud. Even though Horizon Cloud sends the display names to VMware Identity Manager, VMware Identity Manager is not using those display names that it receives from Horizon Cloud. As a result, Workspace ONE displays the basic names for the remote applications.
- 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 node 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.
- In this release, each node 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 node.
- 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. 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 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.
- 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, Microsoft Windows Server 2016 is 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.
- 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 node in Microsoft Azure after you have already configured True SSO for previously deployed nodes, the system does not automatically pair the new node 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 multi-node environment, you cannot reuse names that you used in one node when creating items in another node. The reason for this limitation is that nodes in the multiple-node environment share the same Active Directory domain and the same VNet. As a result, if names are shared within such multiple-node 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.
The known issues are grouped as follows:
- Active Directory
- Images, Farms, Assignments
- Agent Update
- Identity Management, True SSO
- User Interface
- End User, Horizon Client
- Node Updates
Note: The numbers in parentheses stated in each known issue refer to VMware internal issues tracking systems.
Active Directory Related Known Issues
If you add the same Active Directory user group to both the Super Administrator role and Demo Administrator role, those users experience unexpected restricted behavior in the Administration Console. (1963653)
The Super Administrator role is intended to grant all the permissions to perform all management actions in the Administration Console, and the Demo Administrator role is a read-only role. However, due to this known issue, if you add the same user group to both roles, those users do not receive the permissions of the Super Administrator role. Their actions are restricted in the Administration Console, which might prevent availability of full management of your environment.
Workaround: Do not assign the same user group to both roles.
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 node 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).
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.
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.
- Avoid reusing farm names.
- As described in that Microsoft KB article, disable duplicate SPN checks in the Active Directory domain.
Images, Farms, Assignments Related Known Issues
When publishing an image, on the Activity page, you see the task to publish an image fails, and the system task to convert the failed image back to a virtual machine also fails. (2200968)
Due to intermittent connectivity in the Microsoft Azure cloud, publishing an image can fail in this way. In the Activity page, you see an error message that says the request to create the image failed and converting the image back to the virtual machine also failed. Typically, trying the Publish action a second time on the image succeeds.
Workaround: Try using the Publish action again on the image.
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. However, the Scanner Redirection feature is not supported for use in this Horizon Cloud Service release even though you might choose to install that feature.
If a floating VDI desktop assignment is using a manually created master image having extra data disks, the desktop VMs' data disks persist in your Microsoft Azure environment until the VM is deleted. (2106913)
Data disks are not officially supported in this release. If you use the manual method to create a master image which results in a VM with extra data disks, when you subsequently use that master image in a floating VDI desktop assignment, the desktop instances based on that master image are created in the assignment with those data disks usable by the users that connect to use those desktops. When a user disconnects from a desktop and the system performs its standard revert operation to refresh the desktop for use by another user, the desktop's extra data disks are removed from the desktop VM. However, due to this known issue, those data disks might persist in your Microsoft Azure environment. Only after the desktop VM is deleted does the system delete such extra disks from your Microsoft Azure environment.
Workaround: When you use the manual method to create a base image that you plan to use in your floating VDI desktop assignments, avoid creating one that has extra data disks.
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 similar to "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 on Microsoft Azure 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.
The Administration Console reports a farm's servers' DaaS agents are active and their VMs are in success state several minutes before the VMs are actually ready to use for assigning RDS session desktops and applications using that farm. (1941076)
Due to this known issue, after you create a farm and the Administration Console indicates the farm's servers are ready for you to start assigning RDS session desktops or remote applications using that farm, when you navigate to Assignments screens, you see on-screen messages about needing RDSH servers or farms out of capacity. These symptoms result from the Administration Console reporting the farm's servers are ready several minutes before the connection broker to the Horizon agent on the server VMs is completely ready.
Workaround: To avoid this issue, delay creating assignments using a farm for at least 15 minutes after the user interface indicates the farm is ready.
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 New Image or Convert to Image workflows report the agent as 'Active', you can ignore the 'undefined' status on the Imported VMs page.
Conversion of a desktop VM to an image VM and then back to a desktop VM fails. (1965320)
When you create a new image, then run Publish on it and it reaches Published status, then you run Convert to Desktop on that image, then run Publish again, the sysprep process that happens in the publishing workflow can fail. If you again convert the image back to an unsealed image, from that point on, the image might always fail the publishing workflow.
Workaround: None. If you find the image is always failing the publishing workflow, it is prudent to start fresh and make a new base image.
Agent Update Related Known Issues
When using the Update Agent action on an image, the workflow might fail and the Activity page reports an error that the agent is not running or not reachable. (2202375)
One of the system tasks in the Update Agent workflow on an image is to duplicate the sealed image to make a new duplicate VM. Then the system runs the agent update on that new VM and then publishes it to make it a sealed image. Due to a timeout, the publishing step might fail and the duplicate image fails to become a sealed image. The Activity page has a message that says Converting to an image -Error The Agent on the virtual machine is not running or not reachable.
Workaround: Delete the duplicate image that the Activity page says failed. Using the image that you originally chose to update, retry the Update Agent action.
When you use the Update Agent feature to update image that have an agent version earlier than 18.2.2, the update process might fail. (2200962)
Images that you created on nodes at manifest level earlier than 965 might experience this issue. Sometimes the image has RunOnce registry values that block completion of the agent update process.
Workaround: Perform the agent update again, adding the following command line argument on the Command Line tab of the Agent Update wizard: VDM_SUPPRESS_RUNONCE_CHECK=1
Reports Related Known Issues
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.
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.
Identity Management, True SSO Related Known Issues
Launching a second desktop from the Workspace ONE portal using the Horizon Client can fail with the error 'You are not entitled to that desktop or application'. (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 the Workspace ONE portal when the user logs in. The user launches the first desktop using Horizon Client. That desktop connects. Then the user tries to launch the other desktop from the other assignment, also using the Horizon Client. The launch of that other desktop fails with an error indicating the user is not entitled. However, this issue is seen only for the first attempt on the second desktop. If the user launches the second desktop using the browser, subsequent attempts to launch the second desktop using Horizon Client succeed.
Workaround: If you encounter this situation, try launching the second desktop using the browser.
Workspace ONE does not display the remote applications' display names that you set in the Horizon Cloud Administration Console. (2131583)
Due to a known issue in VMware Identity Manager, when Workspace ONE displays the remote applications that you sync from Horizon Cloud, Workspace ONE does not display the display names that you set for those remote applications in Horizon Cloud. Even though Horizon Cloud sends the display names to VMware Identity Manager, VMware Identity Manager uses the remote applications' launchIDs instead. As a result, Workspace ONE displays the basic names for the remote applications.
After you upgrade your VMware Identity Manager Connector from version 2017.8.1.0 to version 2017.12.1.0, the sync operation might fail. (HW-78477)
Due to a known issue in VMware Identity Manager Connector version 2017.12.1.0, after the connector restart when upgrading the connector, the sync operation in the VMware Identity Manager administration console might fail.
Workaround: Save the virtual app collection again by re-entering the administrator password for the tenant and then sync.
While a node deployment is in progress, the Administration Console's Active Directory page does not display the True SSO Configuration section. (2019445)
During the time a node is being deployed, the True SSO Configuration section is not visible on the Active Directory page. Due to this issue, if a node deployment is not yet completed, the Active Directory page does not display the True SSO Configuration section.
Workaround: Check the state of your nodes on the Capacity page. If one or more nodes have yet to finish onboarding into the system, wait until its progress is completed before attempting to perform True SSO configuration.
User Interface Related Known Issues
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.
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)
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.
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)
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. (1967245)
When your Horizon Cloud environment is integrated with VMware Identity Manager, your end users access their assigned desktops and applications using Workspace ONE. 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 VMware Identity Manager creates launch IDs from Horizon Cloud by using older Horizon Cloud REST APIs.
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.
End User, Horizon Client Related Known Issues
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 10 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 10 minutes, the client's automatic retry gives up. Because an encrypted VM usually takes longer than 10 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)
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.
Node Updates Related Known Issues
While a node is undergoing an update, active end user sessions to that node are disconnected. (2028903, 2022498)
During the ten-minute process of updating a node from an earlier software level to the latest one, end users who have connected sessions to the updating node 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 node's farms and VDI desktop assignments do not have Logoff Disconnected Sessions set to Immediately.
After the download of a new version of the node software is triggered, the Unified Access Gateway status displayed on the node's details page is incorrect. (2036319)
As described in the Administration Guide, when the download of the node software update is triggered, the software is downloaded to your environment in Microsoft Azure. Then after the download is finished, your node's details page shows that an upgrade is available. Due to this known issue, when the download is triggered on the backend, the information about the node's Unified Access Gateway configurations incorrectly changes to display Pending status in the node's details page.
Workaround: None. The Unified Access Gateway operations are unaffected even though the displayed status is incorrect. When you update the node to the new version, the displayed status is corrected in the node's details page.
Localization Related Known Issues
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)
Previous Issues Resolved in this Release
This release resolves the following issues reported in the previous release:
Resolved Images, Farms, Assignments Related Issues
You cannot edit the number of sessions per RDSH server once a farm is created. (1973182, 1932001)
This issue is address in this release. Now you can edit the number of sessions per RDSH server after the farm is created.
Resolved User Interface Related Issues
After you directly type a date and time into the Schedule Update window and click Save, the window remains open and the information is not saved to the system. (2028462)
This issue is resolved in this release. When you manually type a date and time into the Schedule Update window and your typed entry does not match the system's required date and time format, a message appears to tell you to use the required format.
After being logged in to the Administration Console past the set timeout period, as you perform some tasks, error messages might be displayed that do not reflect the current state of the system. (2031672)
This issue is resolved in this release.