VMware Horizon Community
epa80
Hot Shot
Hot Shot

Issue With GE/CPA on 7.3.2

We are in the middle of an upgrade from 6.2.0 to 7.3.2. With VMware's assistance, we leapfrogged first to 6.2.5, tested fine, and then went to 7.3.2. Our environment prior to this was a dual data center VDI environment with CPA/Global Entitlements set across both. We are using F5 as our load balancer, with all clients hitting a GTM, that has 1 LTM from each of our data centers behind it. Those LTMs have 5 brokers from each side behind them.

We marked down the LTM in DC1 so no new clients would go there, and proceeded with the upgrade there. Composer servers first, then brokers, then security servers. No blips no errors, went pretty well. Upon everything being on 7.3.2, we started testing from our thin client, Wyse thinOS terminals. That's when we started to see issues.

We would specify a specific DC1 broker or the DC1 LTM itself (DC was the 7.3.2 side), authenticate, be presented with out DC1 Globally Entitled pool, and we would get an error connecting. Either desktop unavailable, even though there were available desktops, or we would get unable to launch desktop due to a communications failure.

What was odd was 2 things: if we instead picked a pool that was globally entitled over on DC2 (still at 6.2), even though we were coming in through DC1, it worked. The other thing was when using a Horizon windows or Mac client, we couldn't get this issue to happen. I did try 2 different Wyse thinOS models, both with an older PCoIP client version and newer, but no luck. The Wyse thin clients are 95% of our endpoint devices accessing the VDI world.

Apologies if this is all over the place, it's quite a confusing issue. All of the testing scenarios I mention here we have done numerous times before when the environment was 6.2, and they were always fine.

We do have a ticket open with VMware (or one is being opened shortly). I'm wondering if they come back and tell us to hop to 7.4 (which specifically mentions a resolved issue of connecting across CPA when the environments are different versions).This would be frustrating, since in our discussions, it was brought up we'd be in this state of in between builds, and it didn't get identified as a problem. Not to mention 7.4 is barely out the door.

I'd be glad to clarify this mess of a post if anyone has any insight/questions that  could help us out. Thanks in advance.

Reply
0 Kudos
2 Replies
alsmk2
Hot Shot
Hot Shot

Are you using the Horizon View iApp in F5? If so, have you checked that View 7.3.2 is supported on the version you are using.

As far as I am aware, only the very latest Horizon iApp is officially supported with 7.3 (f5.vmware_view.v1.5.3), though we do have a site working at 7.3 that uses v1.5.1 happily.

Also, slightly off topic, but if you use APM then you probably haven't noticed yet is that HTML5 access does not work on 7.3 if you don't update your pools to allow users to choose their own protocol. For F5, you also need to add an additional irule to your VDI https virtual servers (or update BIG-IP):

https://support.f5.com/csp/article/K65620682

BIG-IP APM with Horizon 7.x HTML5 gets a Hotfix For Updated Code

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

It turns out our issue was our Imprivata SSO. The appliance was still pointing us to our GTM (which is pointing to our 6.2 environment). We were testing via our thin clients being directly pointed to DC1, where 7.3.2 got installed. So, while we thought we were going to DC1, Imprivata was taking over and saying nope, let's use the GTM.

So that nailed it. When we got brokered via DC2 6.2 brokers, and attempted to go to a 7.3.2 pool, we errored out. Definitely the issue that 7.4 resolves. Luckily we have a path to continue and get the upgrade in without any user impact, but, lost some hours working this out.

Reply
0 Kudos