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... 
We are using non-persistent desktops in most cases and using AD for personalization. My wife as assigned a VDI terminal at Sandia and they are doing the same thing.
@Jeff, We’re using AD for some things, too, but not everything can be done there (or, in some cases it should be able to be done there, but just doesn’t. seem. to. want. to. work. !*$!#). And not everyone uses AD. In any case, the point is that you really, really need to think about the use cases at a granular level, because different needs will require different solutions.
Well the reality is that VDI is not a solution for all users. I think it seems appropriate to users that use a limited number of applications (MS Office suite, for instance) and whose job does not need specialized applications. I am not sure VDI is appropriate for higher level professionals, IT, some faculty, etc. You need to use your use case scenario to evaluate that as well. VDI is not for everyone. Some of the literature I have read is that it is most appropriate for “transactional” users. Those users whose jobs are primarily routine. That alone still saves significant cost of ownership for any entity. I, for example, am a lousy VDI use case because I have a dozen utility applications I run that I paid for myself that I don’t want to live without (and won’t).
“Oy.” That sums up my VDI project. I was charged with implementing VDI within my first month of accepting a position with this company. To help supplement my knowledge gap (I know server virtualization – but desktops is a more complicated can of worms) I brought in 3rd party consultants to help drive the project.
So as you touch on, the peril of having someone new to the company (myself) and a 3rd party drive a project of this nature is that neither of us has a concept of what the true needs of the company are, how the platforms are working together, and why, why, why they are doing whatever they do!
Another challenge: we are trying to use ThinApp as much as possible – which is tricky when the company’s production platform is standing on legacy and home-grown/patch-worked software.
I also have an Office 365 initiative in front of me. There’s a whole other dimension at work here: How will persistent vs non-persistent desktops handle limited visibility to the Exchange server?! Your guess is as good as mine.
I’m starting to understand why I the articles I read in CIO magazine talk about 2-3 year timelines for implementation of VDI.
Great short post on VDI. I’m an independant consultant that is working with a client right now to figure out how and when to deploy VMware View 5.0. Within this decision lies the choice of offering persistens or non-persistant desktops, in my opinion is should be non-persistent 100% of the time. With the availablitiy to save documents to the network drive, there’s no need for local storage, and people shouldn’t be saving to the C: drive anyways. Great post, check out my blog when you get a chance, I was at VMworld too.
-Greg
vDestination.com
Great blog, Greg. Thanks for sharing! As far as 100% non-persistent goes, in our experience it’s just not feasible. Even in “true” non-persistent environments like computing labs, there can be elements of persistence that are needed to maintain printer mappings, eliminate the groundhog’s day effect of software (ie, having to go through the start-up screen/processes for each software), and in some cases, to support specific software that require elements of persistence. When you move beyond those environments to office workers, there are few who do not expect to have the same background, customizations, settings, and other elements of personalization each and every time they log into their computer.
Thanks for writing this post (and this whole blog)!
Having successfully virtualized our server farm, we hope to soon pilot a virtual desktop. Interesting to read about the difficulty in “pre-customizing” a Windows desktop. That will be my challenge as the “desktop guy”. It’s important to me to make things convenient and transparent for my various user constituencies and the physically imaged standalone desktop has been amenable to that treatment. Thought Windows 7 made it more difficult than ever (we skipped Win 6- Vista).
I like your framing of use cases (and the “granular” examination thereof) as a key consideration. The small collection of user communities, faculty, staff, students, all have different needs. At least we have going for us that all our users are getting more savvy each year as software also gets better. Nice symbiosis isn’t it? Sure would be great though if that upper layer (yeah, Active Directory) consistently did what it has promised.
David,
You’re welcome — I’m glad that you’ve found my blog useful! 🙂
This particular post about use cases was written fairly early on in our implementation. We’re much further along now and have discovered even more quirky use-case examples. Groups like “faculty” aren’t as homogeneous as we would think/hope/like, and as a result we’re making case-by-case determinations about VDI for members of this group. Other groups are much easier to apply a common solution to, across different users.
I’ve written more about this discovery, as well as other “ah-ha” moments in a blog post on VMware’s site. Check it out, if you have a moment.
Good luck with your VDI pilot!
Rae
Hi Rae,
I’m employed at a community college and am responsible for creating virtual desktops. We’re using Unidesk and VMware View 5.1 and I hope you don’t mind me asking some silly questions from time to time on here. I’m creating some pilot vms for our library and am wondering how you forced students to log on to the vm. I’ve deleted all desktop icons except for the view client and used kiosk mode settings for the taskbar but the start button is still active. Did you start out with a local OS? If so, how did you force students to log on to the virtual desktops?
Hi Mona, I’d be happy to answer any questions you might have! Feel free to also just email me directly (first.last at snc.edu), rather than posting to the blog and waiting for a reply. I’m more likely to respond sooner to email. 🙂 We did use a combo of thick and thin clients at Menlo when we started with VDI. I don’t remember all of the details, but basically we stripped the OS down so the ONLY thing you could do was click this HUGE View icon in the middle of the screen to load the VMs. It also was the only option in the Start Menu, so you really had no choice. I think we used a combo of group policy and Deep Freeze to lock down all other functionality. In other cases, I know we had the machines auto login all the way to the virtual desktop, but I can’t remember if we did that on any thick clients, or only thin. Here we’re only running this on thin clients so far, but will start working with thick this Fall. I think my team has a strategy for addressing this, so our system admin might be a good person for you to start sharing experiences with. If you email me, I’d be happy to share his contact info. Good luck with your VDI pilot!