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 Release Notes document. 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.

August 2022 - v2207

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

To request enablement of an enabled-by-request feature, file a support request as described in VMware KB article 2006985.

New versions of the following key binaries have debuted in v2207:
A new pod manifest version for Horizon Cloud on Microsoft Azure deployments and the Horizon Agents Installer (HAI).
New items related to service-deployed pods in Microsoft Azure
  • Administrators can now configure the cipher suites that will be accepted when clients connect to the Unified Access Gateway machines. For pods with gateway configurations that existed in your tenant prior to this release, use the pod details page to review the cipher suites configured on those gateway configurations. You can use the Edit Pod workflow to change the configured cipher suites.
  • During upgrade maintenance, Unified Access Gateway session counts will be used to optimize timing to reduce end-user session interruptions.
  • The transient pod deployment engine, also known as the jump box, is removed from the architecture for new Horizon Cloud on Microsoft Azure deployments and updates. Capacity for a transient jump box would be required only if you open a support request and VMware Support determines the way to service that request is to deploy a support-related jump box VM, under their supervision.
  • To avoid effects from Microsoft Azure Cloud's upcoming retirement of some VM models, better accommodate importing GPU-capable VMs, and standardize the VM models for single-pod and multi-pod image imports, starting in the v2207 release, the VM models that the service's automated Import VM from Marketplace wizard uses by default have changed.

    The wizard now uses the following models as indicated for both single-pod images and multi-pod images. We recommend that you check the VM family quotas in your pods' Azure subscriptions to ensure that you have available quota for the images you plan to create using the wizard.

    Import VM from Marketplace wizard creates:
    • Non-GPU, non-Windows 11, a Standard_DS2_v2 VM
    • Non-GPU using Windows 11, a Standard_D4s_v3 VM
    • GPU-capable, a Standard_NV12s_v3 VM
New items related to Horizon Image Management Service
  • Horizon customers with deployments in VMware Cloud on AWS using all-in-SDDC architecture can now replicate images using the Multi-Pod Images capabilities. Along with using the standard IMS features for markers and pools with the deployment in VMware Cloud on AWS, with this support, you can use IMS to replicate images from Horizon on-premises deployments to the Horizon in VMware Cloud on AWS all-in-SDDC deployments and from the VMware Cloud on AWS deployments to the on-premises deployments.

    For the requirements for the support of IMS with all-in-SDDC Horizon deployments in VMware Cloud on AWS, see the relevant information in Horizon Image Management Service System Requirements.

Additional items of note
  • Because every subscription includes a Workspace ONE Access tenant which can be added using the Horizon Universal Console, the capability of new Workspace ONE Access tenant creation from within the Horizon Universal Console. This change supports VMware business operations.

May 2022 - v2204

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

To request enablement of an enabled-by-request feature, file a support request as described in VMware KB article 2006985.

