Review the external url, it has probably been reset to the hostname of the View Connection server in the upgrade.
I thought that you'd might have something there regarding the HTTPS Secure Tunnel > External URL, but it doesn't appear to be the case. The help button next to this setting reads:
The setting is disabled if Use Secure Tunnel connection to desktop is unchecked.
View Clients use the External URL to establish a secure tunnel to this View Connection Server instance.
If a server name is specified, it must be resolvable by each View Client.
The External URL must not be load balanced.
In my testing, it doesn't seem to matter if the External URL for the Connection Broker is set to https://desktops.example.com:443 (friendly external URL) or https://viewconnect4.example.local:443 (internal FQDN). In either case, the result remains the same. View 5.1.3 Agents and below can connect externally via PCoIP but the View 5.2.0 Agent cannot.
The last line of the help pop-out concerns me though: "The External URL must not be load balanced."
My objective is to have all employees learn and use a single URL -- https://desktops.example.com:443 -- regardless of location. Internally, I use DNS load balancing by having three A records servers viewconnect1.example.com, viewconnect2.example.com, and viewconnect3.example.com. Externally, I have just one https://desktops.example.com DNS A record that points to just one Security Server that is paired to viewconnect4.example.com.
My concern is that the Connection Broker viewconnect4.example.com is inside the domain and would thus listen to my internal DNS servers that are performing load balancing tasks for desktops.example.com, to servers that do not have the HTTPS Secure Tunnel enabled and are not paired to the external Security Server. While older View Agents were accepting of this configuration, perhaps the View 5.2.0 Agent is not.
If not, how do others use DNS load balancing with View 5.2.0 to present just a single URL for internal and external access? Perhaps modifying the "hosts" file on viewconnect4 be a solution to prevent it from accessing our internal DNS servers.
Changing the "C:\Windows\System32\drivers\etc\hosts" file on viewconnect4.example.local didn't make a difference. I tried both of these values (not at the same time):
127.0.0.1 desktops.example.com 172.22.55.55 desktops.example.com
I then flushed my DNS cache "CMD > ipconfig /flushdns" and made sure that if I pinged desktops.example.com on viewconnect4.example.local that it responded correctly and did not respond with an IP from viewconnect1, 2, or 3.
In View Admin > View Configuration > Servers > Connection Servers > viewconnect4 > Edit > General > HTTPS Secure Tunnel > External URL > I tried both https://desktops.example.com:443 and https://viewconnect4.example.local:443.
Same result for all four tests. Desktops with the View Agent 5.1.3 and below all work. Desktops with the View Agent 5.2.0 fail to connect via PCoIP.
I haven't made the move to 5.2 as of yet (on 5.1.X), but the first thing that came to mind were the PCoIP Secure Gateway settings on the paired CM and SS. Have you verified your settings for "PCoIP Secure Gatway" did not get changed during the upgrade?
Thanks for offering to help. Here's my configuration...
- Server Name: viewsecure2
- Paired With: viewconnect4
- HTTPS Secure Gateway > PCoIP External URL: https://desktops.example.com:443
- PCoIP Secure Gateway > PCoIP External URL: 68.xxx.xxx.xxx:4172 (help says "An IP address must be specified, not a server name.")
- Blast Secure Gateway Blast External URL: https://desktops.example.com:8443
- Server Name: viewconnect4
- Paired With: viewsecure2
- HTTPS Secure Tunnel > External URL: https://desktops.example.com:443
- PCoIP Secure Gateway > PCoIP External URL: 172.xxx.xxx.xxx:4172 (I also tried the same external IP 68.xxx.xxx.xxx:4172 as the Security Server)
- Blast Secure Gateway Blast External URL: https://desktops.example.com:8443
I restart the VMware View Connection Server service on viewconnect4 after making changes. Results are the same. View 5.1.3 agents can connect with all attempted settings. View 5.2.0 agents via PCoIP fail all attempted settings.
Following this KB Troubleshooting PCoIP Secure Gateway (PSG) issues (1034825) I'm still unable to resolve my issue:
To troubleshoot issues starting a PCoIP session using PSG:
1. Check the operating system's version of the Security Server and Connection Server.
- Security Server OS: Windows 2008 R2 SP1
- Connection Server OS: Windows 2008 R2 SP1
2. Check if the correct Security or Connection server is configured for PSG.
- VMware View PCoIP Secure Gateway service is present and started on both the Security Server and the Connection Server
- View Admin > View Config > Servers > Security Servers > viewsecure2 reports PCoIP Secure Gateway is Installed
- View Admin > View Config > Servers > Connection Servers > viewconnect4 reports PCoIP Secure Gateway is Installed
3. Check that the Security Server and Connection Server are paired.
- View Admin > View Config > Servers > Security Servers > viewsecure2 is paired with viewconnect4
4. Ensure that the PSG is enabled in the Connection Server.
- View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway is Enabled (checked)
5. Check the configuration of PSG settings.
- View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > HTTPS Secure Tunnel > Use Secure Tunnel connection to desktop is Enabled (checked) > External URL > https://desktops.example.com:443
- View Admin > View Config > Servers > Connection Servers > viewconnect4 > General > PCoIP Secure Gateway > Use PCoIP Secure Gateway for PCoIP connections to desktop is Enabled (checked) > PCoIP External URL > 68.xxx.xxx.xxx:4172 (same IP found at View Admin > View Config > Servers > Security Servers > viewsecure2 > PCoIP Secure Gateway > PCoIP External URL (e.g. 68.xxx.xxx.xxx:4172)
6. Check communicating and firewall rules.
- Front-end and back-end firewall rules are vaild since View 5.1.3 Agents and lower can estabilish external PCoIP connections to the same resources
Is the Security Server and Connection Server at 5.2?
Thanks markbenson. Yes, VMware View Composer, Connection Servers, and Security Servers were all upgraded from View 4.6.0 to View 5.2.0.
Next I began upgrading the View Agents from 4.6.0 to 5.2.0 in my parent virtual machines and rebuilding those desktop pools when I discovered that external PCoIP stopped working for the desktops with the newest agent.
I eventually downgraded to the View 5.1.3 Agent, which works and is holding me over as I troubleshoot getting the View 5.2.0 Agent to work.
I had a problem with some linked clones not working on 5.2. Instead of doing an upgrade of the agent I removed the old agent completely and then installed the 5.2 agent. Also just for testing purposes turn off Windows firewall and see if you can connect. I had a windows update reset the firewall rules that were created for connection server.
The fact that PCoIP access remotely via Security Server works to your 5.1.2 Agent pools suggests that the firewall rules, PCoIP External URL and connection server settings are correct. It is therefore odd that you can connect to your 5.2 Agent pools internally. Check that your firewall rules in any external firewall will allow communication from your Security Server to the 5.2 Agent pools. This assumes we are talking about the same Connection Server, Security Server and network in both cases.
PCoIP connection failures with a brief black screen are usually either caused by incorrect remote access setup (PCoIP External URL, Connection Server settings or firewall rules blocking PCoIP). The 3 steps required are described here - Setting up PCoIP Remote Access with View 4.6 and Newer - A config error in any of the 3 steps will give a PCoIP black screen.
General PCoIP black screen problems (internal or remote) are usually caused by the customer downgrading the graphics driver after View Agent is installed (e.g. by installing Tools after installing the Agent), configuring insufficient video RAM or some other factors such as color depth or 3D settings etc. Can you carefully check these things between your working View 5.1.2 Agent VMs vs your 5.2 Agent VMs. Having an insufficient display resolution between these different pools can cause a black screen. Recheck the firewall rules on your 5.2 Agent VMs to make sure the TCP rule and UDP rule for 4172 is present. Blocking these ports will certainly cause the black screen problem. Uninstall and reinstall the View 5.2 Agent to make sure the graphics driver is correct and that the firewall rules are set up correctly.
When you say connection works to the new View 5.2 Agent VMs internally but fails externally, is this from the same client device? Similarly when you say remote access works to 5.1.2 Agent VMs but fails to View 5.2 Agent VMs is this also with the same client device?
We do know that View 5.2 Agents work with View 5.2 Connection Server and Security Server. Many people have upgraded to this version since release in February and are operating this with internal access and remote access.
If you still can't set it up correctly, you'll need to start looking at PCoIP traffic flows in your environment to see if PCoIP is being blocked or misrouted somewhere. Wireshark or similar can help here.
From what you've said, I assume there are no load balancers involved in this setup. This is happening when connecting to just one Security Server.
Please post back to let us know what it was. Thanks.
Meyner22: Thanks for responding. At first, I performed an in-place upgrade of the View Agent in my Parent Virtual Machine from 4.6.0 to 5.2.0. When that failed (externally, internal PCoIP works) I build a brand new Windows 7 PVM with a fresh install of the View 5.2.0 Agent. I tried having the Windows Firewall Service started with profiles disabled, as well as the Windows Firewall Service started with profiles enabled, before installing the View 5.2.0 Agent. I then skipped all Windows 7 optimization scripts and put the new pool in a new Active Directory OU with no Group Policies. No luck. External/WAN PCoIP connections fail. If I downgrade to the View 5.1.3 Agent (uninstall, reboot, install), external/WAN PCoIP connections work.
Markbenson: Thanks for sticking with me.
I agree. If external/WAN PCoIP connections work to desktops with the 5.1.3 Agent, then my DMZ/firewall rules, Security to Connection Server pairing, SSL Certs, and even Windows Firewall rules should all be correct. My test desktop pools are in the same VLANs/subnets as my production desktop pools. I even recomposed my production virtual machine (just my machine, not the entire department’s pool) to the View 5.2.0 Agent. Same result. I can connect internally but not externally.
I have only one Security Server to Connection Server pairing, so all tests are going through the same servers and network paths.
Regarding the PCoIP black screen, I don’t quite make it to a black screen. I get the dark gray remote desktop border with a hollow/transparent inside (it’s not filled with black and instead shows my desktop) for 1 second before the connection is closed. I am certain that the last thing that I install on my PVMs is the View Agent, but thank you for reminding everyone that the Agent must be installed after Tools.
For display resolution, here’s how I have things configured.
- vSphere > PVM > Edit Settings > Hardware > Video Card > Auto-detect video settings
- View Admin > Inventory > Pools > Test 5.2.0 pool > Edit > Pool Settings > Max number of monitors = 2 AND Max resolution = 1920x1200
Most of my external testing has been done via a Windows 8 x64 virtual machine I have at home. When I perform the test I select “Windows – Small” for the display. I’ve also tested externally via my iPad and iPhone, both with the newest VMware View Client. My iPad is able to connect internally to a 5.2.0 desktop at work but not externally from home.
I have provided VMware Support eight Wireshark packet captures:
- Security Server > External Client to a 5.1.3 Agent
- Security Server > External Client to a 5.2.0 Agent
- Virtual Desktop with 5.2.0 Agent > Internal connection via a 5.2.0 Client
- Virtual Desktop with 5.2.0 Agent > External connection via a 5.2.0 Client
- Work Laptop/Client > Internal connection to a 5.1.3 Agent
- Work Laptop/Client > Internal connection to a 5.2.0 Agent
- Home Lab/Client > External connection to a 5.1.3 Agent
- Home Lab/Client > External connection to a 5.2.0 Agent
What we find is no UDP traffic for external attempts to the 5.2.0 Agents. VMware Support is still reviewing this data.
I appreciate everyone’s ideas. If you have any more, I’ll be happy to test. In the meantime, I’ll continue to work with VMware Support. Thank you.
1 person found this helpful
We had a similar issue and went through this:
Not sure if you had seen this yet or not. Did not see it referenced.