Use the information in this page in tandem with the What's New in the Release Notes. Along with the items listed in the Release Notes document, this page is for those of you who already have existing cloud-connected pods onboarded in your environment prior to the most recent service refresh date, or you have previous experience with Horizon Cloud features and workflows. This page describes the significance the newly debuted features and changes might mean to you and those pods. Only significant changes to the features and workflows are described. Minor changes, such as new layouts and color schemes in the administrative console that do not significantly change the workflows are not detailed here.

The most recent service refresh date is listed in the service's Release Notes document. To see the up-to-date information about the various workflows that you perform in your Horizon Cloud tenant environment, read the documentation topics found in the individual guides linked from the Horizon Cloud Service documentation page.

The following sections go back to September 2019. Similar information for earlier releases is not available for publication.

Important: For information that is key to understanding terms used in this page, see the information in the Release Notes document prior to reading the information in this page. The Release Notes document has key relevant pieces of information such as the latest pod manifest number for pods that deploy into Microsoft Azure. Also keep in mind that the key facts described in the following section are true in every Horizon Cloud release.

Six Key Facts About Every Horizon Cloud Release

  • All new cloud-plane-based features that are agnostic to pod manifest version level or Horizon Cloud Connector version level or Horizon pod version level or control-plane regional differences are automatically provided to both existing customers and new customers. As an example, a new feature that does not depend on new APIs for API calls between the cloud plane to the pods or related to Horizon Cloud Connector will be visible and exploitable by existing customers unless otherwise noted below or noted in the product guides. To illustrate this point, one such feature is the console's enhanced feedback submission. Even though this feedback icon debuted in July 9, 2020, the icon and flow is available for use by tenant environments that existed prior to July 9, 2020 even prior to updating the pods or Horizon Cloud Connector to their latest versions.
  • The VMware Horizon Cloud Service team debuts new cloud-plane-based features that are agnostic to pod manifest version level or Horizon Cloud Connector version level or Horizon pod version level on an ongoing, regular basis and on any week of the calendar year. The Release Notes document contains the debut dates of those features.
  • Starting on the day on which that manifest version debuts in the cloud control plane, the pod deployer for deploying pods into Microsoft Azure always deploys pods at the latest pod manifest version.
  • Already deployed pods that exist in your service tenant prior to the day on which a new pod manifest version debuts in the cloud plane will continue running at their existing manifest version until they are updated to the manifest that is brand new for the release. The following facts apply:
    • New service features which have zero dependencies on APIs that require the latest manifest level will be available for those existing pods.
    • New service features which rely on APIs at the latest manifest level will not be available for those existing pods until those pods are updated.
    • Some new service features might depend on the cloud plane region in which your tenant account is located. Such features are noted in the documentation where applicable. Your control-plane region is stated in the Welcome to Horizon Service email sent when the customer account is created, as described in Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.
  • The console's Import VM from Marketplace wizard uses the Horizon Agents Installer (HAI) that is built into the pod manifest. As a result, pods deployed at the latest manifest version will have the latest HAI built into them, and running the Import VM wizard and selecting a pod at the latest level will install the agents from that latest HAI. For pods that are not yet updated to the latest manifest level, the Import VM from Marketplace wizard uses the HAI version that was available when their respective pod manifests were built.
  • Horizon 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 pods. Each pod is onboarded using the Horizon Cloud Connector. These use cases debuted starting with Horizon 7 version 7.6 environments and Horizon Cloud Connector 1.0 for activating subscription licenses on Horizon pods. Then with each new version of Horizon Connection Server combined with a new version of Horizon Cloud Connector, additional cloud-hosted services become available for cloud-connected Horizon pods running the latest Horizon Connection Server version paired with the latest Horizon Cloud Connector version. New deployments of Horizon Cloud Connector are supported using versions N, N-1, N-2, where N is the latest Horizon Cloud Connector version. We recommend that deployments that are still using versions of Horizon Cloud Connector that are earlier than the N-2 version to update to the latest versions to take advantage of new features as well as security and resiliency fixes. For the latest N version of Horizon Cloud Connector, see the upper portion of the Horizon Cloud Service Release Notes page. Also see the VMware Product Interoperability Matrices tool for the matrix of currently supported versions of Horizon pod software with Horizon Cloud Connector. If you are running a combination of Horizon Connection Server and Horizon Cloud Connector version that no longer matches that matrix, please update as soon as possible to a supported combination.

