No matter how utopian the idea of VDI, the harsh reality of remote users, and the networks they are working on, can cause issues for VDI delivery and use. Taking into consideration the real world, should be part of your VDI delivery plan, when implementing a solution.
VDI Clients working on overloaded networks, or remotely on WiFi will be prone to dropouts. So how does the drop out issue get handled by VDI? It’s worth knowing, one of the biggest issues, I’ve come across is multiple sessions in use, usually caused by data packet loss, and high latency due to inferior speed connections to the server, a recipe for creating bottlenecking processes. All of which lead to server overload in that, excessive use of server system memory, and CPU by the ghost/dead sessions.
For that reason I’m more in favour of RDWeb RDS service, as it restricts what remote users can actually do to harm your VDI operation in such events.
The advantage of the RDS 2012 system, is that it uses Microsoft’s remote desktop standard technology to connect the VDI client to the server(s) and services.
This means that when a disconnection occurs. The system gives the reconnection up to a max of 20 attempts so as to establish the connection, the user cannot attempt another connection until the reconnection attempts succeed or fail.
There’s a visual warning and display of the reconnection attempts while the “dropped” session awaits reconnection. Should all 20 attempts fail, then the session is flagged as disconnected, and the server housekeeping removes the dead session in the back ground.
At that point the user can pick up another session from the broker server.
Citrix deals with drop outs differently. XenApp/XenDesktop are controlled by the receiver which will basically keep on trying to reconnect the session, no matter how long it’s been disconnected. But, that is where the issue lies with using Citrix ‘without a leash’.
A user may experience a drop out, working remotely, they’d be tempted to fire up another session to continue working, whilst ‘in the background’ the receiver is wrestling to re-establish back the lost connection, when that connection is established it’s presented back to the originating user.
The issue is that if the VDI is being used to address other software on servers, the user has kicked off multiple sessions in other software, loss of the client on their side may not terminate the back ground session on other servers, leaving dead sessions that could be utilising high resource of the other server. So again the latency build up becomes an issue.
Depending on user stubbornness, this could actually easily lead to a crippling overload a server, if session drop outs are frequent. Although Citrix utilises thin wire technology to improve issues on high latency networks, it can cause “nasty side effects” over the network if not configured appropriately.
A correct Citrix setup/configuration should by policy/rules have timeout disconnects set for situations like these, also idle timeouts are recommended. Also raise users awareness of drop outs and what to do, so that the don’t end up causing your IT more issues
RDS makes for an easier solution, without as much configuration for the drop out handling, waiting for the green light from the server before proceeding helps to eliminate problems with dropped connections. While Citrix on the other had requires some consideration in handling such events.
Not that Citrix has inherent issues. I’ve seen customer set ups where Citrix is as solid as a rock within their own network, perfect for delivering a standard painted desktop solution, the issue lies with not planning for remote workers on external networks.