Mobile workers who use virtual desktops to securely connect to the data they need for work may run into some remote...
connectivity problems, but they're solvable.
"Road warriors," or mobile workers, are the employees who work remotely and in unconventional locations for a significant portion of their business lives. Anyone who has ever worked remotely knows that trying to access corporate networks from the far reaches of the world can be quite a challenge. Add the additional security concerns associated with having data stolen from devices in foreign countries, and you have a situation where virtual desktop infrastructure (VDI) is a practical solution.
This isn't to say VDI is without its remote connectivity problems, however. Have you ever gotten one of those frustrating messages that say, "Your remote session has ended due to network issues"? Yeah, it's happened to me too. Take a look at some of the most common remote connectivity issues to be aware of and some ways to deal with them.
When workers use virtual desktops, they have to connect back to the corporate network. But some countries and hotels block certificate-based virtual private networks (VPNs), which makes it impossible for employees using connections such as Layer Two Tunneling Protocol to get back to their virtual desktops.
For this reason, many companies employ a multi-entry VPN system -- one entry with the certificate and one without it -- with just a username and password as emergency backup for authentication. IT departments should not use this option as standard practice because it is less secure than certificate-based authentication, but it's helpful to have the option available for workers who might need it.
From an input perspective, one of the disadvantages of using VDI is that it is slower than a physical system. This frustrates some contact center workers, who are among the most frequent virtual desktop users. High-latency connections can exacerbate this issue significantly. Employees will find themselves typing information into the system, but it may not show up until ten or fifteen seconds later. For regular typists, this means going back to make corrections frequently. For fast typists, parts of or entire sentences disappear as the system tries to catch up. You can imagine how frustrating this can be for users.
The best way to address this problem is in planning for deployment. Do a network assessment at the outset and make sure you thoroughly test latency with users in various scenarios. Otherwise, you will likely find yourself reconfiguring your network routing tables or replacing network lines later on. If you're responsible for this aspect of your infrastructure, you understand how difficult a task that would be.
Another remote connectivity problem is intermittent connectivity, also known as bouncing connections. This typically happens in less developed countries, and to the average user, it usually manifests itself as getting kicked off of an application. There are two options to combat this: VDI save states and application autorecovery.
More on remote connectivity problems and solutions
How secure is RDP?
Using remote access VPN security to secure your intranet
Get cheap, secure remote access with SSL VPNs
VDI save states have become increasingly popular over the last couple of years as more shops have run into bouncing problems. Though originally designed to address resource consumption from idle virtual desktops, you can easily adapt them to be a safety measure for connectivity drops too. Check with your vendors and you will find instructions about how to set this up and tune it to your needs.
Application autorecovery is the other option. It allows you to address bouncing at the application level. While it is more useful in productivity or Web-based applications, it comes with some of the major ERP vendors' products as well. Application autorecovery is based on the principle of saving the data that the user has entered during a session, which allows them to come back to it if their connection is cut off. If you've ever tried to enter a long order only to be foiled at the last click and have to start all over again, you know how useful autorecovery can be.
These are only a few of the many potential considerations you must take into account when thinking about deploying or using VDI. As you can see, many of the solutions to common remote connectivity problems rely on your network infrastructure and architecture, so don't try to deploy VDI in a silo. Your network can be your greatest asset or your greatest liability in a VDI environment. Be sure to include your network specialists in your VDI planning so they can help assess your resources and sizing before you deploy. You should also work with your user community to understand when and how they will use virtual desktops. Each situation is a little bit different, so there are no hard-and-fast recommendations, but spending time collaborating at the outset will save you from many headaches and user complaints later on.