Hello.
We are having some trouble with our VMware View installation, desktops seem to become unavailable after doing a recompose for a pool inside Vmware View administrator.
ESXi on the hosts, 5.1.0, 1065491.
VMware Horizon View 5.3.0 build-1427931.
The solution has been running fine for some time, 7-9 months.
Desktop config: WIn 7 Enterprise x64 SP1, vmxnet3, no cd/floppy, connected to network and working fine, standard virtual switch, working fine.
All connections through PCoIP, direct to connection server.
A week a go we updated our Win7 Enterprise x64 template as usual, making a new snapshot, making this snapshot as default for a desktop pool in View, and doing a recompose for all the desktop VMs.
Recompose completed without errors.
When connecting to the pool, user is authenticated, and View administrator says in the log that user was granted pool DT01.
However the View client remains black, ie nothing is showing in the client, and after 3 minutes is shows a timeout error.
When trying to connect again, it shows: "The display protocol for this desktop is currently not available. Please contact system administrator."
I have searched a lot, and tried alot of solutions, regarding this well known "black screen when connecting through PCoIP".
I have tried:
* Reverted back to original snapshot before error, still same behaviour after recompose.
* Checking the scratch disk, 1,5GB free of total 4GB, increased also to 5 GB (added 1 GB). Same problem.
* Installed a MS patch regards to vmxnet3 nic driver giving PCI errors and detecting as "new" device when cloning/recomposing, after patch, still same error.
* After recompose, in vSphere, i log in to a client with local administrator, open "cmd" and can ping DNS, DHCP, DC and connection servers. nslookup gives all ok. Network seems fine. DNS records on DNS servers seem to point to correct name <-> IP. (and PTR)
* After recompose, and after a users tries a connection, a specific desktop is mentioned in the log. If I try to connect to this desktop through vSphere and console, the desktop seem to be freezed. I cannot type anything or enter the desktop.I then reboot the client,
I log in to a client with local administrator, checked pcoip agent/server logs, no -500 errors or similar, mostly 0, one error regards to certifcate, but we have no offical ssl yet on the connection server. No apparent or obvious error messages.
* Local firewall on clients are disabled through GPOs, and firewall in our company have ports opened since this setup has worked fine before.
* This problem is also now happening on another Desktop Pool (in same environment, different template/snapshot).
In log on VMware Connection server, it says BROKER POOL PROTOCOL UNAVAILABLE.
I have found that VMware vSphere says, when recomposing,:
"The device naa.xxxxxxx performance has deteriorated. IO Latency increased from average value 2432 microseconds to 49651 microseconds."
and
"Migration of "win-template" to "esxi-host1.contoso.com" and resource pool. Resources: Copying this virtual machine will cause loss of snapshots at the destination"
What does this mean?
Ok, so this is the problem, and some solutions we have tried.
I have found that the work-around for all this is to reboot the desktop 1 time after recompose is done.
This causes everything to work fine, as it's supposed to - log in works fine and user connects. However, when user logs off, desktop is deleted, then recomposed from the snapshot/tenplate, ie gives the same error when new user tries and gets allocated this same desktop.
I have found a citrix/vmware blog, which mentioned GPO issues. GPO not beeing applied, until another reboot after recompose.
However, I can not wrap my head around what GPO or setting missing would cause this timeout or PCoIP error message, I have previously used View without GPO settings for View persona/agent, and it worked fine.
I think we can eliminate firewall issues, since it is working after the desktop is rebooted, and it has worked before, and network dep says no changes have been made (have to trust them:) )
We can always create a script, to boot machines after recompose etc, but this is a nasty workaround, and we need to get this fixed.
Any hints and tips people?
Thank you very much.