VMware Horizon Community
epa80
Hot Shot
Hot Shot
Jump to solution

Rebooting UAGs

We have 2 UAGs in our DMZ, that are connected to 2 connection brokers via an F5 LTM. Our understanding was a benefit of the UAGs vs. security servers, was that if users are connected using UAG, they will not get kicked if we have to restart one of the UAGs. Essentially if the connection is brokered, the UAG is out of the mix. But that's not what we're seeing. When we reboot a UAG, the person gets bounced. Is our expectation of this behavior incorrect?

22 Replies
epa80
Hot Shot
Hot Shot
Jump to solution

I think that's what we're going to do tomorrow, review the iApp. One line that keeps sticking out to me, that may or may not be the issue, is this one, found on page 21 of the PDF:

In the Virtual Servers and Pools section, complete the following. a. Type the IP address for the virtual server. b. Type the FQDN to which external clients will connect with the Horizon Client.

Item B. in particular. Right now our F5 admin has the DC2 LTM FQDN in there for the DC2 iApp, instead of the GTM. The users will actually use the GTM to connect, but, I guess he went with the LTM FQDN upon creation. He did the same on the DC1 iApp. For that entry, he has the DC1 LTM FQDN, instead of the GTM. I can see where he's going with that thought process, but, might have him switch to the GTM and test.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot
Jump to solution

So in the end, the cert error that we got when enabling tunneling, indeed was a cert mismatch. The cert we were presenting with the F5 (that's also on the connection servers), and the cert was that installed on the UAGs, weren't the same. That's what we get for assuming, and not bothering to check a cert, which takes all of 5 seconds. Ah well, once we put the proper wildcard in place, we are good to go, things running just fine in testing.

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso
Jump to solution

Glad to hear that worked out. It's always the last thing you think to check.

Reply
0 Kudos