Forum Discussion
APM :: Version 13.1 and VMware View
This 13.1 upgrade (from 13.0) is causing us a lot of grief. I have a ticket open with support, but the engineer said he was already on a call and would get back to me. This was at 10am yesterday. Good times.
It seems F5 changed the way VDI works and it has broken a lot of people within our organization. Instead of being prompted for the Horizon or HTML5 client, it tries to connect automatically using previously saved information (via cookie I assume - however since this is a new upgrade, there isn't anything previously saved). It looks like it’s using bad data to do so post upgrade (cookie that is not formatted in a way that correctly assigns the connection method or something like that).
For many users, clicking the resource button within the webtop (vmware view profile assigned) does nothing. The user clicks, and nothing happens. Wait for a bit, click it again, still nothing happens. For others, it presents a blank box where the Horizon/HTML5 options were to be presented originally. If the users clear their cache, logs out, and then logs back in, then it will present the connection selection again (Horizon vs HTML5). So at least nobody is down at the moment and we have a workaround.
However once they choose an option above, it will then save that setting going forward. If they want to switch, they have to remember to adjust the VDI settings separately:
We have a number of users that like to use each one independently and choose each time... like it used to be. They don’t want the F5 to presume the selection (myself included). Prior, if you clicked the vmware view resource, a pop-up would be displayed presenting Horizon or HTML5. Now you have to make sure the above setting is what you want BEFORE you do so. Is there a way we can revert this behavior?
VPE is configured to allow selection (same as prior):
In addition, since the upgrade, the HTML5 client no longer works. The HTML5 connection option tries to connect to the public IP address rather than the FQDN. Still trying to figure that part out... but it obviously then breaks the session. This is a big problem for users that are off site and cannot connect using the Horizon application.
As a workaround, I assigned a view proxy which points to the FQDN of the VIP (same one they used to connect in the first place). This was not required before the upgrade.
Minus points F5.... minus points.
We had a similar issue and it seems 13.1.0.6 may have corrected it.
- Josh_Thow_46579Nimbostratus
Hi Ryan, I just closed off a support case today with a similar issue for HTML5 Blast on BigIP 13.1
We also got HTML5 Blast working by changing the view.proxy_addr session variable, we actually deleted it entirely which again directs the Blast protocol to initiate to the FQDN name of the VIP (it keeps using the running browser session URL).
We are running "unsupported" versions (old View iApp 1.2, BigIP 13.1, Horizon 7.3.2) so I assumed our Blast issue was due to changes in how the iApp/BigIP VDI code interacts during the setup wizard. I haven't got to test a new deployment of 13.1 with iApp 1.5.3 yet.
Supported versions are at https://support.f5.com/csp/article/K15041
Is your AP carried over from a previous BigIP/iApp version, or did you recreate the APM on version 13.1/iApp 1.5.3?
Cheers, Josh
PS. During the 12.0 to 13.1 upgrade, we also had to manually add a /Common/vdi{} line before the BigIP config would load.
- Josh_Thow_46579Nimbostratus
Also to work around the VDI settings "VMware View Policy" object, you could add a manual decision box to ask the user for Client/HTML5 and then force the Policy in duplicate VPE branches. Nasty, but it would work.
- JWhitesPro_1928Cirrostratus
We had a similar issue and it seems 13.1.0.6 may have corrected it.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com