Setting up PCoIP Remote Access with View 4.6 and Newer

Setting up PCoIP Remote Access with View 4.6 and Newer

Starting at version 4.6, View has the ability to support PCoIP remote access through the View Security Server. See View 4.6 Announcement.

I posted an article back in December 2010 in the End User Computing CTO site about this forthcoming View release and described how it works. See Secure Remote Access with View and PCoIP.

Some people report that when they setup PCoIP remote access with View 4.6 and try a PCoIP connection from the View Client, they just get a black screen for a few seconds and then an error indicating that the session has ended. On the iPad View Client this problem shows as a message saying "your desktop is loading too slowly". In the vast majority of cases, this was caused because one of the 3 setup steps shown below was not done or not done properly. If you're getting these symptoms, then check very carefully that these 3 simple steps have been done correctly.

When View Connection Servers and Security Servers are running 4.6 or newer, you can enable this functionality by following these three steps:

1. Enable PCoIP Gateway functionality on each Connection Server. By default, PCoIP connections are direct from the View Client to the View virtual desktop as they were in View 4.0 and 4.5. If you have some Connection Servers for remote access and some for local access then just do this for the remote access ones. That way local access PCoIP can still be direct to the View virtual desktop. Using View Administrator, go to the Configuration Servers section. Select a Connection Server, select Edit and tick the box "Use PCoIP Secure Gateway for PCoIP connections to desktop". Then for all users of this Connection Server and any Security Servers attached, PCoIP will gateway through either the attached Security Servers or this Connection Server. The server used for the PCoIP gateway (usually the Security Servers) must be running View 4.6 or newer on Windows Server 2008 R2.

2. On every attached Security Server, set up the “External URL” and the new "PCoIP External URL". These URLs are used by the View Clients to connect to the particular View server. These names and addresses must be resolvable and usable by the clients. If remote connections are made directly to the Connection Server then the External URLs must also be setup on the Connection Server.

3. Update the firewall to allow PCoIP to pass through. This is:

PCoIP between View Client and Security Server

  • TCP destination port 4172 from Client to Security Server
  • UDP destination port 4172 from Client to Security Server
  • UDP source port 4172 from Security Server to Client (this is the reply UDP data)

PCoIP between Security Server and virtual desktop

  • TCP destination port 4172 from Security Server to virtual desktop
  • UDP destination port 4172 from Security Server to virtual desktop
  • UDP source port 4172 from virtual desktop to Security Server (this is the reply UDP data)

This is in addition to the firewall rules used in View 4.5.

For further details, refer to the View 4.6 Architecture and Planning Guide and the View Administrator Guide here View Documentation.

For a more detailed examination of this, take a look at this video. It goes into details on the deployment and architecture for PCoIP remote access with View 4.6 and goes through a worked example involving remote and local access, load balancing, the n+1 VIP model, the external URLs etc. and shows how it is all configured through View Administrator.

Mark Benson - VMware - View Architect - End User Computing CTO Office

Comments

Does this impact WAN performance relative to the current version?

Presumably it will not consume as much bandwidth by avoiding the additional TCP encapsulation, but also wondering what the outlook is for further reducing the PCoIP bandwidth or having some ability to "tune" the connection for better performance in high latency/low bandwidth connections.

You're exactly right. Running PCoIP natively without encapsulation over a TCP protocol in this way is much more efficient and also improves the user experience. It also works from all View clients, even the Teradici Zero Clients.

It is always a good idea to tune PCoIP for your exact requirements to get even greater improvements.

You can, for example, reduce the PCoIP frame rate on the virtual desktop to improve WAN performance and reduce bandwidth requirements.

There are some good papers on this.

http://www.vmware.com/files/pdf/VMware-View-PCoIP-Network-Sizing-Guide-IG-EN.pdf

http://www.vmware.com/files/pdf/VMware-Teradici-PCoIP-Zero-Client-Remote-Access-Guide.pdf

http://www.teradici.com/pcoip/pcoip-technology/pcoip-faqs.php

Mark.

There are some Group policy templates available on the connection brokers that will allow you to change PCOIP settings.

Thank you for the hints and follow ups. These posts have been helpful.


When using the View Security Server url to connect to the View Connection Server, I am getting a black screen and a connection timeout only when the “Use PCoIP Secure Gateway for PCoIP connections to desktop” is set on the View Connection Server. If this flag is not set, the connection to the desktops works fine.

I have tested on an internal network where all machine firewall are configured correctly, as well as where all machine firewalls are turned off. The disconnect and timeout does not appear to be firewall related. Any suggestions?


I have thoroughly read and followed all the tips and hints at these locations:
http://www.vmware.com/support/pubs/view_pubs.html
http://communities.vmware.com/people/markbenson
http://paulslager.com/?p=1300
http://paulslager.com/?p=1326

You'll get a black screen if any of these 3 steps haven't been done correctly.

Double check all your settings and in particular check that the External URL and PCoIP External URL are set correctly on your Security Server. These must contain names/addresses usable by the client to connect to the Security Server.

