VMware updates the Horizon Cloud software components periodically to include new features and bug fixes. VMware typically updates the in-cloud management environment on a weekly basis and updates the software components used in a deployed pod on a roughly quarterly basis. The normal update process takes place without incurring any system downtime.

Important: If the pod is already integrated with the cloud-hosted VMware Identity Managerâ„¢ and you are using the Linux connector version 2017.12.1.0, a best practice is to update the connector to the latest supported version before updating the pod. For the connector version that is supported by this Horizon Cloud release, see the VMware Product Interoperability Matrixes at https://www.vmware.com/resources/compatibility/sim/interop_matrix.php. Follow the steps in Preparing to Upgrade VMware Identity Manager Connector. Then upgrade your pod.

Updating your deployed pod means appropriately moving your pod's current infrastructure components to a higher software manifest level. The infrastructure components are primarily the pod manager VM and any Unified Access Gateway VMs that are configured for the pod. For example, a pod update can include updates for the pod management software or for the Unified Access Gateway software or for both.

You can use the Capacity page to see at a glance which pods have updates available for them. Navigate to Settings > Capacity. A visual indicator appears next to those pods that have updates available for them. When your cursor hovers over the indicator, a pop-up displays additional details.

The following screenshot illustrates the placement of the available update indicator when it appears in the Location view of the Capacity page.

Horizon Cloud on Microsoft Azure: Screenshot of the Capacity page showing a pod with an update available and a green arrow pointing to the visual indicator.

You can see the update details for a specific pod by selecting Settings > Capacity and clicking the pod to open its summary page. When an update is available, an on-screen message describing the update appears at the Version No entry. The displayed version number corresponds to the version of the pod's software manifest.

Horizon Cloud on Microsoft Azure: Screenshot of the pod details page showing update messages and green arrows pointing to them.

Note: After you have updated a pod from prior releases to later ones, you can then update the agent-related software in the pod's already published images, farms, and VDI desktop assignments to the same agent version level that comes with the updated pod version. The agent-related update is done in a process separate from updating the pod itself. For the steps on how to update the agent-related software after the pod is updated, see Update Agent Software for RDSH Images, Update Agent Software for Dedicated VDI Desktop Assignments, and Update Agent Software for Images Used by Floating VDI Desktop Assignments.

This Horizon Cloud pod upgrade process is patterned after a software industry technique known as blue-green deployment. The existing to-be-upgrade pod components are considered the blue components. Shortly after VMware releases a new pod manifest, the VMware Operations team runs some pre-checks and then designates your Horizon Cloud customer account as available to use the new manifest version. At the point in time when that new manifest version is designated in your customer account, the service builds a green set of components for the pod in your Microsoft Azure subscription. This green set is a parallel environments of the existing blue components.

Note: Not all of the pod update process adheres exactly to a software industry blue-green deployment pattern. As an example, in the pod update process, when the newer instances are created alongside the existing ones, the newer ones are powered up and remain running until the pod has completed migrating to the new instances. Also, after the deployer validates the pod is successfully running on the newer components, the older VMs are deleted instead of remaining in an idle state.