New versions of the following key binaries have debuted in v2204:
A new pod manifest version for Horizon Cloud on Microsoft Azure deployments, new versions of Horizon Cloud Connector, Universal Broker Plugin Installer, and the Horizon Agents Installer (HAI).
New items related to service-deployed pods in Microsoft Azure
  • Windows 11 is now a supported guest operating system for use with Horizon Cloud on Microsoft Azure deployments. Refer to this page for known considerations, limitations, and issues when using Windows 11 with the service, Support for Windows 11 Guest Operating System - Considerations, Known Limitations, and Known Issues. Use of this feature requires the pod running this release's manifest or later.

    Some additional points related to this Windows 11 support:

    • If you use the manual import method to import a VM with Windows 11, you must ensure that the Horizon Agents Installer (HAI) version 22.1 or later is used to install the agents. The Windows 11 support requires the minimum agent version provided by HAI v22.1.
    • Use of the console's App Volumes Capture workflow using a Windows 11 golden image is not currently supported. As a work around, you can capture the packages using a Windows 10 golden image and then assign those packages to your end users to use with their assigned Windows 11 single-session or multi-session desktop.
  • New Horizon Cloud on Microsoft Azure pods will always be deployed with high availability enabled.
  • Multi-pod images will now leverage configured proxy settings for any image operation originating from the customer network to the internet (such as when using the automated Import Virtual Machine from Marketplace wizard).
  • Support for manually importing VMs from the Azure Marketplace that use AMD GPU and graphics drivers and using those imported VMs for golden images. This support requires use of the Azure VM model Standard_NV4as_v4 and the pod running this release's manifest or later.
  • In existing dedicated assignments, you can now adjust a provisioned VM's workload CPU, memory, or disk based on individual user needs. When you do this, the pool type will change to Mixed type. Use of this feature is supported for pods running this release's manifest or later.
  • The recommended Horizon Agents Installer version is now displayed on the console's Capacity screen. Regular notifications will be generated as reminders to keep agents up to date. This feature is provided for pods running this release's manifest or later.
  • The service created Microsoft Azure VMs that enter a Stopped state due to a guest OS shutdown will now automatically be transitioned to a Deallocated state to prevent continued billing. Use of this feature is supported for pods running this release's manifest or later.
  • Enhancements in the area of App Volumes for Horizon Cloud pods. To use this feature, the pod must be running this release's manifest level or later.
    • Applications can now be delivered on-demand when a user clicks to launch the application from the desktop and Start menu, and the resulting behavior is the same as if the application was already installed natively on the Windows machine. The setting is available for newly created packages.
  • To mitigate the effects from a Microsoft Azure issue, starting in the v2204 service release, the VM models that the service's automated Import VM from Marketplace wizard uses by default for non-GPU Windows 10 OS images have changed. For details of the reported issue, refer to VMware KB88343.

    The wizard also uses specific models for the Windows 11 support that is newly added in this v2204 release.

    The wizard now uses the following models. We recommend that you check the VM family quotas in your pods' Azure subscriptions to ensure that you have available quota for the images you plan to create using the wizard.

    Single-pod image - Import VM from Marketplace wizard creates:
    • Non-GPU Windows 10 OS or a Windows 10 Enterprise multi-session OS single-pod image, a Standard_DS2_v2 VM
    • Non-GPU Windows Server OS VM single-pod image, a Standard_D2_v3 VM
    • GPU-capable Windows-10 OS or a Windows 10 Enterprise multi-session OS or a Windows Server OS single-pod image, a Standard_NV6 VM
    • Non-GPU Windows 11 OS or a Windows 11 Enterprise multi-session OS single-pod image, a Standard_D4s_v3 VM
    • GPU-capable Windows 11 OS or a Windows 11 Enterprise multi-session OS single-pod image, a Standard_NC6s_v3 VM
    • Non-GPU Windows 7 OS single-pod image, a Standard_DS2_v2 VM (GPU unsupported on Windows 7)
    Multi-pod image - Import VM from Marketplace wizard creates:
    • Non-GPU Windows-10 OS or a Windows 10 Enterprise multi-session OS or a Windows Server OS multi-pod image, a Standard_DS2_v2 VM
    • GPU-capable Windows-10 OS or a Windows 10 Enterprise multi-session OS or a Windows Server OS multi-pod image, a Standard_NV6 VM
    • Non-GPU Windows 11 OS or a Windows 11 OS Enterprise multi-session OS multi-pod image, a Standard_D4s_v3 VM
    • GPU-capable Windows 11 OS or a Windows 11 Enterprise multi-session OS multi-pod image, Standard_NC6s_v3 VM
    • Non-GPU Windows 7 OS multi-pod image, a Standard_DS2_v2 VM (GPU unsupported on Windows 7)
Additional items of note
  • In the IMS support for Horizon on-premises pods:
    • An option is provided to select the datastores and networks in the target pod's vCenter Server for the image copy.
    • Use of IMS with a multi-clustered vCenter Server is now supported.
    • A Republish option to retry publishing when a publish fails is now provided for this pod type.

March 2022 - v2203

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

To request enablement of an enabled-by-request feature, file a support request as described in VMware KB article 2006985.

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2203 release.
New versions of the following key binaries have debuted in v2203:
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 reliability.
New items related to service-deployed pods in Microsoft Azure
  • A new Edit button on a VDI desktop assignment's Summary tab provides convenience for editing the assignment's details.
  • A farm's Summary tab displays additional useful information, such as the farm's creation date and time, its Azure resource group name, and its farm ID.
  • The pod deployer no longer requires creation of an Azure Key Vault during pod deployment. Please note that the Add Pod wizard will continue to validate that the subscription has the Microsoft.KeyVault resource provider in Registered state, to support use of the farms' and VDI desktop assignments' disk encryption feature. That feature requires creation of a key vault in the pod manager's resource group at the time you select use of that disk encryption feature.
    Important: Existing customers should not delete the key vaults that exist in their Horizon Cloud on Microsoft Azure deployments unless under direction by VMware Support. Manually deleting the key vaults will put the deployments into an unsupported state.
  • RSA SecurID is an option for a two-factor authentication configuration on the pod's gateway configurations. To use this feature with an already deployed gateway configuration, the pod must be running manifest 3139 or later. This feature is targeted for enablement in the Add Pod and Edit Pod wizards by mid-March 2022. The option will be visible in those wizards at that time.
