However, I question the need to include support for disconnected clients, simply because if you are in a situation where you do not have persistent access to the corporate servers, you no longer have access to corporate databases and client/server application. In that case, it makes little sense to offer a virtual desktop, as productivity is bound to take a significant hit. Users who work in environments without persistent connections are better served by traditional portable computers, with local operating systems and applications.
VDI can be delivered to an endpoint in two fashions:
- Via a persistent connection, where all activity takes place in the data center and just I/O is sent and received from the endpoint
- By delivering a virtual desktop to the endpoint, which runs locally and is then synchronized with a virtual hard drive stored in the data center, often called offline or disconnected mode; a PC with a virtualization-aware processor is required
Determining what endpoints to support and whether to support disconnected devices is the most critical decision that an IT administrator makes. Those choices determine the VDI strategy that needs to be put in place. I've found that the more traditional deployment of running the virtual desktop in the data center and only having to transmit I/O to the endpoint is easier to deploy and manage. It's also the only method that will work with thin clients or zero clients.
In my experience, VDI that supports disconnected users is vastly more complex to configure, deploy, and manage than VDI that uses a persistent connection. Some of the challenges for supporting disconnected users include the following issues:
- Validating the connecting user
- Validating the hardware (and software) capabilities of the endpoint
- Providing the mechanism to deliver the virtual hard drive to the remote endpoint
- Providing the mechanism to deliver a hypervisor to the remote endpoint
- Managing the client itself
- Managing the active virtual session
- Synchronizing the virtual hard drive between the endpoint and the data center
- Supporting disconnected applications (client/server versus local applications)
- Securing the endpoint and the active virtual desktop
By contrast, what you have to do for a persistently connected endpoint is much less:
- Validating the user
- Validating and securing the connection
- Validating the endpoint's software environment
- Validating or installing the thin client software
- Managing the connection
Note that for VDI to work effectively, data centers need to provide costly high-bandwidth, low-latency links to the client devices on their own networks and ensure that offsite users have similar-quality broadband or private network links.
If supporting disconnected users is required, that's a clue that VDI may be the wrong technology choice. It may be best to provide those users with a laptop, netbook, or tablet, and skip the VDI route completely. Perhaps the biggest problem for supporting disconnected users is related to time: how long it takes to provision the virtual desktop and to synchronize data between the client device due to the huge amounts of bandwidth needed to make the technology palatable. I've tested a few synchronization solutions over a fast asynchronous broadband connection (30Mbps upload and 10Mbps download), and I've seen that the initial provisioning of the virtual desktop to a client PC took upward of 20 minutes. That alone may be reason enough to skip disconnected VDI.
Caution: Difficulty ahead in several areas
Regardless of the path chosen, you should still expect to encounter some difficulties while implementing VDI.