End-to-End Process

Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:

  1. The service creates a jump box resource group in the pod's subscription and deploys a jump box VM. This jump box VM orchestrates the creation of the green set of components.
  2. The green set of components is created alongside the blue components, in the same resource groups. In the pod management resource group, the green set of pod manager VMs and their associated artifacts like NICs and disks are created. In the pod's gateway-related resource groups, the green set of Unified Access Gateway VMs are their associated artifacts are created. These green VMs are started and kept running until this entire end-to-end sequence is completed. The jump box VM and its resource group are deleted when the green components are successfully built and running.
    Important: Starting from this sequence point until the last step of the sequence, there are a duplicate number of VMs running: both the blue VMs and the green VMs. Therefore, it is prudent for you to schedule the upgrade to switch to the new pod software as soon as you see the notification banner that the upgrade is available to move to, and schedule it for a day and time earlier rather than later.

    This process does not cause any downtime, and the parallel VMs do not affect the pod's operations. Unless the system encounters errors that only you can resolve in your Microsoft Azure environment, no actions are required from you at this point. If the service encounters any issues in deploying the green components, it detects whether the remedy for those issues is within your control. If the service determines that you can remedy the issues, a notification appears in the Administration Console. Because the remedy is in your control and cannot be resolved by VMware, if you get a notification of upgrade errors, you must complete the actions to resolve them and then contact VMware support to continue the pod update process. For details about the types of issues that you can remedy, see Cores Needed for Upgrading a Pod in Microsoft Azure and Remedies for Typical Pod Upgrade Errors. If the service determines an issue can be resolved by the VMware Operations team, it alerts the VMware Operations team, which will resolve the issue without any actions from you.

  3. A notification banner appears in the Administration Console, letting you know an upgrade is available to move to and you can schedule the day and time for making the switch. The following screenshot is an example of what appears on the Capacity page.
    Capacity page indicating that an updated version is available for a pod

  4. Next, you must schedule the update to move the pod from using its current blue VMs and components to the green ones. You schedule this update from the pod's summary page, by selecting Update > Schedule. You set a day and time for the service to switch the pod to using the new green components. The service deploys a jump box VM to configure the scheduler in the pod, and then deletes the jump box VM until the scheduled day and time.
    Important: Before the update runs, remove any management locks in Microsoft Azure that you might have set on any of the pod's virtual machines (VMs). Any VMs with names that have a portion like vmw-hcs- podID, where podID is the pod's ID value, belong to the pod. Microsoft Azure provides an ability to use the Microsoft Azure portal to lock resources to prevent changes to them. Such management locks can be applied on an entire resource group or on individual resources. If you or your organization has applied management locks on the pod's VMs, those locks must be removed before the update runs. Otherwise, the update process will not successfully complete. You can locate the pod's ID value in the pod's details page from the Capacity page.

    You determine the convenient time for the update to take place. Typically, the update itself, or the migration from the existing version to the new version, takes about ten minutes. As a best practice, schedule the update at a time when the environment is least busy. After the update is scheduled, the Administration Console displays the scheduled time in a top banner. You can reschedule the time for the update at any time prior to the scheduled time, if required by your organization's needs.

    Important: When you schedule the update in the pod's details page, you are prompted for a date and time. This time is local to your browser time zone.

    Horizon Cloud on Microsoft Azure: Screenshot of the Capacity page with the top banner showing the time of the scheduled pod update.

  5. At your selected day and time, the service again deploys a jump box VM to orchestrate the switch for the pod to use the green VMs and components. The green components become the current blue components. The process takes from five to fifteen minutes to complete, with the longer times for pods that have both an external and internal Unified Access Gateway configuration. The process migrates the data and configuration from your existing to-be-updated pod's infrastructure to the new.

    During the migration, the following limitations apply:

    • You cannot perform administrative tasks on the pod that is undergoing the update.
    • End users who do not have connected sessions to their virtual desktops or remote applications served by the updating pod and who attempt to connect cannot do so.
    • End users who have connected sessions served by the updating pod will have those active sessions disconnected. After the migration is complete, those users can reconnect. No data loss will occur, unless you have used the Immediately option for the timeout handling in the farms and VDI desktop assignments.
    Caution: Users with connected sessions to desktops or remote applications served by farms and VDI desktop assignments with Logoff Disconnected Sessions set to Immediately will be immediately disconnected and those disconnected sessions are also logged off immediately. In those conditions, any in-progress user work is lost.

    To avoid loss of in-progress end user data for this scenario, before the migration process starts, adjust the Logoff Disconnected Sessions setting in the farms and VDI desktop assignments to a time value that will give those users time to save their work. Then after the update is finished, you can change the setting back to what it was before.

  6. After everything is migrated to the new environment and the pod is successfully running on the new instances, the system deletes the blue VMs from the pod's resource groups, and the jump box resource group and its contents. Some artifacts, such as the NICs for the previous Unified Access Gateway instances, remain to preserve configuration values that are needed for the next pod update.

After the End-to-End Process is Complete

When the migration to the green components finishes, you can perform administrative tasks on the pod. To see the software version that a pod is currently running, select Settings > Capacity and click the pod to open its summary page. The page displays the current software version running. Click the software version number to see associated release information.


Important: If your configured Radius server is deployed in same VNet, then after the migration to the new infrastructure elements, you must update the settings on your Radius server to accept the new private IP addresses for the new internal Unified Access Gateway VMs. This is a one-time requirement for the first update on the pod, and does not have to be repeated for that pod's future updates.
Important: Starting with this release, the pod architecture is updated to support high availability. After you upgrade your pod to manifest 1600 and subsequently enable high availability, if your pod was configured for direct connections, you should remap your DNS settings to point to the new tenant appliance IP address that will be displayed in the upgraded pod's details page. Until you update the DNS mapping, even though those direct user connections will still work, they won't have the high availability fail over if the active-broker manager VM goes down. For this use case, you map an FQDN to the IP address in the Tenant appliance IP address field that is displayed on the pod's details page, as described in Upload SSL Certificates to a Horizon Cloud Pod for Direct Connections. Prior to this release, that IP was the one assigned to the pod's manager VM's NIC on the tenant subnet. Starting in this release, for pods at manifest 1600 or later, the pod's tenant appliance IP address is the private IP address of the pod's load balancer. For existing pods that are upgraded to this release's manifest version, if you had configured a DNS name to point to the tenant appliance IP address for a pod of manifest 1493.1 or earlier, you should remap your DNS settings to point to the new tenant appliance IP address that will be displayed in the upgraded pod's details page.