September 2021 - v2109

Use the following information when you are an existing customer with cloud-connected pods dating from before September 2021 and you want to understand any effects on your experience from the features described in the Release Notes for September 2021.

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2109 release.
New versions of the following key binaries have debuted in v2109:
A new pod manifest version for Horizon Cloud pods deployed into Microsoft Azure by the service's deployment wizard. In addition to providing the backend support that the pod managers need for some of the debuted features, this manifest includes platform code improvements for performance and reliability.
New items related to service-deployed pods in Microsoft Azure
  • Horizon Agent Update now supports targeting agent updates on individual desktops within the assignment. Use of this feature requires a pod running at this release's manifest level.
  • The pod deployment wizard and Edit Pod wizard no longer mandate having a Unified Access Gateway configuration unless the tenant's Universal Broker settings include two-factor authentication. Previously, the wizards enforced the use of at least one Unified Access Gateway on the pod.
  • When your tenant is configured to use single-pod brokering, connecting to a VDI desktop or a farm-based session desktop using the RDP protocol is now supported.
  • The system requirements for transitioning a single-pod broker tenant to Universal Broker no longer include having at least one internal or external Unified Access Gateway configuration on every pod except in the following scenarios.
    • When you select to enable two-factor authentication in the Universal Broker settings in the Schedule Transition wizard. When two-factor authentication is enabled for Universal Broker in the wizard, the transition requires that every pod in the tenant's fleet have an external Unified Access Gateway.
    • When your tenant's fleet also includes Horizon pods, and the console's Broker page indicates their Universal Broker configuration already has two-factor authentication enabled. In this case also, the transition requires that every pod in the tenant's fleet have an external Unified Access Gateway.
  • For App Volumes applications with multi-session desktops, application package detachment now happens after the last user assigned that package logs off. Shutting down the underlying farm VM is no longer required to detach volumes. Previously, the application package detachment happened at shut down of the VM.
New items related to Horizon Cloud Connector and cloud-connected Horizon pods
  • Now available are documented steps for using the high availability features of vSphere with the Horizon Cloud Connector appliance. Because this ability relies on the vSphere high availability features, it is specific to the on-premises and all-in-SDDC pod architectures. In those deployment architectures, the Horizon Cloud Connector is deployed into a vSphere infrastructure.
  • Use of Cloud Monitoring Service and pods deployed with the federated deployment design that uses Google Cloud Platform and Google Cloud VMware Engine (GCVE) is now supported.
  • The Change to Managed State wizard no longer mandates having a Unified Access Gateway configuration unless the tenant's Universal Broker settings include two-factor authentication. Previously, the wizard enforced the use of at least one Unified Access Gateway on the pod.
New items related to Universal Broker
For end users on your internal network, Universal Broker now supports direct connections between their clients and the virtual desktops and remote applications (VDI and RDSH). With this support, an internal Unified Access Gateway is no longer required to launch virtual desktops and remote applications for these internal connections. To support these internal clients' launch of the virtual desktops and remote applications, you must use the console's Broker > Network Ranges to specify ranges of egress NAT addresses so that Universal Broker can recognize the specified ranges as originating from your internal network.

August 2021 - v2108

Use the following information when you are an existing customer with cloud-connected pods dating from before August 2021 and you want to understand any effects on your experience from the features described in the Release Notes for August 2021.

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2108 release.
New versions of the following key binaries have debuted in v2108:
A new pod manifest version for Horizon Cloud pods deployed into Microsoft Azure by the service's deployment wizard. This manifest includes platform code improvements for performance and reliability.
New items related to service-deployed pods in Microsoft Azure
  • Two additional operations are added to the set of operations that the service principal needs to use in your subscription, as described in Operations Required by Horizon Cloud in Your Microsoft Azure Subscriptions. These two additional operations are to support an upcoming feature by which the service can reduce the time it takes for a new pod deployment and for a pod upgrade by using pre-configured images in the Microsoft Azure Marketplace. When your service principal uses a custom role, that role will need the ability to perform these two additional operations.
  • When creating an App Volumes assignment, the wizard no longer includes the OS Family selection menu. Because packages captured in a VM running one type of Windows operating system are compatible with desktops running the types of Windows operating systems that are available for use with these pods, specifying the OS family for the assignment was determined to be no longer necessary. Therefore, the menu could be removed from the wizard with no loss of functionality. This change is also applicable to App Volumes assignments that were created prior to this release. When editing such existing App Volumes assignments, even though the OS Family was selected when that assignment was created, because the OS Family choice is no longer required by the system, that field is no longer present in the edit window.
  • Additional improvements in the area of reporting on failures that occur during the automated agent update process. When the pod is running this release's new manifest version, the downloadable CSV report now also provides the names of the desktop VMs in which the agent update process was successful or skipped, in addition to the ones in which the process has failed.
