Unable to add a "View Pod" using Horizon Plugin

[SBC350]

Hi,

I installed the Horizon Plug-in for vCO and following the doc, I only get as far as adding the View Pod in configuration but it fails.

If I try to add the View Pod using the DNS Alias, im getting a "view-alias.domain is untrusted" , if I try to add it using any of my 4 View connection server directly, it fails at the Ping Connection Server step.

It is quite ridiculous,as it can reach the connection server and get prompted for the self-signed certificate for any of the 4 connection servers, but fails at the "Ping" step.

I also tried, using the IP instead of FQDN even if does ask for FQDN, it didnt work.

I followed the only troubleshooting step provided..., to ping the connection server from the vco server and it does work.

Any ideas ?

Thank you

Alex

[willonit]

I had a lot of the similar issues. I was trying to connect to connection servers that were associated with security servers ad it didn't like that. I had to build an additional connection server and add a certificate to it (used internal CA) with the subject name the same as the external view URL. After that the workflow ran fine. Let me know if you need any more details.

[elgwhoppo]

I'm also getting whooped by this one. Fails at Ping connection servers, even though I can clearly ping the connection server and can curl -k the https page directly from the vCO appliance. Stood up another connection server, placed my third party cert on it. I also had a DNS alias in there for the connection server name, I changed that to an A record so that it wouldn't be resolving to a different hostname internally. Also, I can't even seem to find where it's importing the certificates to when imported via the workflow.

Still no joy in Mudville. Will keep banging on it.

[elgwhoppo]

OK, I think I got it. What's happening in the  "Ping Connection ser" task is being given an array of all the connection servers, which are being populated by the "Is connection serve" task. The problem is, it's just grabbing the URL from the tunnel configuration and throwing it into an array. That name may not be resolvable from the inside network, as it wasn't for the first two in the list in my case, nor will it ever be. Also, I have the same DNS name with different ports for my config as shown.

So to fix this, I duplicated the "Add View Pod in Configuration" workflow, and modified the "Ping Connection ser" task as shown. By modifying the script to start at the third place in the array (or in your case whatever the last number of connection servers is), it only checks the last one in the list and that's the one which worked out OK, since the one that works in my case is the last one in the list. Otherwise you'd have to mess with it a little more.

This is kind of a silly way of determining the admin UI for the brokers if you ask me. I'd probably just have it prompt to have the person fill out the array of administrative UI URLs for each of the connection servers rather than trying to programmatically determine it, then just accept the untrusted or bad named cert.