Should you Convert a Desktop to a Dumb Terminal?

You’ve rolled out a shiny new VDI solution, but most of your user base is on good physical desktops that don’t need replacing… and that you don’t have the budget to replace with thin clients yet.  What do you do?  I think that most VDI rollouts get to the point where they’re asking that question eventually.  There are two main answers that you get (ignoring the “replace them anyway!” opinion).  You can run your View Client as an Application on the desktop or you can run it as the desktop’s Shell.  In my opinion, they are both viable solutions... but they both certainly have drawbacks.  Let’s talk about the Application option first.

The View Client is an application, just like any other.  That means that you can place a shortcut on the user’s desktop and, after they sign in, they can start it and log in to their VDI Desktop.  If they user needs to get out of their VDI Desktop, it’s very obvious that they can simply minimize the window (or even close it).  This fact is both a good thing and a bad thing.

It’s bad because we want the users to actually use their new desktops; if it’s easy for them to minimize it and get to their old, familiar environment, then they will do that.  Why?  Well, people are creatures of habit, and as long as their old desktop let them do their work, it was good enough… and it’s really hard to get people to change from “good enough”, especially if you’re trying to get them to change to something unfamiliar (like from an XP physical desktop to a Win 7 VDI Desktop).  Even if the OS isn’t changing, the very fact that they are logging in by a different mechanism (or needing to run an application after logging in, before they can run their *real* applications) is change, and people don’t like change.

It’s good because it makes what is happening very clear to the user.  Think for a minute about what’s going on on that desktop – it’s Windows on Windows, from that user’s perspective.  When they hit Windows+L to lock their workstation before lunch, they are locking both their VDI Desktop and their Physical Desktop.  They come back from lunch, hit Ctrl+Alt+Del and unlock their physical desktop… putting them back into a windows environment where they have a window to their VDI Desktop that is also locked.  That is a cue for the user – they have successfully unlocked their physical workstation but must unlock their VDI workstation.  It’s annoying for them (having to do it twice), but at least they understand it.  Compare that to our other option for repurposing a physical desktop – converting it so that the View Client runs as the desktop’s Shell.

A bit of searching around will reveal a VMware Blog post on just that topic.  I’ve followed a slightly improved version of those procedures… and in my experience, it leads to a fair amount of user confusion.  The problem is that you have 2 instances of Windows running for the user, but it appears to be only one.  This means that when the user issues a windows command at the keyboard, such as Ctrl+Alt+Del, the Client instance of Windows and the Virtual instance of Windows will both catch it.

It’s really confusing when a user hits Windows+L to lock their session.  That command will lock both the Client and Virtual desktops, as you’d expect.  When the user comes back, they’re greeted by a screen that says “Press Ctrl+Alt+Del to log in”… which they do.  Then, since there’s no shell running but the VDI Desktop, they’re presented immediately with a screen that says “Press Ctrl+Alt+Del to log in”.  They just did that!  Well, they hit Ctrl+Alt+Del again, and the Client (which is already unlocked) catches it and brings them to the “Lock your computer…” screen.  That’s not what they were expecting – they were trying to log in!  Even worse, if the user did not click on the VDI Desktop before hitting that second Ctrl+Alt+Del, the VDI Desktop didn’t even receive the command and so when they cancel out of the “Lock your computer…” screen, they’re right back at the “Press Ctrl+Alt+Del to log in” prompt.

Some education about what’s happening (as well as a note about the ever useful Ctrl+Alt+Ins keyboard shortcut) can mitigate this confusion, but the fact of the matter is that the user will need to unlock both physical and virtual desktops.  Users do not like this.  So, what to do?

Administrative Templates to the rescue!  If you look on your Connection Server, under your C:\Program Files\VMware\VMware View\Server\Extras\GroupPolicyFiles directory, you'll see a bunch of Administrative Templates.  Under the PCoIP Session Variables template (pcoip.adm), you can make a few tempting changes.  The one that I end up using is "Disable sending CAD when users press Ctrl+Alt+Del" - this doesn't completely resolve the user difficulties when using a Windows box as a Client, but it helps.  It means that when they press Ctrl+Alt+Del, it will only be picked up by the Client system.  There's a very tempting "Use Enhanced Keyboard..." option that will redirect special key combinations to *only* the VDI Desktop, but if you read the description it says that it needs to be run under Elevated Privileges on a Windows 7 box, making it difficult to effectively deploy to end users.

I think that the best user experience comes from using a terminal.  Failing that, running the software on a fat client as an application is more intuitive than trying to convert the fat client into a dedicated VDI system.  There is a method of fat client conversion that I haven’t played around with yet: installing Ubuntu on the client desktop and setting it to launch the View Client.  I’ll post about it if I get a chance to try it out, but I’m hopeful that getting Windows off of the client device might resolve some of the confusion that I’ve seen with converted desktops.