jroback
Enthusiast
Enthusiast

2106 IOS and Windows Clients default to BLAST - PCOIP only users can't connect.

The latest Horizon client for IOS and Windows  now defaults to Blast over PCOIP, not just for new connections but even for existing saved connections.  I looked through all of the available release notes on the IOS client back to 2006.0  and I don't see any reference to this change.  (If missed it, I apologize in advance, but I did search for PCOIP IP and Blast in all of them)

This is causing a huge issue for some of our users because, for various reasons some of our environments are optimized for PCIOP and setup with only the PCOIP agent components installed, so upgrading their Horizon Client results in them being unable to connect to the environment.  

Additionally, these users following our existing documentation are no longer able to connect using the latest clients.  So our help desk has been scrambling to figure out why end users are suddenly are unable to get their new ios devices connected.   And the users who are able to connect are getting a different experience with Blast than they were with PCoIP, so our help desk is having to work through those issues too.

Part of what's frustrating with this, is it's not even part of an initial logon wizard where the user is prompted to make a choice, they have to stop, mid -logon at the pool selection prompt and go to settings and change from BLAST back to PCOIP.

I understand that we could influence this with specific URLs or with Group Policy settings for the client, but the clients are, by design, unmanaged stations that we don't control, so we're counting on end users to be able to easily connect themselves.  That has always been part of the beauty of the Horizon solution, that fully unmanaged clients could so easily get connected to the system.

I do understand that BLAST is the future and that's where all development is going..... but shouldn't the timing of this be left to the VMware admins, not to VMWare and whenever the end users' device happens to update?  Use of BLAST does require a bit of fine tuning to the environment and testing of the various options.... something I hadn't planned to spend time on this month.   I think VMWare needs to understand that we can structure the timing of server side updates, but with client side updates we have very little, if any, control over who and when they occur, so changes here need to be made very carefully.

This is really puzzling overall, why would the developers do this?  At best is shows a lack of thought into the impact of choices,  and at worst it seems like an attempt to force more people into using Blast over PCOIP without their knowledge or agreement.  

At the very least, before implementing this they could have developed a feature where the system would try Blast first and then fall back to PCOIOP.   That would still be frustrating, because suddenly we'd have users switching to blast when we hadn't planned on it, but at least it wouldn't be breaking the existing infrastructure like the current version is doing when blast is not available.

Am I alone in being troubled by this?

Labels (6)
0 Kudos
2 Replies
mhartstein
Contributor
Contributor

We experienced something like this as well with the 2106 Windows client. Our (version 7.13) pool default display protocol is PCoIP (for a variety of reasons) and, starting with the 2106 client, it just ignores this and uses Blast. 2103 and lower respect the pool setting. If we disable the "Allow Users to Choose Protocol" setting on the pool, it the new client WILL use PCoIP, but this is not an acceptable long-term solution since we do want Blast to be selectable as an option for our users for certain situations.

We opened a case about a month ago and VMware was able to reproduce it and reported it to their "internal teams," but we did not hear anything further.

Hopefully the 2109 (or whatever) client will return to respecting the pool default protocol.

jroback
Enthusiast
Enthusiast

Thanks for your input on that, we'll give that a try, I thought we had our pools set for them to not choose protocol, but perhaps we missed it on some pools, so if that works it's a great workaround for now!

 

Jeff

Tags (1)
0 Kudos