Additional items of note
  • Use of the Horizon Infrastructure Monitoring features with Horizon pods is no longer supported. As a result, all references to using those features with Horizon pods is removed from documentation. (Horizon pods are the ones that run Connection Server.)

February 2022 - v2201

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

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2201 release.
New versions of the following key binaries have debuted in v2201:
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
  • The gateway configurations now support configuring a syslog server to receive the logs from the Unified Access Gateway instances. This feature is supported for pods running manifest 2298 or later.
  • LDAPS can now be selected as the protocol when registering your Active Directory environment with your tenant. This feature is available when your tenant is explicitly enabled for it and all pods are running this release's manifest level. To request enablement, you must file a support request as described in VMware KB article 2006985.
  • During the time that an upgrade is scheduled for a pod, the pod's details page in the console displays a banner which indicates that after the upgrade of the pod and its Unified Access Gateway instances, you might need to update the IP addresses that are configured in your RADIUS server as allowed client connections from the NICs on the Unified Access Gateway instances. When a pod has a gateway configuration, Unified Access Gateway instances are also updated when that pod is updated to a new manifest version. With this feature, during the time period that the upgrade is scheduled, the pod's details page in the console will alert you that when the gateway configuration has configured RADIUS settings, you might have to take additional action to ensure that your RADIUS server configuration is updated to allow client connections from the IP addresses that the gateway NICs will be using post-upgrade.
New items related to the Image Management Service (IMS)
  • You can now select which pods you want the multi-pod images to be copied to. Previously, the images were copied to all pods by default.
New items related to Universal Broker
  • In the help desk tool, the breakdown of logon segments is displayed in the session data for users connecting through Universal Broker .
  • When using Universal Broker and Dynamic Environment Manager together, Dynamic Environment Manager can now distinguish between internal and external users, for the purposes of applying smart policies.
  • For Horizon pods, the VDI multi-cloud assignment workflow now supports pools that are running Windows Server 2019.

November 2021 - v2111

Use the following information when you are an existing customer with cloud-connected pods dating from before October 2021 and you want to understand any effects on your experience from the features that debuted in the service with this month's release.

New versions of the following key binaries have debuted in November 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 service-deployed pods in Microsoft Azure
  • You can now edit the VM Model type for an existing VDI desktop assignment. The pod must be running this release's manifest level.
  • Multi-pod image management now supports multi-session operating systems. You can now create farms from such multi-pod images. The pod must be running manifest 2915.x or later.
  • In tenants enabled with single-pod broker, you can now move an individual VM between VDI desktop assignments that are provisioned by the same Horizon Cloud pod. To have use of this feature, your tenant must be explicitly enabled for it and the pod must be running this release's manifest level. You can request enablement of this feature in your tenant by filing a support request as described in VMware KB article 2006985.
  • In the area of auto-agent updates, you can now remediate incomplete or failed agent updates in cases when the agent is stopped and not running in the VM. The pod must be running this release's manifest level.
  • Enhancements in the area of App Volumes for Horizon Cloud pods. The pod must be running this release's manifest level.
    • App packages will now be automatically detached as the last assigned user of that app logs off a Windows 10 Enterprise multi-session system. Previously, a shutdown of the VM was required to detach the packages.
    • App Volumes now supports VMware Dynamic Environment Manager with Windows 10 Enterprise multi-session operating systems.
    • App Volumes batch files can be used to configure the App Volumes workflow. This feature is covered in the App Volumes Administration Guide in the page titled Batch Scripts for App Volumes workflow.
    • The RunAsUser.exe utility is now included with App Volumes Agent, allowing you to run the executable from the App Volumes advanced configuration batch files. Typically, the code from these batch files executes in the system scope and you can use this utility to run code in the context of the current logged in user. This feature is covered in the App Volumes Administration Guide in the page titled Use RunAsUser for App Volumes Batch Scripts.
    • Improvements in the Print Spooler restart behavior in a Windows 10 Enterprise multi-session operating system.
New items related to Universal Broker
Starting with this release, for greenfield deployments of Horizon Cloud on Microsoft Azure Universal Broker is the enabled broker by default.
Additional items of note for current customers
  • You can now specify email addresses to receive alerts and notifications from your tenant and those addresses are not required to be associated with a tenant administrator role. Prior to this feature, only tenant administrators could receive alerts and notifications by email.
  • When your tenant's Horizon Universal License includes licensing for VMware SDDC components such as VMware vCenter, vSAN, and vSphere, you can retrieve those keys using the Horizon Universal Console. In the console, you can select which versions of the keys you want to retrieve and can view those keys at any time. To use the console to generate the key, you must have the Super Administrator role in the tenant and be a Customer Connect user on the EA that is associated with this tenant.
  • When Workspace ONE redirection is enabled at the tenant level, end users are appropriately redirected to Workspace ONE Hub even when the end-user clients are directly connecting to the FQDN on the pod's Unified Access Gateway configuration. Previously, such end-user connections were directly obtaining a desktop.

