Ensure software and hardware get along after a VDI platform upgrade

When a VDI platform upgrade gets complicated

For example, take a typical small IT environment with a couple hundred seats of VDI and a dozen or so servers in VMs on the same vSphere platform. This size of business seldom has enough equipment for testing infrastructure changes. It is large enough that there are real consequences if mistakes are made, but it is not large enough to have staff that specializes in parts of the environment; everyone is a generalist.

IT admins are responsible for upgrades to the View components, and let's say in this scenario the IT department needed to upgrade View to remain on a supported version.

The basic version upgrade process for View has a few steps that IT needs to complete in a prescribed order:

1. Upgrade View Composer, usually on the vCenter server
2. Upgrade Connection servers
3. Upgrade Security servers
4. Upgrade agents in desktops
5. Upgrade View clients

The first three steps are supposed to happen over a short period of time, causing a single system outage of a couple of hours. The last two can happen later, sometimes over weeks or months. This tight interlocking of View components makes this kind of VDI upgrade quite a stressful activity.

The problems can come when employees try to use their thin or zero clients back in the office.

After the IT admin takes these steps and everything shows green in the View administrator console, he or she may assume the upgrade was a success. Even testing the virtual desktop connections from home and through the security server may appear to work correctly. But there can still be an underlying issue.  

Hardware and software butt heads

In certain circumstances, the problems can come when employees try to use their thin or zero clients back in the office. Again, take this example: Half of the VDI clients in a company are Samsung NC240 devices with LCD screens and a Teradici Tera1 chip inside. These zero clients are not supported past View 5.1, and will not allow connections to desktops after this upgrade. The cause is a change in the SSL/TLS connections View handles to improve security. The release notes mention the adjustment for the version of View, but they do not say that the change prevents any Tera1-based zero clients from connecting.

With every VDI deployment, each vendor looks after their own part. It is up to the customer to ensure their collection of parts from both the platform vendor, endpoint providers and more work together.

If IT took snapshots of the affected servers prior to the upgrade, admins can roll back to those snapshots. To back out of the upgrade, admins need to roll back all of the View servers and the vCenter server. Of course, that roll-back option means an outage for all VDI users, and undoes all of the VDI platform upgrade work put in to this point. At this point, it is up to management to decide what to do. In this example, to proceed with the View upgrade, the company may need to replace 100 zero clients. If they do not upgrade, then they will be on an unsupported version of View and will not be able to upgrade vSphere.

VDI upgrade lessons learned  

This is why admins must test every kind of access device and network connection before they declare success with a VDI platform upgrade. With View, they should also use the VMware Hardware Compatibility List (HCL). This will ensure support for the zero clients, and every other software and hardware component, after the upgrade. It is also good to always take a screenshot of the HCL page. The HCL can change, adding another View upgrade project that may have a few issues.

VDI platform upgrade complexities can bite. Combinations of hardware that worked perfectly on one release of the product may not work at all on others.