VMware updates the Horizon Cloud software components periodically to include new features, improvements for service supportability and resiliency, user-experience improvements, 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. When VMware updates the software components used in a deployed pod, the manifest number for the pod's software goes to a higher number. If there are improvements considered important for pod serviceability and support operations, VMware will make a new manifest available even if the timing within a quarter of the previous manifest version. The normal update process takes place without incurring any system downtime.

Important: If the pod is already integrated with the cloud-hosted Workspace ONE Access using the old Linux connector version 2017.12.1.0, you should update the connector to the latest supported version before updating the pod. To choose 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. Then update your existing connector by following the steps for your chosen connector version found in the VMware Workspace ONE Access documentation. After you have completed updating your connector, then update 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 VMs 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 which pods have updates available for them. Navigate to Settings > Capacity. The pod's Status column will show the pending icon instead of the green dot, the pod's version number is a hyperlink instead of static text, and when your cursor hovers over that version number, a tooltip indicates an update is available. The following screenshot illustrates the behavior described in the preceding sentence.


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

You can see the update details for a specific pod on its details page. When an update is available, an on-screen message describing the update appears.


Horizon Cloud on Microsoft Azure: Screenshot of the pod details page showing update messages.

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 in Horizon Cloud, Update Agent Software for Dedicated VDI Desktop Assignments, and Update Agent Software for Images Used by Floating VDI Desktop Assignments.

This Horizon Cloud pod update process is patterned after a software industry technique known as blue-green deployment.


Conceptual illustration of the blue-green update process.

The existing to-be-updated pod components are considered the blue components. Shortly after VMware releases a new pod manifest, the VMware Horizon Service 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 update workflow to switch to the new pod software as soon as you see the notification banner that the update 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 administrative console. Because the remedy is in your control and cannot be resolved by VMware, if you get a notification of update 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 Horizon Cloud Pod in Microsoft Azure and Remedies for Typical Pod Update 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. On the pod's details page, a banner appears that says an update is available to move to and you can schedule the day and time for making the switch.
    Horizon Cloud on Microsoft Azure: Screenshot of the pod details page showing update messages.

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

Post-Update

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 the September 2019 quarterly service release, the pod architecture is updated to support the ability to have high availability (HA). Even when the high availability feature is not enabled, the new HA-capable architecture includes a Microsoft Azure load balancer in front of the pod's manager VM. After you update your pod to manifest 1600, if your pod was configured for direct connections, you should remap your DNS settings to point to pod manager's Azure load balancer IP address that will be newly displayed in the updated 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 for an HA-enabled pod if the active-broker manager VM goes down. For this use case, you map an FQDN to the IP address in the Pod Manager Load Balancer IP field that is displayed on the pod's details page, as described in Configure SSL Certificates Directly on the Pod Manager VMs, Such as When Integrating the Workspace ONE Access Connector Appliance with the Horizon Cloud Pod in Microsoft Azure, So that Connector Can Trust Connections to the Pod Manager VMs. Prior to pod manifest 1600, that IP was the one assigned to the pod's manager VM's NIC on the tenant subnet. Starting with pod manifest 1600 or later, the pod's IP address to map is the private IP address of the Microsoft Azure load balancer used for the pod's manager VMs. For existing pods that are updated 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 IP address displayed for the Pod Manager Load Balancer IP label in the updated pod's details page.