This article describes the importance of ensuring the agents installed in the pod's images, farms, and VDI desktops stay compatible with your pod's manifest version and describes the remedies you should take to prevent agent-related compatibility issues.


Screenshot that illustrates a blue dot indicator appearing next to an image that needs the Update Agent workflow.

Before a pod update starts, you should update the agents until all of the blue dot indicators in the console have disappeared. Then after the pod update, if you find that any blue dot indicators have returned in the console, you must update those agents again.

Tip: The goal is to get rid of all of the blue dot indicators displayed in the console — before a pod update and also after a pod update.

Your Responsibility

As described in the Horizon Service Description PDF, you are responsible for on-going management and patching of your images and assignment VMs with the latest updates. If you do not ensure that the agents in pod's images, farms, and desktop assignments are updated to the latest agent version that is compatible with the pod version, the pod will be in an unsupported configuration.

Therefore, before a pod update starts, you must ensure the agents are updated to the latest agent versions. Also after the pod update is completed, you must ensure that no blue dot indicators have returned in the console. If you see the blue dot indicators have returned in the console's display, you must again update the agents for the indicated items.

Clear All Blue Dots Before the Pod Update's Scheduled Maintenance — And Afterwards

In the console, examine your sets of image VMs, the farms, and the VDI desktop assignments. Are there any blue dot indicators? The console will display a blue dot indicator next to images and dedicated VDI desktop assignments in which the agent is not up-to-date. The goal is to clear away all blue dot indicators before the pod gets updated to a new manifest version.

The following screenshot illustrates the type of blue dot to look for.


Screenshot that illustrates a blue dot indicator appearing next to an image that needs the Update Agent workflow.
Before the Pod Update Starts, Run Update Agent Procedures to Clear Away All Blue Dots
Perform the Update Agent workflows until you reach zero blue dots. In the console, you can examine all of the lists of VMs in the farms' details pages and the VDI desktop assignments' details pages to confirm they are using the highest compatible agent version. Follow all of the instructions described in each of these topics:

After you've completed those procedures, the farm VMs, the desktop VMs in floating VDI desktop assignments, and the unassigned desktop VMs in the dedicated VDI desktop assignments should all be updated and running the highest compatible agent version. In the console, you can examine all of the lists of VMs in the farms' details pages and the VDI desktop assignments' details pages to confirm.

After the Pod Update Completes, Check for Any Blue Dots. Then Run Update Agent Procedures to Clear Away All Blue Dots
Why could the blue dot indicators return in the console after a pod update if you cleared them prior to the pod update? Because when a new pod manifest debuts, a new agent version also debuts. That combination of pod manifest and agent version make for the supported pod-agent configuration.

However, the pod update process that takes an existing pod to that new pod manifest level does not touch the agents already installed in that pod's existing image VMs, farm VMs, and VDI desktop VMs. Those agents will still be at their previous installed versions — which might or might not be compatible with that pod manifest. If your farm and desktop VMs were created versions back in the past such that updating the pod moves the pod ahead to a version beyond the pod-agent version compatibility matrix, the pod will be in an unsupported configuration.

Here is an example. The following screenshot shows an example of when a pod that was deployed during the service's 2.2 version is updated to the service's 2101 version. The agent version 19.4 that is the default most recent version for that pod will be incompatible (gray box) when that pod is updated to the service's 2101 version.


Screenshot that illustrates the compatibility matrix for Horizon Cloud on Microsoft Azure version 2.2 and HAI

How to Tell Which is the Latest Agent Version Available for a Specific Pod Manifest

For each pod, the pod manager does a pairing with the agent that is installed in an image VM, farm VM, and VDI desktop VM, and an imported VM (when that imported VM has had the agent pairing action performed on it). This pairing underlies the secure communication that is required between the pod manager and those VMs. A new version of the agent is released at the same time as a new version (manifest) of the pod-manager software, and both of those versions are compatible with each other. At the same time, each new version of the pod-manager software is intended to be backwards compatible with a few of the prior agent versions. That means that the newer pod-manager software can continue to communicate with and interoperate with older agents, back to a certain point. When the delta between the newer pod-manager software and the older agents gets too wide, the communication and interoperability between the pod manager and those agents stops.

To determine the interoperability of a specific agent version with a specific pod manifest for one of your pods, you need to relate pieces of information from multiple spots — the pod manifest version, the version of the product named VMware Horizon Cloud Service on Microsoft Azure in which that pod manifest version debuted, and the version of the Horizon Agents Installer (HAI). The agent software is installed into the pod's imported VMs, image VMs, farm VMs, and VDI desktop VMs by the HAI software.

  1. First, use the Capacity page or the pod's details page to obtain the pod's manifest version.
  2. Then open the Horizon Cloud Release Notes and do a page find for that manifest version to locate the What's New date on which that manifest debuted.
  3. In that same What's New location, locate the version number that is shown after the product name VMware Horizon Cloud Service on Microsoft Azure — such as 2201.
  4. Then go to the VMware Product Interoperability Matrices page at https://interopmatrix.vmware.com/#/Interoperability and select to compare Horizon Cloud Service on Microsoft Azure with Horizon Agents Installer.
    • Horizon Cloud Service on Microsoft Azure in Compare section.
    • Horizon Agents Installer in With section.

If your combination of pod manifest and agent version on the matrix lands outside of a green dot, then unexpected issues with the VMs in the pod that are running those agent versions are highly likely to occur.

Example
Imagine a pod that is running manifest 1763.x, which according to the Release Notes, the first 1763.0 manifest debuted in VMware Horizon Cloud Service on Microsoft Azure 2.2. The matrix illustrates that pod will interoperate with the agent version it debuted with (19.4) and also prior agent versions 19.3.1, 19.3, and 19.2. From the Release Notes What's New December 13, 2019, one can see that the HAI version 19.4 debuted at the same time as that VMware Horizon Cloud Service on Microsoft Azure 2.2 release. For this example, the oldest agent that a 1763.x pod can operate with is the 19.2 agent. The highest agent is the 19.4 agent. Before you update a pod running 1763.x, the best practice is to ensure the agents in the image VMs, farm VMs, and VDI desktop VMs are updated to the agent version that is the highest one indicated in its column.

The following screenshot is an illustration of the previous paragraph and the compatibility matrix as it was on February 23, 2021.


Screenshot that illustrates the compatibility matrix for Horizon Cloud on Microsoft Azure version 2.2 and HAI