Guest Blog Post By Raechelle Clemmons, CIO, Menlo College
"Don’t sugarcoat it, tell it to me straight." People are always saying that, but almost never when they're expecting delight. The truth is, if you want drastic change, you need to set your expectations high and anticipate discoveries and difficulties along the way. When it comes to deploying and managing desktops, VDI has dramatically changed the way we do almost everything. And while it has already given us so much flexibility in our environment, virtualizing the end user experience and getting IT people to do things in new ways has not been trivial or pain free.
Here at Menlo College, we have a campus-wide VDI initiative based on VMware View and Unidesk desktop layering technology. Ultimately, we will provide students with "anytime, anywhere" access to lab applications and full, personalized desktops for faculty and staff. We will also significantly reduce our operational costs for desktop management because, with layering, we can support all our use cases, deliver applications in a modular way, and reduce calls to the help desk. Our "all-in" approach has been key to our ROI rationale, but different from many other implementations where only a small number of use cases are supported.
Many people have covered the basic lessons on how to deploy VDI, so here I offer some uncommon knowledge — hands-on intelligence that one can only acquire on the bumpy road. I hope it's helpful to others contemplating the VDI journey.
Use cases can be blurry.
Don’t expect users to fall neatly into persistent and non-persistent categories. We found that desktops we treated and perceived as non-persistent in the physical world actually have elements of persistence. But we discovered even deeper fuzziness than anticipated. We have “faculty” users, for example, who are not a homogenous group. Some faculty members moved to VDI and are perfectly happy with it. Others we’re not even trying to move because they do a lot of research with large data sets, and we’re not sure that a virtual desktop can handle the resource requirements.
There are always outliers.
Still other users proved unsuitable for VDI for small but critical reasons. One faculty member was accustomed to plugging in 5 or 6 USB devices, which would sometimes freeze or crash the virtual desktop. Another faculty member runs a lot of DVDs but the virtual desktop wouldn't recognize the DVD player on her “thick” client (traditional PC running a virtual desktop) because it wasn’t a USB device, and a USB player attached to a thin client produced really choppy results.
Video? It depends.
With VDI, there’s also the concern over video and how well it displays. As described above, physical DVDs don’t work well, but streaming video can be just fine. We’ve found it works great with PCoIP, and not very well using RDP as the brokering protocol.
Antivirus software – enough said.
It’s fairly common knowledge that traditional antivirus software doesn’t always work well in a virtual environment. We put a new antivirus program that was not optimized for virtual workloads and found it slowed desktops to a grinding halt. Conclusion: get antivirus that is optimized for virtual desktops or can be reconfigured to run well in a virtual environment.
Different setup, different experiences.
There are also inherent differences between physical and virtual desktops that require some differences in setup, and sometimes result in different end-user experiences. A non-persistent virtual desktop, for example, is truly non-persistent – every time you reboot the machine you have to run through the new Word/Excel/PPT setup processes (you know, where it asks for your initials?), and if you run Firefox, you have to click through the “do you want this to be your default browser” windows. This can be a little frustrating for users, and requires you to use GPOs or some other method to address these items, if you don’t want users to have the “Groundhog Day” experience each and every time they use a virtual desktop. Not so with an imaged computer, where you can run through these things and then “freeze” the computer. (This is also now the case with virtual desktops created by Unidesk, which is a huge help.) This speaks a bit to the idea that a non-persistent computer really isn’t fully non-persistent – in many cases we actually require some small amounts of persistence for settings, printers, and so on.
A need for speed, at what cost?
Depending on your server, network, and storage infrastructure, as well as how you’re configuring your desktops (memory, processors), there may be speed or performance differences between physical and virtual desktops. In cases where we have an entire room or lab of machines, no one has complained about (or possibly even noticed) a performance issue – the user experience is fine. But some of our employees, who are in the process of transitioning over to VDI as their primary computer, seem to more easily notice a slight speed/latency/lag difference with virtuals that didn’t exist with their physical machine. This lag can be exacerbated if the user is the sort that likes to keep a lot of windows open. We believe that there is—and that we have achieved—an “acceptable” performance level and user experience, but each organization will need to determine for themselves what this is, and work with users to recognize that it may be different, but not necessarily bad. Beefier servers and faster storage can improve performance, but you need to be able to invest in the infrastructure.
Management troublemakers.
One thing we love about VDI is that it really simplifies desktop management – especially maintaining and updating software, not having to have different images, etc. But, when there are issues with VDI, supporting it is much more complex than in a physical environment because it touches Active Directory, servers, network, and the VDI management console, among other things. We have occasional issues where one user gets disconnected from her virtual desktop, and another situation where a user periodically tries to log into her desktop and it says it’s busy (but she’s the only one who has access to it, and it’s not in use). We’re troubleshooting these, but they point to two lessons learned: 1) these types of things don’t happen in a physical environment, and 2) the interconnectedness of a virtual infrastructure can make it pretty complicated to determine where the problem actually lies.
Small can be an advantage.
We’re fortunate, when troubleshooting these types of issues, that we’re small enough for our VDI lead to have access across the various systems. In larger environments, where you might have separate departments with responsibility for AD, servers, storage, and the network, troubleshooting VDI issues can be difficult. We heard recently from a colleague who is the VDI lead at a large institution, who said if he creates desktops on Monday or Tuesday they won’t work, but if he does the EXACT same thing on Thursday or Friday, they work just fine. With limited access to the institution’s domain and network, he has to troubleshoot these issues with two other departments, and so far, hasn’t had much success. So he schedules his desktop builds for Thursdays and Fridays, only. It would be comical, if it weren’t preventing his VDI project from being fully successful.
Learn to think differently.
It does take some serious time and work to help both IT staff and end users see the potential for doing things differently. We all get conditioned to do things a certain way, and no matter how kludgey it may be, we're hesitant to change. One year into the project, for example, some members of my team are still connecting users via VPN when they ask for remote access. I finally dictated that we would NOT set anyone up with VPN access, any more. Even when we ARE considering VDI as a possible solution, I find that sometimes that we’re looking for ways that VDI can replicate what we used to do, instead of deciding whether we could do it more efficiently in a new way.
The single best example of this is how we handled a specific class that uses a specialized piece of accounting software. Our first test case for VDI involved this class – last year we turned a physical lab into a virtual one, and enabled the class to run their specialized software in that classroom, or access it to complete their homework via a few virtual lab “seats” we had created at the same time. Students had to use USB sticks to transfer data from their virtual “classroom” desktop to their virtual “homework” desktop, but overall, it worked reasonably well and students were happy to have the anytime/anywhere access that VDI afforded them. This year, we were all set to do the same until we realized – there’s only one class that uses this accounting software. Instead of providing it as part of a lab desktop, we decided to provide each student with his or her own virtual desktop, so that s/he can access the software during class in the lab, as well as from anywhere on campus or at home. This eliminates the need for USB sticks, greatly simplifies the user experience, and takes full advantage of the virtual environment, instead of just creating a virtual lab that follows the same constraints as a physical one. At the end of the semester, we’ll delete the students’ virtual desktops, freeing up the space for other uses.
Expect a "hybrid" phase that is initially more resource-intensive.
We chose to move to VDI in part because we have a small staff, and needed to find better ways to manage and support our desktops. While I firmly believe this will help us do so in the long run, in the short run it has proven to be MORE resource-intensive, not less. This is because we are in between, managing two different environments – physical and virtual – in tandem, and also because of the issues and complexities we’ve experienced. With a small staff it’s been hard to dedicate the resources to really find, troubleshoot, and fix all of the issues one might expect to experience with a new implementation.
So with all the bumps, I suppose the big question is – would I still hit the VDI road, if I could do it all over again? Absolutely, undoubtedly, and maybe with a little less naiveté, but with no less pride. When a user can pull up their virtual desktop from anywhere at any time, or they want a new app and we can assign a layer in seconds, or someone calls in with a problem that used to take hours to resolve but now takes only minutes…well, then we're racecar drivers, we're flying, and there's no better job in the world!
Raechelle Clemmons is Chief Information Officer at Menlo College in Atherton, California. Prior to joining Menlo, Raechelle was the Director of IT Relationship Management and Project Services at California State University, East Bay. Raechelle is a 2009 Frye Leadership Institute Fellow. She holds a bachelor's degree in political science, with an option in public affairs and administration, from Cal State East Bay, and is ITIL v.3 Foundations certified. Follow Raechelle Clemmons on Twitter or read her blog.
