view 4.6 client cant connect internally using PCOIP

[chaz112182]

hello,

if i fire up the view client from outside our network i can connect with PCOIP no problem. we have an external dns service that point security.domain.com to the public IP address of the security server.  we are using a static NAT at the moment (planning on moving the security server to the dmz with load balancing in the near future) so the security server is joined to the domain and has a private IP address.

when i try to connect with the view client internally using secuirty.domain.com using PCOIP i just get a black screen. local dns resolves security.domain.com to the private IP address of the security server. i can do an nslookup and it resolves properly. i can do a tracert and that completes successfully. i originally thought it was a dns problem but this seems less likely since dns appears functional. the windows firewall on the security server is set to disabled so it's not that either. im sure its something simple i am looking over.

i'd appreciate any insight ...  cheers!

[chaz112182]

forgot to mention that RDP works just fine with security.domain.com both externally and internally.

[mittim12]

Can the clients access the PCOIP external URL?  

[chaz112182]

indeed. internally i can goto security.domain.com (the external pcoip url) and download the client. i can even connect using rdp using security.domain.com. when i select PCOIP is alows me to choose my desktop pool connects and then i just get a black screen and am eventually disconnected. 

[markbenson]

99% of the time, a PCoIP black screen is caused by one of the 3 setup steps not being done or not being done correctly. http://communities.vmware.com/docs/DOC-14974

In the case where you are wanting to support local and remote access in the same View environment you should dedicate one or more Connection Servers for each purpose. That's because it is better for internal clients to access the PCoIP virtual desktops directly (not gatewayed).

You can do it with a single Connection Server but it is less efficient for internal users. In this case local and remote users will be the same.

I'm confused by your statement that security.domain.com is the "PCoIP External URL" because this must be an IP address (not a DNS name). It sounds like your Security Server is set up correctly as remote PCoIP View Clients work. The problem will be that the "PCoIP External URL" is not usable by your internal View Clients (either firewall reasons or because the internal clients can't use the IP address in your Security Server "PCoIP External URL").

You can fix your setup, but I would advise you to use a different Connection Server (replica) for the internal users.

Mark. 

[chaz112182]

i appreciate the responses.

@mark sorry for the confusion regarding the pcoip external url being a fqdn and not an IP address that was a mistake on my part. we are indeed using the public IP address of the security server for the pcoip external url. we are using the fqdn for https secure tunnel external url which of course is externally resolvable.

if we wanted to make this work as is would we just need to change the https secure tunnel to use the public IP addess of the security server? internal dns resolves the fqdn of the security server to its local IP address.

eventually we will be working to segment internal and external users in an effort to allow direct pcoip connections on the LAN.

great job on the 4.6 pcoip remote access video you posted. that was very helpful in getting our infrastructure setup.

[Camek]

For this to work on the inside and outside you are going to need two different security servers or have a security server for outside and a connection server on the inside.  The issue is PCoIP requires an IP address setting for the external URL value and because you need to different IP (one inside and one outside) you have to use two different servers..  So how we do this is we have a security server setup with the "PCoIP Secuirty Gateway" external URL set to the external IP address which is visable from the internet.  Then on the connection server we have set the "PCoIP Secuirty Gateway" external URL set the intranet IP address of the connection server.    If you want you can play around with split DNS where the same URL ( view.mysite.com )points to differnet IP inside and outside the network so users don't have to use two differnet names in thier view client.

[chaz112182]

@camek thanks for the response.  currently we have a security server and two connection servers in our environment.  my colleuge and i were disucssing what you've mentioned in regards to split dns.

we currently have an external hosting site that serves up connection.company.com and that points to the public IP of the security server. we had planned on trying to edit our internal dns so that connection.company.com points to the intranet IP address of the connection server.  based on your reply it seems like this should work until we have sometime to setup this up properly with dedicated connection servers for external and internal traffic.

thanks again.

[Camek]

Yes, that should work fine...  Before PCiOP you could make this inside and outside network stuff work with one server because the "external" could be a URL reference but now the PCiOP must have an IP address it takes a bit more to make this setup work.  

Happy VDing...

[genoIE]

I am dealing with the same issues. I am trying to set up a replica server for the internal access but cannot see the same linked clone desktop pools. The issue is for traveling internal employees, they cannot see the same desktop from both internal and external. Is there a way to make the same desktop pools accessible from both internal and external?

Thanks

Gene

[markbenson]

You need to install the second Connection Server as a replica of an existing one. That way, it doesn't matter which Connection Server you go to, by default, users will see the same virtual desktops.

Mark.

[genoIE]

I did that, I thought. I will try again. I thought I might be missing something because I thought it should work that way.