Additional items of note for current customers
Integration with a new VMware product, VMware Workspace ONE Assist for Horizon, enables Horizon Cloud administrators to launch remote support sessions directly from the Help Desk Tool from the Horizon Universal Console. Administrators can assist end users with tasks and issues involving their virtual desktop sessions. VMware Workspace ONE Assist for Horizon is part of the VMware Workspace ONE UEM product line. For all of the requirements for using the features provided by this new product, see the topic 'Requirements for Horizon Cloud with Workspace ONE Assist' in the Workspace ONE for Horizon and Horizon Cloud document.
The Contact Information section of the Horizon Universal Console General Settings page is removed because its fields are not needed for any workflows or use cases or system operations.

July 2021 - v2106

Use the following information when you are an existing customer with cloud-connected pods dating from before July 2021 and you want to understand any effects on your experience from the features described in the Release Notes for July 2021.

New versions of the following key binaries have debuted in July 2021: a new pod manifest version for service-deployed pods, new versions of Horizon Cloud Connector, Universal Broker Plugin Installer, and the Horizon Agents Installer (HAI).

New items related to Horizon Cloud Connector and its use with Horizon pods
  • Version 2.0 of Horizon Cloud Connector adds service-level fault tolerance for the license service. Documentation about this feature can be found within the Administration Guide topic Horizon Cloud Connector 2.0 - Clusters and Service-Level Fault Tolerance and its subtopics.
  • Version 2.0 of Horizon Cloud Connector adds support for monitoring the appliance using SNMP. Administrators can use this standards-based monitoring function to proactively monitor and receive alerts on critical connector-related services, such as licensing, upgrade, and connector life cycle, even if they are not logged into the Horizon Universal Console. Documentation about this feature can be found within the Administration Guide topic Horizon Cloud Connector 2.0 - Monitor the Appliance Using SNMP.
New items related to service-deployed pods in Microsoft Azure
  • Multi-pod image management provides an easy method for publishing and replicating single-session VDI images to two or more Horizon Cloud pods in Microsoft Azure and updating multiple VDI multi-cloud assignments with a single operation. The features of multi-pod image management with Horizon Cloud pods is only available to tenants configured to use VDI multi-cloud assignments and for Horizon Cloud pods running manifest 2632.x and later. Documentation about this feature can be found in Managing Horizon Images From the Cloud and its subtopics.
  • Enhancements in the area of automated agent updates:
    • Prior to a scheduled agent update, the system will now by default automatically restart the VMs selected for the agent update process. This automated restart helps to ensure the VM and the software and services running inside its operating system are in a known state prior to running the agent update operations.
    • Improved reporting on failures that occur during the automated agent update process. You can download a CSV report of the names of the desktop VMs in which the agent update process has failed, even when the agent update process is still underway on the assignment. The CSV report is available for download when the pod is running this release's new manifest version.

May 2021 - v2105

Use the following information when you are an existing customer with cloud-connected pods dating from before May 2021 and you want to understand any effects on your experience from the May 2021 release.

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2105 release.
New versions of the following key binaries have debuted in v2105:
A new pod manifest version for Horizon Cloud pods deployed into Microsoft Azure by the service's deployment wizard. This manifest includes platform code improvements for performance and reliability.
New items related to Horizon Cloud Connector and its use with Horizon pods
Universal Broker now supports published desktops and applications for Horizon pods on VMware SDDC. For this support, the pods must be running Horizon software version 2103 or later and Universal Broker Plugin Installer version 21.03 or later.

April 2021 - v2104

Use the following information when you are an existing customer with cloud-connected pods dating from before April 2021 and you want to understand any effects on your experience from the April 2021 release.

Note: The versions of Horizon Cloud Connector and Universal Broker Plugin Installer are unchanged in this v2104 release. You can continue to use the March 2021 versions of those components with your tenant environment.
New versions of the following key binaries have debuted in v2104:
  • A new pod manifest version for Horizon Cloud pods deployed into Microsoft Azure by the service's deployment wizard. This manifest includes platform code improvements for performance and reliability.
  • A new HAI version includes a fix to resolve an intermittent issue related to the Cloud Monitoring Service receiving data from the Horizon agent. (problem report 2742816).
