VMware View 4.x - Warning: Using Legacy Messaging Mode to Support Old Agents

During the aforementioned customer engagement in my last post, I noticed a reoccurring error in the event logs of both of the new View Connection Servers (labeled VCS01 and VCS02) in regards to ‘Legacy Messaging Mode’. Searching both the KB and the Communities sites with Google gave me exactly 1 relevant hit (http://communities.vmware.com/message/1356802) that was over 6 months old (at the time) and had no tips on how to ‘drill down’ on which machines were ‘acting up’. In the interest in saving others with Event Log Paranoia, here is how I got to the bottom of this. 

The error, which posts to each VCS event log every 30 minutes as a ‘Warn’, is pretty self-explanatory: at least one of the desktop sources has the old agent installed and it is not going to perform 100% until you install the newest agent: 

The error text:

Message:	Using legacy messaging mode to support old agents. Performance may be affected.
Type:	Warn
Time:	DATE TIME
Module:	DesktopTracker
Thread:	DesktopControlSessions

The real problem was, once the Agent had been pushed out to all the machines, what if this warning kept occurring? The error text does not give the name of the desktop source nor does the VMware View 4 Desktop Manager (VDM) GUI give you the version number of the currently installed / running agent on any given Desktop. In short, I needed a way to get a list of all of the VDI sources and their installed agent version so that I may recommend remediation as necessary as I was not going to check each VM / Physical by hand.

A Little Backstory

During our migration planning with the customer, they noted that they wanted to be able to fail back to their old VDM environment with zero VM level changes during the failback (if it came to it). This meant hooking all of the VDI sources to the new VDM servers without upgrading the View Agent first. This is not the preferred way, especially since features like PCoIP would not be available to end users until the agents were upgraded. Since this customer was not using linked clones, the agents would be pushed through LANDesk to all VDI sources on a scheduled / controlled basis. In this particular corporate environment, neither myself or the team I was working with had direct control over LANDesk, so it would be difficult for me to check which sources actually got a successful install of the Agent (or even which desktops were on the list to be pushed).

In Pursuit of Virtual Happiness

On VCS01, I fired up ASDI edit against the VMware View ADAM instance to see if the information was stored within, which, of course, it was not. I dug around on a test VDI source to see exactly where the version information was stored. I found both the Version Number and Build number located cleanly in the registry under ‘ProductVersion’ and ‘BuildNumber’ here: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM.

The Solution

Myself and another consultant came up with a neat solution to this problem. Using a VBscript, we were able to pull all of this information together with LDAP queries and WMI calls.

The script does the following:

1. Prompt the end user for a VDM server, which can be either a standard or replica server (security servers need not apply as they do not have an ADAM instance). 
   1. Note: This also works against the load-balanced address FQDN.
2. Query the View ADAM instance to obtain all of the NetBIOS names of all of the desktop sources in the ADAM database. 
   1. Desktops are defined as Class=pae-DesktopApplication and are referred to as CN=(DESKTOPNAME) in OU=Applications within the ADAM instance context DC=vdi,DC=vmware,DC=int.
3. Loop through the list with a WMI query designed to use the StdRegProv provider to hook into the desktop’s registry and pull out the Agent Version and Build numbers.
   1. Note 1: It will pull out the Version / Build from the Connection Servers AND the Security servers if they are part of the same domain. If your security servers are in a workgroup (like ours) or in a DMZ AD domain (and there is no trust), you will get a DENY on the output.
   2. Note 2: VMware View 3.x does not report its build number in the registry.
4. For each entry, export the result set to a TSV file, which can be opened and edited with Excel. 

This script gave me exactly the report I needed to resolve this error. While this deployment only consisted of about ~120 desktops, you could imagine the efficiency gain in higher density deployments. 

Our script is attached, Happy Hunting, hope it helps. Change extension to .txt for best results.

Download Script Here