Horizon Cloud Pod Updates — Steps For Continued Agents Compatibility and Support

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.

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 Cloud Services Guide, you are responsible for ensuring adequate protection of the content that you deploy or access with the Cloud Service, including but not limited to patching of the virtual machines that comprise your images and assignments (pools). 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.

• 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:

  • Run Update Agent on the images that have blue dots. For specific steps to follow to update an image, see Update Agents for RDSH Farms, Update Agents for Dedicated VDI Desktop Images, and Update Agents for Floating VDI Desktop Images.
  • Edit the farms and VDI desktop assignments to use those updated images instead of their current image. This step refreshes all of the farm, floating VDI desktop VMs, and unassigned dedicated VDI desktop VMs to use the images with the new agent version.
  • Run Update Agent on the dedicated VDI desktop assignments to update the assigned dedicated VDI desktop VMs to the new agent version. See Update Agents for Assigned Dedicated VDI Desktops. 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 2204 version is updated to the service's 2404 version. The agent version that is the default most recent version for that pod will be incompatible (gray box) when that pod is updated to the service's 2404 version.

  

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 Horizon Cloud 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 First-Gen Horizon Cloud Release Notes and do a page find for that manifest version to locate the 'Update' section in which that manifest debuted.
3. In that same section, locate the version number that is shown after the product name Horizon Cloud on Microsoft Azure — such as 2201.
4. Then go to the Product Interoperability Matrixes and select to compare Horizon Cloud on Microsoft Azure with Horizon Agents Installer.
   • Horizon Cloud 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 3821.x, which according to the Release Notes, that manifest debuted in Horizon Cloud on Microsoft Azure 2210. The matrix illustrates that pod will interoperate with the agent version it debuted with (22.3) and also prior agent versions 22.2, 22.1.0, 21.3, and 21.2. From the section Release Notes - October 25, 2022, one can see that the HAI version 22.3 debuted at the same time as that Horizon Cloud on Microsoft Azure 2210 release. For this example, the matrix is indicating that the oldest agent that a 3821.x pod can operate with is the 21.2 agent. The highest agent is the 22.3 agent. Before you update a pod running 3821.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 at the time of this writing.