New items related to service-deployed pods in Microsoft Azure
Support for moving App Volumes packages between App Volumes applications using the console. Includes support for moving newly imported packages to the appropriate applications.
Additional items of note for current customers
Some features debut as Limited Availability features. Such features are enabled on a tenant-by-tenant basis, usually on a per-request basis. Search the Release Notes for such Limited Availability features are mentioned.

March 2021 - v2103

Use the following information when you are an existing customer with cloud-connected pods dating from before March 2021 and you want to understand any effects on your experience from the features described in the Release Notes for March 2021.

New versions of the following key binaries have debuted in March 2021: a new pod manifest version for service-deployed pods, new versions of Horizon Cloud Connector, Universal Broker Plugin Installer, and the Horizon Agents Installer (HAI).

This list is based on the items listed in the Release Notes What's New March 2021 section of the Release Notes page.

New items related to Horizon Cloud Connector and its use with Horizon pods
Version 1.10 of Horizon Cloud Connector brings fixes and security updates.
New items related to service-deployed pods in Microsoft Azure
  • Universal Broker and multi-cloud assignments are now available for existing deployments of Horizon Cloud pods on Microsoft Azure.
  • The console's pod detail's page has a new Maintenance feature, used to specify a preferred maintenance window. Use this feature to inform the system of your preferred time and weekday for pod maintenance activity to occur.
  • Starting with this release's pod manifest, App Volumes for Horizon Cloud pods on Microsoft Azure now supports Microsoft Windows 10 Enterprise multi-session, allowing multiple users to each login into individual sessions with their own app assignments. Previously, the use of Microsoft Windows 10 Enterprise multi-session with App Volumes for Horizon Cloud pods was in Tech Preview. Please note that the feature is supported for deployments starting with this release's pod manifest and starting with this release's App Volumes Agent version.
  • For customers using App Volumes for Horizon Cloud pods on Microsoft Azure and also using the App Volumes Command-Line Capture Program to capture applications for importing into your Horizon Cloud applications inventory, a new option has debuted with App Volumes 4 version 2103 that provides for packaging applications without needing the App Volumes Manager console, as well as other tools to work with VHD formats and with the MSIX app attach formatted packages. For information, see the App Volumes 4 version 2103 Release Notes What's New.
Additional items of note for current customers
As documented in the Release Notes document, some cloud-plane-based features debuted in the weeks prior to the v2103 release. See that document for those details.
Universal Broker and multi-cloud assignments now support Horizon pods on Azure VMware Solutions (AVS), enabling unified brokering of multi-cloud assignments across hybrid and multi-cloud deployments, supporting both Horizon pods and Horizon Cloud pods on Microsoft Azure.
The console is enhanced to reflect its new name: Horizon Universal Console.
Some features have debuted as Limited Availability features. Such features are enabled on a tenant-by-tenant basis, usually on a per-request basis.
In the administration console for Horizon pods (known as Horizon Console), the Cloud Brokered option is not operational for this release. This option appears in the RDS desktop pool settings and application pool settings for cloud-managed Horizon pods running version 2103 (8.2) of the Horizon software. Enabling the Cloud Brokered option has no effect for this Horizon Cloud release.

January 2021 - v2101

Use the following information when you are an existing customer with cloud-connected pods dating from before January 2021 and you want to understand any effects on your experience from the features described in the Release Notes What's New January 2021.

New versions of the following key binaries have debuted in January 2021: a new pod manifest version for service-deployed pods, new versions of Horizon Cloud Connector, Universal Broker Plugin Installer, and the Horizon Agents Installer (HAI).

This list is based on the items listed in the What's New January 2021 section of the Release Notes page.

New items related to Horizon Cloud Connector and its use with Horizon pods
  • With Horizon Cloud Connector 1.9, the automatic update feature now has a simpler configuration for the network details. You only need to provide an unassigned static IP address for the new appliance for upgrade.
  • Horizon Cloud Connector 1.9 enables more secure access methods when troubleshooting the Horizon Cloud Connector appliance. SSH access for the appliance's root user is disabled and a new custom user (ccadmin) is now available for SSH access, including support for using an SSH public key instead of password credentials.
