We have a bunch of Windows 10 floating-pools and they work fine. We also have 1 Persistent/manual pool with a single Win10 VM in it (came from same master-image).
Wierd thing is, that this one specific Windows 10 VM always shows up as "available" in View 6.2.0 admin.
The user that owns that VM can log in fine with his View client. But he can log in *only once*.
So he logs in, works. Disconnects, then tries to re-connect but the client barks that there are no desktops available. All the while, the VM displays as "available" in View Admin. In fact, it never ever shows anything else.
Only when the VM is powered down, it will say "Agent unreachable" as it should. But other than that, it always shows as "available", regardless of actual state.
The admin or the user must reboot the VM to be able to login again as from every second attempt on and onwards, results in the "no desktops available" error.
At the same time, The user can take over the still running session with RDP (effectively bypassing View) as often as he wants. The problem lies purely in View.
This VM runs inside the same subnet as the connection-brokers so firewall issues are out of the question. And the brokers do see the VM when it boots and change from "agent unreachable" to "available". So there is communication between the brokers and this VM's agent (all v6.2.0).
Any idea's? This behaviour started a couple of months ago. Before, it worked fine. The VM is highly personalised and cannot be scrapped and rebuild. I re-installed the View Agent and VMtools and did all the obvious troubleshooting stuff. I'm baffled.
Thanks for the hint. I found that the userinit value is indeed wrong. Instead of "
C:\Windows\System32\userinit.exe,"C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe"," it shows "
This of course causes the wssm.exe to not get launched.
I can correct the value but it does not survive reboots. After a reboot, the
"C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe", part gets removed. I must find out who/what messes with that value...