**The solution is in this post. **
The important stuff:
VMware View version 5.3.0 build-1427931
vCenter 5.5 U1 (Build 1588022)
Registry Key Sub-folder in common with all VDI Desktops: HKLM\SOFTWARE\VMware, Inc.\Guest Customization\
Registry Key: CustomizationInProgess
Registry Key Value: 0
– VDI Desktops show Agent Unreachable in View Administrator.
– Desktops are not reachable via the View Client or browser Blast- The registry key sub-folder detailed above is missing from the hive
– The VDI desktops go “Unreachable” at random times
– A netstat-a check on the desktop may show an active TCP connection on port 4001 to a View Connection Server. This threw troubleshooting off a bit as this is a normal state for an online View Agent
– All DNS names were verified from the Connection Server and desktop
Nobody knows the answer to this yet. We have a ticket open with VMware and they are looking into it. We do know that if the Guest Customization registry folder is missing, it’s game over for the desktop. Re-installing the View Agent and/or VMware Tools has no effect on the problem.
Changing an existing CustomizationInProgress key from zero to 1 will also put the View Agent into an unreachable state. This makes sense, as View would see the desktop as still being in a Customizing status, like it was just being built. What doesn’t make sense, is the status in View Administrator. If the key in question has a data value of 1, the View Agent becomes ‘Unreachable’ not ‘Customizing’.
1. Sysprep. One of our admins stumbled upon the registry key fix after reporting to VMware that the VDI desktops were stuck in a ‘Customizing’ state after sysprep scripts were run. VMware top-spinned the problem back over to us, blaming Microsoft and the scripts. The admin found the Customization key, logically summarized that was the indicator for View’s status listing of the desktop, and changed it from 1 to zero. Immediately after the change, the desktops moved forward in the process and became ‘Available’.
2. Who or what is deleting the registry key? We have no idea yet on that. Logically, it is the View Agent, with system account privileges, because the guest customization is over. Desktops in a linked clone pool do not have the Guest Customization folder in its registry hive and all the desktop agents are online.
At this time, that registry sub-folder is the lynchpin for the VDI desktops availability.