New items related to service-deployed pods in Microsoft Azure
The pods now support the ability to rollback the dedicated desktop to a previous usable state in the event that the agent update fails and a configurable failure threshold that provides a fail-fast mechanism that will stop the update process and skip any remaining desktops. For this feature to be used with a previously existing pod, that pod must first be updated to manifest 2632.0 or later.
Additional items of note for current customers
As documented in the Release Notes document, some cloud-plane-based features debuted in the weeks prior to the v2101 release. See that document for those details.
For pod manifests of 2474.0 and later, the set of Active Directory permissions for the domain join accounts is reduced to provide more flexibility for tenants. However, because the system will use the same domain join accounts in domain-join-related operations with all of the pods in your tenant's fleet, when your fleet includes pods of manifests prior to 2474.0, you must ensure your domain join accounts have the prior set of permissions that those pods require. When all of your Horizon pods in Microsoft Azure are updated to pod manifest 2474.0 or later, then you can adopt the newer reduced set of Active Directory permissions for your domain join accounts. See Service Accounts That Horizon Cloud Requires for Its Operations and the updated section about the permissions for the domain join account.
The console is enhanced to reflect some new terminology. Previously, the console displayed labels such as On-Premises and VMware Cloud on AWS when referring to cloud-connected Horizon pods that are installed in on-premises vSphere installations or in a VMware Cloud on AWS SDDC (software-defined data center). These are the pods that are based on the Horizon Connection Server software. With the availability of Horizon pod deployments on additional cloud-hosted VMware SDDCs such as Horizon pod on Azure VMware Solution (AVS) and Horizon pod on Google Cloud VMware Engine (GCVE), the console is enhanced to use the label VMware SDDC when referring to those members of your tenant's pod fleet.
Support is added for running the Enrollment Server on Microsoft Windows Server 2019. The Enrollment Server is used for the True SSO feature. Installation of Enrollment Server on Microsoft Windows Server 2008 is no longer supported.

October 2020 - v2010

Use the following information when you are an existing customer with cloud-connected pods dating from before October 2020 and you want to understand any effects on your experience from the features described in the Release Notes What's New October 2020.

New versions of the following key binaries have debuted in October 2020: a new pod manifest version for service-deployed pods, new versions of Horizon Cloud Connector, Universal Broker Plugin Installer, and the Horizon Agents Installer (HAI).

This list is based on the items listed in the What's New October 2020 section of the Release Notes page.

New items related to Horizon Cloud Connector and its use with Horizon pods
  • Horizon Cloud Connector version 1.8 is released in both OVA and VHD forms.
  • Horizon Cloud Connector 1.8 provides the ability to select a deployment profile to either enable with subscription license support only or with Horizon Cloud features. This selection is made during the deployment of the appliance.
  • Horizon Cloud Connector now supports Horizon pods that are deployed on Azure VMware Solution (AVS). Currently, this support is for use of your subscription license with those deployments. The full set of cloud-hosted services are not yet provided for these deployment types.
New items related to service-deployed pods in Microsoft Azure
Horizon Cloud on Microsoft Azure pods now support the ability to specify custom Azure Resource Tags during a pod deployment or gateway deployment. The pod deployer applies the specified tags on the resource groups that the pod deployer creates. For a description of the resource groups that the pod deployer creates, see Resource Groups Created for a Pod Deployed in Microsoft Azure. This new feature is not dependent on the pod manifest version.

July 2020 - v3.1

Use the following information when you have cloud-connected pods dating from before July 2020 and you want to understand any effects on your experience from the features described in the Release Notes What's New July 2020.

Specifically about existing cloud-connected Horizon pods
Debut of Horizon Cloud Connector 1.7. For its features, see the July 2020 What's New in the Release Notes.
Specifically about existing pods in Microsoft Azure
For the following new features described in the Release Notes document's July 2020 What's New section to be used with a previously existing pod, that pod must first be updated to manifest 2298.0 or later to take advantage of the feature.
  • Multiple tenant subnets for use with farms and VDI desktop assignments. This feature is not yet available for use with multi-cloud desktop assignments, which are used in a tenant configured with Universal Broker.
  • Use of the advanced session load balancing for RDSH farms.
  • Ability to cancel both desktop and farm expansion tasks that are in a queued or running state, with support for automatic desktop assignment and farm resizing. This feature is not yet available for use with multi-cloud desktop assignments, which are used in a tenant configured with Universal Broker.
  • To provide for improved end-user login times, the time it takes for a VM to get to agent-ready state for pod-provisioned desktop VMs that are powered off and need to power on to fulfill an end user's request for a desktop has been reduced.
  • Use of the App Volumes features — the pods must be updated to this release's manifest version and your customer account must be located in one of the following Horizon Cloud control-plane regions: USA-2 (PROD1_NORTHCENTRALUS2_CP1), Europe-2 (PROD1_NORTHEUROPE_CP1), or Australia-2 (PROD1_AUSTRALIAEAST_CP1). Your control-plane region is stated in your Welcome to Horizon Cloud Service email.

