Updated: Aug 4, 2022
Last week I have performed an in place upgrade of a Horizon environment that I built a couple of years ago, still running version 5. The reason for it was a need for an update in terms of security on the WAN side of the environment, making it more secure and adhere to the ever increasing security standards. There have been a lot of security measures taken in newer versions of the components, like removing unsafe Cipher suites (Diffie-Hellman, RC4 etc) and removing unsafer protocols like SSLv3. The best option for a more secure environment would be to implement the Unified Access Gateway, which has been available for a while now, but for this customer there was a stringent need for windows based servers.
The upgrade itself went without a hitch. Checking the VMware interoperability site for all components (including the used VMware Horizon clients) revealed no issues up front. The customer was already running ESX 6.0 and has also leveraged both a Teradici APEX2800 accelerator and an Nvidia GRID K1 card in the server. Upgrading the components in the right order also worked fine:
- I prepped their golden image with the newer version of the Horizon Agent and making choices on whether to use USB and other redirection features, cleaning the golden image (see my other post regarding the cleanup script) and making a snapshot in preparation for the recompose. You also have to make sure you install the components in the right way: VMware Tools, Nvidia GRID vGPU windows drivers, VMware Horizon Agent, Teradici APEX drivers, each with a proper shutdown in between. I have seen many times that an incorrect order of installing these components leads to all sorts of weird issues.
- Updating the Composer server, making sure to have the necessary SQL database and login information for the database. This is an in place upgrade and is quite fast.
- The inplace upgrade of the Connection and Security Server and making sure the correct ports were open to be able to setup the IPsec connection between the Security and Connection servers again after the upgrade (watch out for TCP 4002 and look up this document for all the details in regards to the interconnectivity of all Horizon components). This is also an in place upgrade that does take some time, removing the services always seems to take more time than you would expect. Just leave it to it, and it will finish.
- Finally we did the recompose of the desktop as a last step and we got to testing. All seemed fine. The protocol used was still PCoIP, as the concerning customer has a number of Teradici zero clients in place, so we selected the option in the desktop pool settings to not have the user the ability to choose the protocol:
When you set this to yes, the user can actually choose the protocol he or she wants to use to access the desktop, as can be seen in this screenshot. RDP for instance does not need any custom ports to be opened in the firewalls between your Horizon client and the concerning environment, as it is tunneled over port 443, which is usually open anyway, unlike PCoIP, which needs port 4172:
After some initial testing, all seemed fine. The users could access their desktops, though one or two faced the need for an updated Horizon Client, but there were no real issues to be found. Another feature that the customers use is the HTML5 web based access you have to an environment like this. If enabled in the Pool settings with a simple check box, you can use your internet browser to be able to access your desktop session through any compatible HTML5 browser. This setting looks like this:
In older versions (6.1 and before if I remember correctly), you would have to install seperate components on top of the Security and connection servers and also in your desktop to make HTML5 web access possible, but that is no longer the case. Just installing the default components also adds this feature by default, it is just a matter of enabling and disabling. Although it was, until 7.3.2. To my dismay, the following morning the customer complained he could no longer access his desktops through this HTML5 interface and lost this functionality. An unhappy customer and an unhappy Hans were the result. After some searching, this is apparently a difference in feature availability thinking on VMware's part. When you set the pool option for the ability to select the protocol to No, this effectively disabled HTML5, although the HTML Access: setting is still set to Disabled.
Takeaway from all of this? If you are implementing Horizon 7.3.2 and want to grant the users the ability to access the desktop through a HTML5 compatible browser, you will need to set the Allow users to select protocol setting to yes, otherwise it will simply give you an error message, instead of a browser based desktop.
VMware has reported on the forums that this choice will be reverted in newer releases.