If it still doesn't work - go through the video for a complete worked example. You don't need to watch the whole thing, you can skip to about 18 mins in for the details of setting this up.

Use netasat -an to check that your Security Server is listening on UDP 4172 and TCP 4172.

Make sure PCoIP isn't being blocked anywhere. The logs and wireshark traces may help you.

If you still can't get it configured correctly, give us more details of your setup and someone will be able to help you further.

Mark.

Hi Mark,

First of all, thank you for providing this video. Smiley Happy

I do have a question on setting up the security servers based on your video.

1. To split the security server to two (internal and external use), do they need to be installed as a replicate or stand alone security server?

2. Just watched the following youtube video on how to install the security server.

It's stated there that the Security Server host must be joined to the Active Directory domain.

On your example, the security server ip address is using a totally different subnet (192.168.1.xxx) than the local network (192.168.2.xxx). Is that mean they are not part of Active Directory? Is it because they are sitting on the DMZ?

Please advise.

Thank you so much.

Thanks for those comments.

No. View Security Servers don't need to be joined to an AD domain.

It's normal for Security Servers not to be joined to an AD domain to simplify the firewall rules in a DMZ.

Hi Mark,

Thanks for the prompt respond. Smiley Happy

Btw, looks like you replied while I edited my comments. I wasn't fast enough. Oops.

Do you think you know the answer of my first question by any chance?

Thanks.

I'll try and respond less promptly in future 🙂

If you have one or more Connection Servers for internal and one or more for remote access, they can all be part of the same View cluster (i.e. 1 standard and the others replica). That way that can all be managed as one View environment.

Mark.

Hi guys...

Thanks for all these helpful comments and posts.

I was wondering if I would still need a security server if I use a Cisco VPN to connect to my network. Will PCOIP work if I connect thorugh the VPN directly to my broker?

Thanks so much!

Haha. Smiley Happy

Thanks again.

@acaceres2007

You don't need a security server if you are using Cisco VPN.

That's what we have previously but then Cisco VPN users complaint that they were seeing blurryness on their screen a few to many so I thought maybe by bypassing the VPN and use the security server on the DMZ will solve that problem. Smiley Happy

We'll see how it goes. Hopefully it'll be better.

Now the trick is how to put the Security Server VM on the DMZ.

I'm still working on it... :smileyplain:

Make sense... thanks!

Check this out!

http://paulslager.com/?p=1300

I found that blog on the internet!

regards,

Anyone know why the video no longer loads?

Thanks,

Bob

The YouTube video posted in a comment above is not my video. This was not correct anyway and has been withdrawn by the user.

The video you want is the one at the bottom of the article (on vimeo). That loads fine.

Thanks for the reply Mark.  Actually, that video won't load for me either, but I am sure it has something to do with our proxy not allowing access to vimeo.  I know we block youtube, so probably vimeo too.  Anyway to download it so I can watch it offline?

Bob

Yes, it does sond like your proxy. I'm sorry you can't watch it, but it sounds like it's a deliberate policy in your company to block access to videos. You'll need to access it in a place where you have full Internet access. In the mean time time, if you have any questions, then please feel free to raise a discussion thread in the main View communities section, and we'll hopefully answer any questions you have.

I currently see a problem. If you are behind a proxy server, the PCoIP port (TCP/UDP 4172) blocked by default.
This is a Security Policy by many Companys.


In which version will be tunneled PCoIP completely in SSL.

TNX

We initially looked at various options around tunneling the PCoIP traffic through Security Server but we really didn’t want to interfere with the advanced performance characteristics of the protocol. The step improvement in having a UDP based remote display protocol would be somewhat eroded if we just tunnelled that over an HTTPS connection which uses TCP as its underlying transport protocol. HTTPS encapsulation is good for RDP, but PCoIP is already secured by AES-128 encryption over the wire and so double encryption is unnecessary. We also wanted to ensure we will support existing PCoIP based View clients, newer clients such as Wireless and 3G enabled iPad etc., and third party clients based on the Teradici zero client in a really easy and intuitive way. It was clear that customers want the same security, connectivity and ease of administration benefits from Security Server that they are used to for RDP and other TCP based protocols, but also want to maximize the user experience with PCoIP for the remote access case.

We recognise that sometimes, people will block 4172 and in these cases PCoIP will clearly not connect. For these cases it is still possible to drop back to RDP. Also View supports third party VPNs to connect so that's another option.

For the vast majority of cases, PCoIP is allowed through proxies and firewalls etc. and in this case the user gets the best possible compatibility and user experience.

Mark.

Hi Mark,

Thanks for highlighting these common problems.  I had fallen foul of step 1 (Use PCoiP Secure Gateway for PCoIP connections to desktop).

For anyone else who missed it, it is in the ViewAdministration 4.6 document:

"Configure the Secure Tunnel Connection and PCoIP Secure Gateway", (Page 20)

and

