Are you using a third-party load balancer or the native High Availability feature in UAG 3.5?
A black screen is typically a communication issue. Verify the PCoIP Secure Gateway is disabled on the connection server(s) that the UAG point to. If it's disabled make sure that routing and the firewall will allow the necessary communication from the UAG to the Horizon Agent.
I'm using the built in HA feature in the UAG's.
(it turns out the PCoIP problem was just a missed firewall rule)
Here's the situation I want to solve (I'll worry about everything else later ), when I log into the user web interface at view.myco.com I am able to authenticate fine. However when I launch a desktop I get a certificate error, the UAG is presenting the certificate for view.myco.com when I'm really trying to connect to view1.myco.com:8443. So to boil it down, my question is how do I get the UAG to present one certificate via the VIP, and then another certificate when it's called upon using its non-VIP IP?
Some more items to complicate the issue:
1) A wildcard cert would solve this problem, but we're not allowed to use wildcards
2) I tried to upload a PEM certificate with a private key, but the UI errors out saying "Provide only one certificate". So I try just providing just the public cert by itself and it takes it, which doesn't do me any good because the private key is from another machine. Does this mean that I need to generate the CSR on the UAG? And if I do that, does it get me to my goal of one certificate on the VIP and another on the UAG IP?
I think this may be solved by using a a SAN cert across your UAG's which contains the names view, view1, and view2. Have you tried that?
EDIT: I am reading up on this because I'm not well versed in the UAG technology. However from this page, nified Access Gateway Configured with Horizon , it looks like the UAG isn't doing "true" load balancing. What hits the nail on the head is the line under the diagram that reads "The affinity is based on the source IP address. The first connection from the client is distributed using round robin mechanism. However subsequent connections from the same client are sent to the same Unified Access Gateway which handled the first connection."
Quickest way to fix this is use a SAN cert as stated above. There are ways you can do this with a separate load balancer in front of your UAG's and not using UAG HA, but that gets complex.
Yep, that's what I had to do. Putting the SAN cert on the UAG's solved the problem. I'd still like to know what those little links to replace the Blast and tunnel certificate actually do, but in the end it's working and I've got other problems.
Not too sure, but if I had to guess that would be used if you had AirWatch or Workspace also deployed that is authenticated through your UAG. Each service would require it's own external DNS name, requiring a different certificate. At that point you would want to have separate certificates for each service.