I have updated my lab environment to the newly released vSphere 5.1a version, I was already running View 5.1.1 and Windows 8 RTM on vSphere 5.0u1 with great success.
No matter what I try, I am unable to get Windows 8 RTM, View 5.1.1 and vmtools v9 to play nice. When I use that combination, the View client gets a blank screen for a few seconds then it closes (PCoIP) or I get an error 2825 with RDP. The desktop VMs show up as Available in the View console but no client connections are possible.
Note that when a View client tries to connect, I can see on the VM console that the user logs on, but after a few seconds, the desktop locks. It's as if the "session" never gets transferred over to the View client.
The workaround is to keep the vmtools at version 8.5.6 but if anyone knows how to make this work with the latest release, please let us know.
I met the same issue with you.
Let me add a few more details based on my observations... I am very confused by what I see... some PCoIP connections started to work by themselves as far as I can tell but still won't work from my home office - please read.
Let me start by saying that I miss PCoIP very very much when working from home... using RDP over the WAN is not fun 😞
I have two completely separate View environments:
- The first is what I call a "CrashNLean" installation that I use every day to run my own virtual desktop and experiment with the latest and greatest releases of View component. It is currently running vSphere 5.1 (vmtools v9) and View 5.1.1.
- The second is a shared development and integration (DevNTest) testing View instance where a team of individuals work, it is a change-controlled environment running vSphere 5.0U1 (vmtools 8.6.5) and View 5.0.1.
From the home office:
- Using a Cisco Linksys E1200 N router, View client 5.2 on a wired Windows 8 desktop, View client 5.1.1 on a wireless Windows 7 laptop. (connections are NATed)
- While I can connect to DevNTest virtual desktops with PCoIP from my home office, I am unable to connect with PCoIP to any desktops running in the CrashNLearn environment since it was upgraded to vSphere 5.1. It was working fine with View 5.1.1 on vSphere 5.0U1. RDP works fine to both environments from both computers (desktop and laptop).
- What I see when trying to connected to CrashNLearn is a black screen (sometimes it's just a frame) for about 15 seconds, then a message that the connection timed out (The connection to the remote computer timed out). This fails not only with Windows 8 VMs but also with Windows 7 VMs.
From the work office:
- Connected to the corporate LAN on the same subnet as the View environments, VXL vTona Thin Client (PCoIP only), View client 5.2 on Windows 8.
- PCoIP connection to both View environments work fine from this location. RDP works fine also for the Windows View client.
From Hotel network:
- Hotel wifi connection, View client 5.1.1 on Windows 7 laptop
- Can connect to both View environments with PCoIP and RDP.
From 3G network:
- iPad with latest View client over a 3G wireless connection
- I can connect to both View environments with PCoIP.
- Since I can connect to one of the View environment from home, I know my home network is setup correctly to handle PCoIP.
- Since I used to be able to connect to my CrashNLearn when it was using vSphere 5.0U1 and View 5.1.1, I don't think it's an issue with View 5.1.1.
- Since I can connect to both View environments from the work office (corporate LAN), 3G and the hotel networks, I know my View security and connection servers and firewalls are all configured correctly to handle PCoIP.
- Since PCoIP connections are also failing from home with Windows 7 VMs, I know this is not a Windows 8 only issue.
- The only location it's failing from is from my home network but to only one of the two View environments.
What could it be?
- Is there a difference in how NAT connections are handled with View 5.1.1 on vShere 5.1 (vmtools v9)?
- I have checked all the firewall settings, I have tested access with telnet to 4172, 4001, 8009, etc.. ports
- I have re-build the Windows 7 and Windows 8 VMs from scratch a few times (way to many to remember), ensuring the vmtools and View agent were installed in the right order, with reboot in between.
- I have tried with older vmtools (v8.6.5) on Windows 8 - no luck.
I will take a look at the View client and agents logs and post the relevant details if I can find them.
In my ENV, the win7 is works well. win8 cannot conect by PCOIP.
It's the other way for me, I am able to get to Windows 8 VMs with PCoIP but not RDP (error 2825).
Here's a quick update on this situation:
After a suggestion from a colleague of mine to try bypassing my home router, a Linksys E1200, I connected a laptop directly to my cable modem and it works!
So, now the question is why is it working with the router for one environment and not the other, and how do I fix it?
I suspect it has to do with the handling of the NATed connection by my Linksys E1200 router... but I have not changed anything on the router (it's pretty much using a default configuration).
How are NAT connections handled by View?
Could it be something on the Security Server?
I found the problem!!!!
The security server is dual-NIC'ed (one leg on the Internet, one on the internal network) and for an unknown reason (to me at least), it was trying to respond to UDP packets to Videotron (the ISP where the problem was observed) using the INTERNAL interface while it should have been using the EXTERNAL one.
For reasons I don't understand, it was sending the replies to the correct interface for other ISPs (Rogers and Comcast are the ones we tried).
To work around the problem I removed the default gateway on the internal interface but I am wondering what is the correct way of configuring a dual-homed security server to avoid this problem?
Is youre internal subnet the same as the subnet the ISP has been presenting to you? i.e. are you both using a 10.X.X.X subnet?
If so change your internal subnet 192.168.X.X
They are not the same, my home network is 192.168.x.x, the ISP network presented to me is 24.x.x.x. and the internal network is 10.x.x.x.