When deploying a gateway configuration on your pod, in addition to the Standard_A4_v2 VM size in previous releases, you now have the option to use the Standard_F8s_v2 VM size, which provides more vCPUs for each Unified Access Gateway instance. For existing pods, this new feature is available when editing the pod to add a new gateway configuration to that pod.

Additional items of note for current customers
An enhancement to submitting product feedback is now available in the console's header bar, for all existing customers.

Pods that can have the high availability (HA) feature are now supported for Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas). If you have an existing pod in Microsoft Azure Government for which you want this feature, please contact your VMware representative for that enablement.

March 2020 - v3

Use the following information when you have cloud-connected pods dating from before March 2020 and you want to understand any effects on your experience from the features described in the Release Notes What's New March 2020.

Specifically about existing cloud-connected Horizon pods
The debut of Horizon Cloud Connector 1.6.x provides a command-line diagnostic tool for you to check the health of required Horizon pod's system components and services that are needed for Horizon 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 about existing pods in Microsoft Azure
For the following new features described in the Release Notes document's March 2020 What's New section to be used with a previously existing pod, that pod must first be updated to manifest 1976.0 or later to take advantage of the feature, unless otherwise noted.
  • 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 updated to at least manifest version 1763 or later (the December 2019 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 console's workflow to delete that existing external gateway. When the deletion is completed successfully, then you can run the Edit Pod workflow to add back an 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. This option does not change what is displayed for those end-user connections that are going through Workspace ONE Access. 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 manifest 1976.0 or later for it to be able to take advantage of this feature.
  • Pod manifest 1976.0 or later 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 console, even though this feature's options are displayed in the farm's Servers tab in the 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
Enhancements in the reports available in the 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.

December 2019 - v2.2

Use the following information when you have cloud-connected pods dating from before December 2019 and you want to understand any effects on your experience from the features described in the Release Notes What's New December 2019.

Specifically about existing cloud-connected Horizon pods
Starting in this release:
  • Some things that are within your control can prevent a successful automatic update of the Cloud Connector, such as insufficient datastore space in your vCenter environment to accommodate the update. Starting in this release, if automated update is enabled for your Horizon Cloud tenant account, such items are identified in the console, so that you can address and clear those items.
  • Automated updates of Horizon Cloud Connector are now supported for Horizon pods deployed in VMware Cloud on AWS.
  • Enhancements to the Horizon Cloud Connector onboarding success screen include a health status display for the connector's components and an option for activating and deactivating SSH on the Horizon Cloud Connector appliance.
Specifically about existing pods in Microsoft Azure
For the following new features described in the Release Notes document's December 2019 What's New section to be used with a previously existing pod, that pod must first be updated to manifest 1763.0 or later to take advantage of the feature, unless otherwise noted.
  • To support advanced deployment configurations, the pod deployer provides options for:
    • Using a separate VNet for the external gateway configuration's Unified Access Gateway instances, separate from the pod's VNet and the core pod elements. The VNets must be peered.
    • Using a separate subscription for the external Unified Access Gateway configuration, separate from the subscription used for the core pod elements. Because a VNet is scoped to a subscription, the separate subscription deployment scenario is also the separate VNet scenario. The VNets must be peered.
    • For an existing pod to take advantage of this feature, the pod must first be updated to manifest 1763.0 or later. Then you need to meet all the documented requirements for using a separate VNet for the external gateway configuration, including peering that VNet with the pod's VNet. Then you must delete the pod's existing external Unified Access Gateway configuration, using the console's workflow to delete that existing external gateway. When the deletion is completed successfully, then you can run the Edit Pod workflow to add back an external gateway using the new options.
  • Starting with this release's manifest, you can use SSD disk types for VDI desktop assignments and RDSH farms.
  • Starting with this release's manifest, you can customize the OS disk sizes for VDI desktop assignments and RDSH farms. At earlier pod manifests, their OS disk sizes were set to be the same as the published base image, which was 127 GB by default and could not be changed.
  • New in this release, in the Import VM from Marketplace wizard, you will see a toggle that provides the ability to omit joining the resulting VM to an Active Directory domain. Previously, this workflow joined the VM to the domain by default and you could not change that behavior. This new toggle is available for existing pods prior to this release's manifest version.
  • With the redesign of the Capacity page in this release, the Type view is removed. With the removal of the Capacity page's Type view, there are two changes to note about items that were previously accessed from that view: the action to view the pod's current usage of its subscription's Microsoft Azure limits has moved to the pod's details page and the Remove Subscription action that had been present in that view is removed completely.
Additional items of note for current customers
  • Enhancements in the reports available in the Administration Console's Reports page. The data in these reports is provided by the Cloud Monitoring Service.
  • Enhancements to the Horizon Cloud Administration Console's Capacity page. Instead of having to drill-down into a pod's details page to modify the pod's configurable details or to delete a pod from your tenant environment, you can now initiate the edit pod and remove pod workflows from the Capacity page itself. As a result of this redesign, the workflows for modifying location information that were previously done using the Capacity page's Location view are now options within the Edit Pod workflows. As an example, to specify a new location name, use the Edit action on a pod and you can specify a new location name as an option of that Edit Pod workflow. Please note that the previous Location view's workflow for removing saved Microsoft Azure subscription information when all of that subscription's associated pods have been deleted is no longer available.
  • The product name formerly known as VMware Identity Manager is now named VMware Workspace ONE™ Access.
  • The Horizon Agents Installer no longer installs a dormant DaaS agent. In the previous release, the HAI installed the DaaS agent's MSI into the guest operating system, but it was dormant and not used. In this release, the MSI is not installed at all.

September 2019 - v2.1

Use the following information when you have cloud-connected pods dating from before September 2019 and you want to understand any effects on your experience from the features described in the Release Notes What's New September 2019.

Specifically about existing cloud-connected Horizon pods
Starting in this release:
  • Automatic update is now supported on Cloud Connector versions 1.3 and 1.4. It is recommended that customers on earlier versions of Cloud Connector update to the latest to take advantage of this feature.
  • Cloud Monitoring Services (CMS) with session usage details is provided as part of Horizon Cloud Service.
Specifically about existing pods in Microsoft Azure
For the following new features described in the Release Notes document's September 2019 What's New section to be used with a previously existing pod, that pod must first be updated to manifest 1600.0 or later to take advantage of the feature, unless otherwise noted.
  • The pod architecture has changed in this release. All pods at the September 2019 release's manifest version have a pod Microsoft Azure load balancer and a Microsoft Azure Database for PostgreSQL server instance (Gen 5 Memory optimized tier). This means that before you update your existing pods to this release's manifest version, you must ensure that your existing networking configuration meets the DNS, ports, and protocols required to accommodate the pod Microsoft Azure load balancer and Microsoft Azure Database for PostgreSQL server instance. If you have firewalls or network security groups that block specific ports and protocols, compare your current networking configuration to the information in the following topics and update your networking configuration accordingly.
  • Enhanced alerting for pod update errors that require customer actions to resolve them is provided in this release. Some things that are completely within your control can prevent a successful pod update, such as not having enough cores in the pod's associated subscription to create the jump box VM which orchestrates the pod update. Starting in this release, such items are identified in the console, so that you can address and clear those items.
  • Starting in this release, you can revise the following gateway-related settings on an already deployed pod: add two-factor authentication settings to a gateway that does not have them, edit a gateway's two-factor authentication settings, change the gateway's session brokering timeout setting. In previous releases, you had to configure RADIUS two-factor authentication when the pod was first deployed, and could not change those settings afterwards. Also new in this release, you can delete gateways from an already deployed pod and you can deploy a new pod to have an external gateway without a public IP address on its Azure load balancer and instead have a private IP address on that load balancer.
  • Support for defining Microsoft Azure resource tags when creating a new dedicated or floating VDI desktop assignment or a new farm for Horizon Cloud on Microsoft Azure.
  • High availability is now available. To support high availability for pods in Microsoft Azure, the pod architecture is updated to use the Microsoft Azure Database for PostgreSQL service (Updated Gen 5 Memory optimized tier), a Microsoft Azure load balancer, and an availability set. For a pod that is newly deployed in this release, you have the option to enable high availability for that pod at deployment time, or enable high availability later on. For pods that existed prior to this release, before you can enable those pods for high availability, you must first update them to the 1600.0 manifest or later and also update the agents in the pods' images, farms, and VDI desktop assignments to this release level. When the pod update and agent updates are completed, then you can enable high availability on the pod by editing the pod from its pod details page in the Administration Console. This new feature brings additional requirements for enabling the Microsoft.SQL service endpoint on the pod's management subnet when your pod uses subnets that you create yourself, and for allowing outbound access for port 5432.

    At the September 2019 time, this High Availability (HA) feature for pods in Microsoft Azure is only supported for pods deployed in the Microsoft Azure Commercial regions (standard global regions). The pod HA feature is not currently supported for pods deployed in Microsoft Azure China, Microsoft Azure Germany, and Microsoft Azure Government (US Gov Virginia, US Gov Arizona, US Gov Texas). The VMware team is working on adding support for the HA feature for pods in those above listed cloud environments. If you have an existing pod in Microsoft Azure in China, Microsoft Azure Germany, or Microsoft Azure Government that you want to update to this release's manifest version without HA, please contact your VMware representative for assistance.

    Before updating an existing pod in one of the standard Microsoft Azure global regions to manifest 1600 or later, because the new pod architecture uses the Microsoft Azure Database for PostgreSQL service, you must ensure the following items are in place:

  • To increase resiliency of the Horizon Agent pairing process, this release brings further evolution of moving the DaaS agent functions into the Horizon Agent. The DaaS agent has now been incorporated into the Horizon Agent. Even though both the automated Import Image workflow and manual installation of the Horizon Agents Installer install the DaaS agent's MSI into the guest operating system as they did in previous releases, starting in this release, the DaaS agent is dormant and not used. However, the service for the DaaS agent still appears in the Windows Services list. Do not start that service or unexpected results can occur.
  • Moving the DaaS agent functions into the Horizon View agent has changed both the automated Image Import from the Azure Marketplace workflow and the steps for manually building a base VM. Previously, the base VM that resulted from the automated workflow was paired to the cloud at the end of the workflow, while for a manually created VM, you had to manually bootstrap and pair the VM. Now, for base VMs in a pod that is new or updated to this release version, the resulting base VM is listed on the Imported VMs page with an agent status of Not Paired. To pair the VM, you can either:
    • Run the Reset Agent Pairing action on the VM listed on the Imported VMs page, if you want to pair it with the cloud before customizing it.
    • Run the New Image action on the VM directly, if the VM has all of the customizations you want and you are ready to publish it. In this case, the New Image workflow will first run the pairing process to make the agent active, and then you can complete the rest of the fields and click Publish to publish the image.
  • With the move of the DaaS agent functions into the Horizon View agent, the Reset Agent Pairing workflow is now available to use on imported VMs, farm server VMs, and desktop VMs in dedicated VDI desktop assignments. In a farm's details or dedicated VDI desktop assignment's details, if you see an error state in the Agent Status column for a farm server VM or desktop VM, you can use the Reset Agent Pairing action in the console to repair the pairing state of that VM. (The action is not available for floating VDI desktop assignments.) In the Imported VMs page, you can use the Reset Agent Pairing action to initially pair a VM that has not yet been paired, or repair the pairing state for a VM that was previously paired.
  • The disk encryption feature now uses the newer AzureDiskEncryption v2.2. This newer version enables support of disk encryption for VMs with in-guest proxy set up to talk to the Internet. To take advantage of this new support, update your VMs' agents to version 19.3.0 or later.
  • Updated guidance to use VM models that have a minimum of two (2) CPUs for your farms and VDI desktop assignments. VMware scale testing has shown that for production environments, using a minimum of 2 CPUs avoids unexpected end-user connection issues. Even though the system does not prevent you from choosing a VM model with a single CPU, you should use such VM models for tests or proof-of-concepts only.
  • Usability enhancements to the VM Types and Sizes page.
Additional items of note for current customers
  • Improved usability and optimization of the Unified Dashboard interactive map view, including more accurate reflection of the pod location and zoom functionality.
  • Enhancements in the reports available in the Administration Console's Reports page. The data in these reports is provided by the Cloud Monitoring Service.
  • For cloud-connected Horizon 7 pods, additional details are displayed in a pod's details page. The pod and Cloud Connector must be at the latest version to see this feature.
  • The product name formerly known as VMware User Environment Manager™ is now named VMware Dynamic Environment Manager™.