Troubleshooting VMware Horizon View 7.5.1 Virtual Desktop in “Agent unreachable” status

I’ve had several colleagues reach out to me in the past to ask about how I normally troubleshoot an Agent unreachable issue when all of the usual checks were verified (e.g. desktop being powered on, an IP address was obtained, etc) so I thought I’d take the opportunity to write this blog post using a recent issue I encountered at one of the environments I work with.

Problem

You’ve noticed that desktops in a Desktop pool has the Status reported as being Agent unreachable:

Clicking on the ellipsis displays the following details:

Status: Agent unreachable

Pairing state:Paired and secured

Configured by: <viewConnectionServerFQDN>

Attempted theft by:

Troubleshooting

Assuming the following obvious items have already been verified:

1. IP address was obtained
2. There is connectivity between the View Connection server and VDI
3. Desktop is powered on
4. All Horizon View Agent services have been started
5. Desktop’s domain secure connection is not broken

… the first step for troubleshooting issues that have limited information provided in the error details is to review the Horizon View Agent logs on the problematic virtual desktop via the following folder:

C:ProgramDataVMwareVDMlogs

What I typically do when in the log folder is to sort the files by Date modified so the most recently modified files are displayed on top.  For this example, the latest debug log that had been modified was:

debug-2018-10-09-154215.txt

… so I opened the file in Notepad and began reviewing the entries:

Parsing through the logs allowed me to identify the following 3 suspicious entries:

2018-10-09T15:42:25.726-03:00 DEBUG (0F6C-09CC) <Thread-4> [BrokerUpdateUtility] Published CHANGEKEY request

2018-10-09T15:42:34.277-03:00 DEBUG (0724-0728) <Main Thread> [wsnm_desktop] WTS_CONSOLE_CONNECT, sessionId=1

2018-10-09T15:42:35.745-03:00 DEBUG (0F6C-09CC) <Thread-4> [BrokerUpdateUtility] Timeout waiting for success response

2018-10-09T15:42:16.553-03:00 WARN (0724-079C) <PluginInitThread> [ws_configmgr] Update rejected, attempt to reconfigure as paired with missing key information

2018-10-09T15:44:23.232-03:00 INFO (0724-0F38) <JavaBridge> [wsnm_jmsbridge] wsnm_jms died, restarting in a minute

After reviewing the agent logs of the virtual desktop, I proceeded to log onto the VMware View Horizon Connection Server to review the server logs located in the folder:

C:ProgramDataVMwareVDMlogs

The most recent modified log file was:

log-2018-10-09.txt

… so I opened the file in Notepad and began reviewing the entries until I found the following:

2018-10-09T00:00:08.386-03:00 WARN (0EC8-0A34) <DesktopControlJMS> [JMSMessageSecurity] Message could not be validated: Signature invalid for identity agent/4f631619-2cf1-4676-a63e-a37ecc4b9e80

2018-10-09T00:00:08.386-03:00 WARN (0EC8-0A34) <DesktopControlJMS> [JMSMessageSecurity] Identity validation failed: UNKNOWN

2018-10-09T00:00:08.386-03:00 WARN (0EC8-0A34) <DesktopControlJMS> [DesktopTracker] CHANGEKEY message from agent/4f631619-2cf1-4676-a63e-a37ecc4b9e80 is discarded as it cannot be validated

The entry references a GUID of a desktop and not its name so to determine which desktop this GUID belongs to, I launched adsiedit.msc on the View Connection server:

Then used these instructions to open the local VMware Horizon View ADAM database:

Connecting to the View ADAM Database (2012377)
https://kb.vmware.com/s/article/2012377

Name: View ADAM Database

Distinguished Name: dc=vdi,dc=vmware,dc=int

Server: localhost:389

Once connected to the ADAM database, navigate to the Servers OU then locate the unique GUID in the right hand pane:

Open the properties of the object and navigate down to the attribute named pae-DisplayName to locate the name:

Solution

Quickly searching for the identified log entries above brought me to the following KB:

After reinstalling or upgrading the View agent, the View Administrator console reports the message: Agent Unreachable (2038679)
https://kb.vmware.com/s/article/2038679

Using the provided command::

vdmadmin -A -d desktop-pool-name -m name-of-machine-in-pool -resetkey

… located in the directory:

C:Program FilesVMwareVMware ViewServertoolsbin

Resolved the issue.

The following are the screenshots of what the output for the command would look like:

Note that a restart is not required for the status of the VDIs to return to normal: