How-To
Tips for Managing VDI, Part 2: Component Best Practices
In a previous article I looked at what has happened during the last two years with regards to virtual desktop infrastructure (VDI), how remote working has become prevalent and explained what VDI is. In this article I will dive into specific components and some best practices around them.
In most cases the VDI client is the only piece of hardware that an end user interacts with. To greatly simplify it all, a VDI client acts as a display for a virtual desktop and passes a remote user's keyboard and mouse interactions to it. When VDI first came out, we had a slide that showed the client with a long cable, a very long cable attached to a virtual machine to explain this.
In actuality VDI is far more complicated. We need a highly optimized protocol to pass the desktop to the client and refresh only the portions of the screen that change. We need to pass back not only the user's keyboard and mouse interactions with the desktop but also local devices such as printers, scanners and USB drives that are attached to it. And we need to do this in a secure fashion but also in a manner that is simple enough that even the most non-technical employee can use it.
On the hardware side there are clients that cost less than $100 that use Arm processors. These devices are fine for task workers that only use one or two applications. For power users in the M&E, STEM and financial markets there are VDI clients that cost thousands of dollars but can support four or more 4K monitors. There are, of course, a wide variety of VDI clients between these two extremes. Most VDI implementations also support using mobile devices and web browsers.
On the software side, VDI vendors supply native VDI clients that run as applications on existing Windows, macOS and Linux systems. This makes it extremely convenient and quick to onboard new VDI users. This assumes that the user has a system and is willing to use it for work purposes. Although VDI clients have proven to be very secure, the OS that they run on -- especially on personal systems -- might not be up to corporate standards.
Most standalone VDI clients come preinstalled with a bespoken OS and the common VDI client software preinstalled on them. Furthermore, many have write-only filesystems as well as other security features built into them.
Best Practices Goals -- End User Experience
One of the first issues that we saw during the early days of the pandemic was with the consumer grade equipment that users were using. From a security perspective, some of the equipment did not support the latest Wi-Fi authentication methods. This allowed unsecured communications from the endpoint device to the router that could be eavesdropped on.
On the performance side, many times they suffered from weak Wi-Fi signal strength as well as latency and bandwidth issues. We had tools that could measure and monitor the infrastructure side but on the client side we didn't have the tools in place to measure them. Hence, we wasted a lot of time investigating the infrastructure rather than the client.
Since then, we have come up with sophisticated tools to monitor endpoint devices and look at VDI in a holistic manner.
Some of the more sophisticated monitoring and managing tools can automatically drop unsecured connections, alert the users or help desk when they are having Wi-Fi or networking issues.
Logon Duration
Very few things are as maddening as the wait you have while your system boots up. When booting and logging on hundreds of processes take place.
Overly long log-in duration was reported as the No. 1 end user problem according to a recent poll. Another study showed that the average logon duration for over 1,500 companies was under 30 seconds. If users are seeing over a 30-second response they need to be investigated. The 30 seconds is just a benchmark. In highly critical areas such as healthcare, even 30 seconds is too long as a patient's outcomes can suffer. In other industries a longer log-in time may be acceptable if there are a lot of activities such as security checks, drives being mounted and so on being done in the background.
The important thing is to know what is going on during the log-in process so you can make informed decisions about them and/or optimize the experience for the users. There are tools that break the process down and display this information in an easy-to-understand manner.
The log-in process can be broken down into different phases. Each of these phases can have issues that can cause a slow log-in.
During the Prestart up phase, authentication, and entitlement can be slow if the authentication server is overloaded. This is not seen on the client or the virtual desktop, hence a holistic view of the VDI environments is necessary.
During logon, user profiles especially roaming profiles can greatly slow down systems.
Many VDI systems have ways to perform application abstraction (such as VMware App Volumes). These programs can greatly improve the management of users' desktops and decrees the cost of VDI, but if they are not configured correctly, they can cause slow log-ins.
In the screen capture below, in the lower right, is the output of a script and shows that the Group Policies are taking 51 seconds to complete. On investigation I found that we were making a bunch of unnecessary calls. Once they were eliminated it dropped down to less than 20 seconds without any loss of functionality or security.
Below is a table for a few of the other processes that take place and that can cause slow log-in duration.
What to Look For |
Pre-Startup |
Logon |
Shell Start |
✔ Authentication |
✔ User profiles |
✔ Startup applications |
✔ EUC-VDI Broker |
✔ Group policy |
✔ AppX & Active Setup |
✔ Protocol connection |
✔ Logon scripts |
✔ End user management |
✔ Published Apps |
✔ Print & driver mapping |
✔ Scheduled tasks |
✔ VDI Client |
✔ Client-side extensions |
✔ Startup scripts |
|
✔ App Volumes |
|
|
✔ FSLogix |
|
As a side note, one of the early problems that VDI had was anti-virus (AV) storms where all the virtual desktops would kick off AV software at the same time causing an I/O load on the disks and CPUs, often making desktops unresponsive. This issue was quickly identified and AV companies came up with techniques to overcome them so they are no longer an issue.
Response Time
Another niggling issue for users is slow response time, that is, the time that you click an object or type on the keyboard and the time that the action associated with it takes place.
In the past it was very difficult to quantify slow response and we had to go on just how a user felt with regards to response time. With Windows 10, version 1809 or later and Windows Server 2019, Microsoft included the User Input Delay counter metric. This measures how long the user response to an action takes. This counter works for both local and remote sessions, providing a quantifiable way to measure an end user's experience.
Using these counters when we make changes to something in our environment, we can quantify how they affect performance. In one case an admin I know was able to justify new VDI servers by showing how additional memory decreased the input delay and increased end user satisfaction. These counters are very important in critical environments like healthcare and finance.
The maximum time a user can tolerate before getting feedback is shown in the table below.
What to Look For |
Response Times |
✔ 0.1 second -- click response |
✔ 1 second -- needs feedback on progress |
✔ 10 seconds -- loses attention, moves on to another task |
In this article we discussed factors that affect the end user's satisfaction and what needs to be monitored to ensure that they have a good user experience. This is very important as nothing will stop a VDI implementation faster than users having sub-adequate performance. In my next article I will look at some of the newer techniques that can be used with VDI.