Use cases are critically important in virtual desktop implementations. Identifying and understanding your various use cases will help you make more effective decisions about your VDI architecture — the underlying platform and management technologies, broker, clients, communication protocols (RDP, PCoIP, etc), storage requirements, and so on. Some use cases may be better supported by one system design and set of technologies, other use cases may work better with an alternate design and/or technologies. And no matter how badly you want to be 100% virtual, some use cases may not be well suited for VDI at all. At least not yet.
While the specific details of each use case will vary, all use cases can generally be distilled down to two types — persistent or non-persistent. Non-persistent desktops refresh themselves to their original state on shutdown/startup; they don’t maintain user data, personalization settings, or any other changes. Persistent desktops do, and therefore can be more complicated to work with, often requiring more storage, a potentially different backup structure, and a host of other considerations ranging from how to handle access to local USB devices and printers to user needs for installing personal software and administrative rights. Which is why many institutions focus their VDI projects on non-persistent desktops.
At Menlo, we are rolling out both types of virtual desktops, but decided to start with our simpler non-persistent ones. Or so we thought. It turns out that while our lab and learning space *do* refresh themselves on shutdown/start up (we use a software called Deep Freeze to maintain a steady state in our physical environment), and *do not* maintain user data or other personalization/changes the user makes, they have persistent attributes nonetheless. So they’re *both* persistent and non-persistent at the same time. Oy.
What makes our environment both? While we do expect our desktops to return to their original state, that original state includes a customized desktop background and specific positioning of icons on the desktop, among other things. This isn’t that difficult to do with a physical image, but in a VDI environment this spans both persistent and non-persistent attributes. To make matters even more challenging, some of the software we’re using on our presumably non-persistent desktops requires level of persistence to, well, work properly. Or at all.
These challenges are all solvable — but possibly not in the ways that you think. To manage icons we found a program called RocketDock, so instead of ordering the actual desktop icons we get rid of these with an AD script on log in and replace them with an application that serves up icons in a configuration we set at the application level. Scripting at various levels has also helped address some of our persistent/non-persistent issues. (For the record, and in the interest of full disclosure: our VDI solution is a combination of VMWare View and Unidesk, and we’ve been working with Rob Zylowski and the folks at @UnideskCorp to solve these problems. Their creativeness and brilliance in finding solutions to these challenges cannot be overstated.)
The key, in my opinion, to addressing at least some of these issues is understanding what need you’re actually trying to address, and then figuring out the best way to solve that problem. And I don’t mean the need for ordered icons or specific desktop background — those were just solutions that were designed to meet the need in your current environment. There might be different, possibly even better, ways to solve it in a new virtual environment. Or you may find that because of the differences in the environment, the need simply no longer exists.
Which brings me right back to….yep, you guessed it….use cases. Knowing and understanding them is *key*. Once you’ve figure out “how” you do things for each use case, don’t forget to ask “why”. And when you think you’ve got them all figured out, go back to the drawing board and take a look at them again. And again.
Some guy named Rae... 