October 2021 - v2110

Use the following information when you are an existing customer with cloud-connected pods dating from before October 2021 and you want to understand any effects on your experience from the features that debuted in the service with this month's release.

Note: The generally available versions of Horizon Agents Installer, Horizon Cloud Connector, and Universal Broker Plugin Installer are unchanged in this v2110 release.

Also, the pod manifest version for Horizon Cloud pods deployed into Microsoft Azure by the service's deployment wizard remains as 3000.x. If critical fixes are required, patches such as 3000.1, 3000.2, and so on will be made available.

New items related to service-deployed pods in Microsoft Azure
  • Horizon Universal Console now supports narrow scope permissions to desktop assignments and farms for the built-in predefined roles. To have use of this feature, your tenant must be explicitly enabled for it and all of the Horizon Cloud pods must be running manifest 2915.x or later. You can request enablement of this feature in your tenant by filing a support request as described in VMware KB article 2006985.
  • In the New Pod workflow and Edit Pod workflow, administrators can now choose 8443 as the TCP port for Blast Extreme on the pod's Unified Access Gateway instances. Prior to this feature, the Blast Extreme TCP port was set to 443 by default and there was no wizard option to change it. Port 8443 is strongly preferred because it has better performance for the client-to-gateway traffic and uses less resources on the Unified Access Gateway instances. The chances of CPU congestion in the instances causing traffic delays from the client are reduced when you use 8443 for the Blast Extreme TCP port. You can use the Edit Pod workflow to change the Blast Extreme TCP port for existing gateway configurations.
  • 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 Universal Broker
  • Universal Broker and multi-cloud assignments now support brokering of desktops and apps for pods using Google Cloud VMware Engine (GCVE).
  • Universal Broker now supports the ability to restrict the launching of virtual desktops, published desktops, and published applications to specific clients and versions and provide warning messages to clients.
  • Universal Broker now supports the ability for end users to connect to their VDI desktops and published desktops using the RDP protocol from within those Horizon Clients that provide the RDP protocol as an option for use with Windows-based desktops.
New items related to Horizon Cloud Connector and cloud-connected Horizon pods
  • With the debut of the Horizon Cloud Connector version 2.0 native binary for Google Cloud Platform, all of the cloud-plane services that the cloud plane provides for Horizon pods deployed with a federated architecture are now supported for such pods. Such pods use Google Cloud Platform for the management components and Google Cloud VMware Engine (GCVE) for the desktop components. Use Horizon Cloud Connector version 2.0 to obtain this full support. Please note that currently the Image Management Service (IMS) is only supported with on-premises Horizon pods and not for cloud-based Horizon pod deployments.
  • With the debut of the Horizon Cloud Connector version 2.0 native binary for Amazon EC2, all of the cloud-plane services that the cloud plane provides for Horizon pods deployed with a federated architecture are now supported for such pods. Such pods use Amazon EC2 for the management components and VMware Cloud on AWS for the desktop components. Use Horizon Cloud Connector version 2.0 to obtain this full support. Please note that currently the Image Management Service (IMS) is only supported with on-premises Horizon pods and not for cloud-based Horizon pod deployments.
  • Horizon Cloud Connector version 2.0 OVA is now supported for use with Horizon on VMware Cloud on Dell EMC. These pods are all-in-SDDC deployments. Except for the Cloud Monitoring Service (CMS) and Image Management Service (IMS), those cloud-plane services that the cloud plane provides for Horizon pods in all-in-SDDC deployments are supported for this deployment type.

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. This feature is supported for pods running manifest 3000.x or later.
  • 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 When Your Organization Prefers to Use a Custom Role for the Horizon Cloud App Registration. 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 VMware Horizon 8 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.

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 new features.

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

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
Some cloud-plane-based features debuted in the weeks prior to the v2103 release.
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 VMware Horizon 8 version 2103 (8.2). 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 new features.

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

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 deactivated 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
Some cloud-plane-based features debuted in the weeks prior to the v2101 release.
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 new features.

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

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 new features.

Specifically about existing cloud-connected Horizon pods
Debut of Horizon Cloud Connector 1.7.
Specifically about existing pods in Microsoft Azure
For the following new features 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 new features.

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 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 new features.

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 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 new features.

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