"Connection Problem Between View Client and the PCoIP Secure Gateway", Step c. (Page 287)

I found this post as I was having the 'black screen' issue.

Thanks again,

Nick

Thanks for the feedback Nick. It seems like a popular topic. I'll try and put some more of these posts out.

Mark.

I too have the black screen issue and have followed the video and all documentation with no luck.  MY security server is listening on TCP/UDP 4172 and I have opened up HTTP, HTTPS, and 4172 TCP/UDP on my firewall to the Security server.  In my setup the Security server is just on the local LAN, not in a DMZ and is a domain server.  there is no firewall/router between the local view desktops, ESX servers, or vCenter server and the Security server.  the box for PCoIP gateway is checked.  all works internally and RDP works externally but PCoIP does not.  I am using a SonicWall NSA 2400 and it appears that all the correct ports are open as i can telnet from outside to the Security server on 4172 and HTTP/HTTPS are working correctly to it.  any other thoughts or ideas that might help me out?  thanks!

Please use the discussions forum for questions like this. There are several threads on this already and people have got it working by going very carefully through the 3 setup steps described in this document.

Have a look at this thread - http://communities.vmware.com/message/1860942#1860942 . It has a very similar case to yours and was resolved. There is also some steps that were used to diagnose the configuration error to get it working. You should follow these steps and you'll soon be up and running. You can either start a new discussion post on the discussions section or add further comments on the discussion I referenced.

If you haven't done all the 3 steps correctly, it will result in getting a black screen when you select the desktop pool. It's an indication that PCoIP is being blocked.

Mark.

Thanks for the info but I have already looked at that one and it didn't provide any further info.  At first glance I thought outbound UDP was the culprit (not sure how or why as no outbound connections are blocked but it appeared to be that way) but further checking I realized that the PCoIP external gateway was still set as the internal IP address of the Security server rather than the external address.  I changed it and now instead of the black screen that says the connection ended I now get a black screen for a much longer period of time and finally a pop up saying the connection timed out.  So far I have not been able to find much on that particular error.......

Please start a thread on the Discussions forum and people will help you out.

Mark,

Great posts!  We are going to have a simple setup, we are only needing about 6-8 users to have remote capability.  I have setup a Connection Server and all works well from inside my network and I do see quite a few posts about the Security Server, but my question is, is a Security Server required if I setup all ports to point to my Connection Server through my firewall.  We are trying to maintain as small an infrastructure as we can.

Regards,

Mike

You're quite right. Security Server is optional. All Security Server functionality is also co-hosted on Connection Server so with a small setup, you can have a Connection Server only. It must be Windows Server 2008 R2.

When you set it up, if you have any further questions, post a message on the Forum discussion pages and we'll help you out.

Mark.

What are the disadvantages to skipping the Security Server layer and just putting your Connection Servers in the DMZ? Is the function of the Security Server to simply to proxy the session thru the DMZ? In the video you say the Security Server is a subset of Connection Server - what is left out?

I am just seeking to understand in order to keep things simple while not compromising security. Thanks!

Steve

The security servers leaves out all of the admin functionality and ADAM database portion of the connection broker.

of course, thanks!

Thanks for the excellent info, Mark.  We have a View 5 environment and I got everything setup properly and was able to access VMs remotely via the standard View client and iPad client through the Security Server.  However, there was an issue where I was trying to setup 2 users in a remote office and remote access from one PC works fine (PCoIP or RDP via the standard View client) but the other PC would only connect via RDP.  Both Win7 PCs have firewall on with exception rules for the View client.  Since I have no access to the firewall in the remote office, could this be a firewall issue in the remote office?  Thank you for your help.

Yes, it could be firewall. If any of the 3 steps are not done it will cause a black screen with PCoIP. Check out step 3 above for the firewall rules. If a firewall blocks the PCoIP protocool it won't work. If you still have a problem after checking step 3, then give us the details on the Discussion section and someone will help you.

Mark.

Hi Mark,

I've tried to configure my View 5.2 environment as shown in the video. I've few questions and would like you to answer them please.

1- Users will connect to myview.mydomain.com through Load Balancer VIP but we're not giving any URLs in the External URL instead we're giving an IP Address. Due to which View Admin console giving error that "SSL Certificate doesn't match the External URL".

2- Do we need to configure HTTP to HTTPS redirection on Load Balancer end? Because after configuring myview.mydomain.com as VIP, HTTP doesn't work anymore but only HTTPS works.

3- Can we use View Security Internal IPs (which are in DMZ) on External URL and PCoIP External URL?

Please find the attached screenshot of my current configuration which works fine using Source Hash. Only 2 issues as dicussed above
View Administrators shows SSL Certificate does not match the External URLs and HTTP to HTTPs redirection.

Looking forward for your answers.

Cheers

You can ask questions about this on the Discussions section. That allows others to contribute too. Thanks.

Version history
Revision #:
1 of 1
Last update:
‎02-25-2011 04:34 AM
Updated by: