Friday, October 19, 2018

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.


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:



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:



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:


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


The most recent modified log file was:


… 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)

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:



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)

Using the provided command::

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

… located in the directory:

C:\Program Files\VMware\VMware View\Server\tools\bin

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:



Unknown said...

Fantastic! this fixed my issue (after I had spent many hours trying every other solution I could think of).

Unknown said...

Had this exact issue, but the solution was to put the VM in maintenance mode, remove it from the domain and re-add it back. Then remove maint mode.

Anonymous said...

Also if you VM OS is set to FIPS enabled - uninstall the view agent and restart, then install the View agent in FIPS mode.  This fixed the issue for me