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.
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 at a glance which pods have updates available for them. Navigate to. 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.
You can see the update details for a specific pod by selecting Version No entry. The displayed version number corresponds to the version of the pod's software manifest.and clicking the pod to open its summary page. When an update is available, an on-screen message describing the update appears at the
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 Horizon 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.
Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:
- 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.
- 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.
- 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.
- 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 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-
podIDis 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.
. 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.
- 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:
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.
- 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.
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.
- 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, selectand 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.