There are many benefits to using virtual infrastructure; too many to count. With all of the benefits, however, come a few challenges that I had not expected before becoming accustomed to supporting users of this virtual environment. From a user’s perspective, we want to make the experience as close to the “classic” computer experience as possible. In working towards this goal, we’ve come across a few hurtles that have taken some creativity to navigate.
The underlying issue to some of these hurtles is that, fundamentally, it takes a computer to access a virtual computer. So, rather than supporting and dealing with the problems of one machine, in some cases we are supporting two per user.
One example of challenge in the support of virtual computing is local printer setup. A virtual computer user wants to hit the “print” button and have the document print out to a physical printer located somewhere near their desk. Using the classic model, this would be a simple task. When using a virtual machine to originate the print job, there are many more steps involved before the printer gets the data that it needs to be able to do its job. We’ve learned to overcome this by using remote control technology to take control of the user’s local computer that the printer is connected to and install software and drivers there.
Another issue, as simple as it may sound, is that users aren’t restarting their virtual machines very frequently – if at all. A classic (if not cliché) help desk scenario is that when a user calls with an issue, any issue at all, we tell them to restart their computer and call back if it doesn’t solve the problem. Although this is sometimes a waste of time, it is often a necessary troubleshooting step. Of course, you sometimes get users who will preemptively say that they’ve already restarted, even though they haven’t. Whenever I hear this, I run the command net statistics server which will tell me when the last reboot took place (from the computer’s perspective). In supporting our virtual environment, at first I was surprised at the disproportionate number of people who were telling me that they had restarted their computers that hadn’t. Then I realized that there was confusion as to which computer they were restarting. See, when connecting to a virtual machine via RDP, the usual “Shutdown” button on the start menu changes to “Windows Security”, creating an extra step – and confusion.
What would you do if you went to restart your computer and didn’t see the Shutdown button? Maybe push Alt-Ctrl-Del? In that case, if your physical computer is running windows, it would invoke the Windows Security dialogue for the local PC – so you would be restarting, but you would only be restarting the local machine, not the virtual machine. If it were me, I would reach for the physical power button on my local PC, which of course, would also have no effect on the virtual machine.
In finding ways to overcome this problem, we considered having a “reboot script” run once a week or so, but that could end up with a potential data-loss scenario if a user left an un-saved file open. Luckily, I was able to find a small script that can replace the “Shutdown” button in the start menu. I am in the process of testing this solution on a handful of virtual machines, and if the testing goes well, I will roll this out to all of the virtual desktops.
As to be expected with a system that gives so much power and flexibility, there have been a few unforeseen challenges. And as we move forward in supporting this virtual infrastructure, the challenges are coming to light and being tackled one by one. It has been an enjoyable experience finding solutions to these hurtles in exchange for the power and flexibility that the system returns.
