The steps involved with planning out a VDI implementation are the same as with any large-scale IT project; gathering requirements, identifying stakeholders, establishing milestones, determining goals for success, conducting research, selecting vendors, planning test/production rollouts, gathering feedback, going live and then closing the loop on any residual issues. However, there are some particular challenges with VDI which should be avoided. Here are ten of them.
1. Not planning enough resources
When my wife and I bought our house we were amazed by the size of our walk-in closet, figuring we would never fill up a space that could serve as a small home office. Almost 13 years later we might be able to fit a pair of socks in there somewhere – maybe – but otherwise it’s packed to the gills.
Your VDI environment will be that walk-in closet. Your virtual machines (and users) are going to be extremely hungry for CPU cycles, memory, storage, and network bandwidth. Don’t provision the resources you need today or tomorrow – build out the infrastructure for next year or, better yet, three years from now. Configuration planning guides such as this article on VDI storage by TechTarget.com and this article on VDI networking by Networkworld.com can help.
Monitor how the resources are being used before, during and after the VDI rollout. It’s essential to have a good insight into what your components should be doing versus how they’re actually doing. For instance, make sure you’re inherently familiar with your network traffic, subnets, and the hosts/applications running across these so you’re not reduced to guesswork if issues arise.
2. Not taking advantage of existing resources
Some vendors might (happily) convince you that you have to run out and buy all new hardware for your data center, not to mention a fleet of shiny thin clients for your users. As I said in point #1, you definitely shouldn’t skimp on having sufficient resources, but you should also make do with what you’ve got where applicable. Don’t scrap older desktops in favor of thin client hardware – yet. Let them wear out then replace them. Don’t assume a Windows virtual desktop has to be connected to from a computer or thin client – tablets and mobile devices can also be used (depending on your network and remote access capabilities), which is where your BYOD program can really come in handy.
Need a test virtual environment? Don’t waste space on your production VDI hardware; use older servers if you can. Don’t assume each user will need one license/virtual desktop each; see if they can share these if possible (such as part-time users or employees who work alternate shifts) – of course, your available options will depend on your vendor (more on that below).
3. Not controlling the sprawl
This applies to VDI as well as walk-in closets, of course. Virtualization sprawl is not a new problem, but it can be a particular nasty one in a VDI world.
Standardize as much as possible on virtual images to cut down on the amount of maintenance and upkeep you have to perform for each one. If there are certain applications a group needs perhaps you can consider pushing them out through Group Policy or System Center Configuration Manager (or virtualize the apps entirely) AFTER the user logs in. That will let you rely on a standard “vanilla” Windows image for all users rather than a separate image with those required programs.
If you do employ multiple images, become familiar with user requirements and organize your images by role if possible in a distributed desktop model (e.g., a software developer who needs plenty of RAM, a salesperson who will connect over the VPN and needs snappy response times, an intern who shouldn’t have access to certain applications or the ability to use USB drives, etc.). Keep up on your documentation and make sure to decommission unused virtual desktops such as when users upgrade or leave the company.
4. Not fully preparing staff/users
An old saying claims you can never be too rich or too thin. While one might disagree with either concept, it’s indisputable that your users can never receive enough training or advanced notice as to what to expect with any new rollout. Make sure they’re aware of the ways they can and should use their virtual desktops; whether over the VPN, from their smartphones, with which credentials, how/where to save files and so forth. This is where identifying users as project stakeholders and shadowing their activities to see how you can map these into a VDI rollout will be invaluable.
Any cons to VDI should also be spelled out to users so they will know to inform you about application latency, slow logon times, video difficulties and so forth. During a pilot migration you might want users to log problems on a “VDI issues” page on your intranet, if you have collaboration capabilities such as through Sharepoint, Google Sites, or a wiki.
Don’t go too fast when you deploy VDI; work in stages and circle around after each stage to follow up with the users and get feedback. Get to know their habits and needs. Assuming “no news is good news” is a flawed assumption.
5. Not having a clear understanding about user profiles
You may not have thought much about user profiles (the collection of settings which defines their desktop environment, right down to the wallpaper image of their sailboat) when everyone was on physical desktops, but now your ability to manage and troubleshoot user profiles will be a critical element to a good VDI strategy. You can configure folder redirection or roaming profiles (or both) in a Windows environment to ensure users will have the same settings/access, no matter where they log in.
I personally am leery of Microsoft’s roaming profiles based on direct experience. I found small profiles worked reasonably well, but large profiles resulted in a seemingly-interminable delay at logon and logoff about which I heard numerous complaints (and keep in mind that many users logging into a VDI environment at once will tax your resources even more greatly). Not only that, but I didn’t find roaming profiles reliable; not all changes would be reflected on the synchronized copy, either local or remote. Every environment (and administrator) is different, of course, but the point is that you have to have a clear cut understanding of what settings your users will receive, where these settings are kept, and how they will be deployed – and know that this works as expected. It’s worth pointing out that you can use other products like the Citrix Profile Manager or AppSense Environment Manager.
6. Not having a plan for outages
System outages are a fact of life. If you’ve read up on VDI I’m sure you’ve heard the term “putting all your eggs in one basket” so I won’t reuse that comparison here. I will say that having centralized virtual desktops on a single system is like using one of those handy password manager applications – there’s only one password to have to remember now, but if you forget it then you’re dead in the water.
Use redundant everything. Servers, storage, network connections, network switches, routers, even images. Not only that, but figure out what you’ll do if the VDI environment goes down anyway. Do you have on-site maintenance? Support contracts? Backups? A strategy for employees if they can’t access their virtual desktops (besides “Go to Chili’s and have a beer”)? Here’s where a physical server set up for people to connect to and work from (albeit maybe without the wallpaper of their sailboat) will save the day.
Draw out your entire virtual desktop infrastructure and look at the links in the chain between the components. That’s where your problems - and the answers to those problems – will arise.
7. Not haggling out a license strategy with dedicated professionals
I was going to write out a detailed analysis of the licensing involved with VDI, then realized it will differ vastly from company to company so my facts would only apply to one given segment of the population. Instead I’ll sum up your license strategy by invoking that odd Facebook relationship status: “It’s complicated.” This will be the case whether you’re a small company of three family members or a massive corporation spanning multiple continents.
Licensing requirements are as clear as mud, and may be different for virtual versus physical systems. Check the vendors involved. I’ll say this up front: Microsoft licensing is too complex for the average layperson to deal with even if you leave virtualization out of the mix. A good article here will help put you on the right path out of the fog; however, that’s just the first step. Get in touch with the licensing pros and have them explain it all to you. I’ll admit that it’s about as much fun as walking barefoot over hot coals – in fact, licensing may well be the most unpleasant aspect of your VDI project – but it has to be done. Furthermore, make sure your support agreements will cover virtual environments.
8. Viewing a VDI migration as simply relocating a physical resource to a virtual one
When you go overseas there are certain customs that you won’t necessarily find in your own country. For instance, Russians find it rude if you stand with your hands in your pockets. The “OK” signal is an insult in Brazil. Australians put beets on hamburgers (I like that idea, actually). I’ve heard that weddings in the Caribbean do not involve a best man. You get the point. Virtual desktops aren’t “imaginary physical desktops.” They are software running more software with different rules you should research and be aware of so you should be prepared to adopt different strategies and new mindsets.
For instance, there are best practices for using your antivirus client in a virtual environment which don’t apply to a physical scenario. Symantec provides a download for applying these guidelines to their Symantec Endpoint Protection client, which has specific virtual settings.
You have a user with some weird Outlook problems and you want to run a repair on the software? Well, you could do that, but perhaps that’s a solution better suited to a physical desktop. Can you roll back their virtual desktop to a snapshot from before the problem started (yes, you could use System Restore on a physical Windows box but snapshot work is quicker and more successful in my view)? Maybe it’s better to just redeploy their virtual desktop from the base image; then they’ll get their preferred settings from their redeployed user profile when they log in? The list of possible scenarios goes on.
9. Betting the farm (or your reputation) on cost savings
If you’re elbows-deep into a VDI migration chances are you know by now that it’s probably not anyone’s idea of a dreamy cost savings project. It requires a lot of software, hardware, network capacity and time (which translates to salary dollars). Art Wittman of Network Computing stated in April of 2013, “VDI is too expensive to justify on costs alone.”
The benefits from a VDI implementation are likely going to come from other areas such as improved administrative capabilities, more convenient user access, predictable and controlled environments, and disaster recovery/business continuity measures. If you’ve stated the company is going to save “X” dollars (or worse, vague terms such as “a ton of money”) not having to buy so much hardware on a per-user basis, those words might come back to haunt you. You may see a reduction in power costs but this could be offset by increased network bandwidth, resulting in slower response times. There’s often a “give and take” balance of this sort when it comes to new products.
10. Assuming all your security woes are over
All your data is in the server room (one way or another) and it’s locked up off-limits to everyone except IT staff? You can disable access for a terminated employee by disabling their virtual desktop with a few mouse clicks? Great! No more need to worry about stolen secrets or missing laptops. Let’s relax and forget all those nagging worries about data breaches we keep reading about.
Not so fast. Just because your data is off those physical systems lying around your office (or worse, being forgotten in taxicabs) doesn’t mean you can relax. Data breaches can still take place via the traditional means: social engineering, network sniffing, vulnerability exploits, disgruntled employees, rogue system administrators who fancy themselves Walter White, and so forth. If you pull up a confidential document on the monitor of your thin client, someone else might not be able to save it to a flash drive or print it, but they could certainly snap a picture of your monitor with their iPhone… leaving no trace behind.
The same security rules still apply to VDI. Passwords, encryption, screen locking, disconnection of idle sessions, etc., will never go out of style. Some good tips for VDI include segregating the virtual systems on a separate subnet as well as from each other. Use 2-factor authentication where possible and make sure you stay vigilant in deploying security patches just as you would with physical machines.
Moreover, there are some new approaches to security in the virtual world which are upping the ante in favor of the home team. One such example is identity-aware networking, which a white paper by the Enterprise Strategy Group refers to as “a policy-based network architecture that understands and acts upon the identity and location of users and devices.” Stay on top of the security trends and concerns in order to keep current with the changes.
This is by no means an exhaustive summary of the only VDI mistakes you should avoid; there are more out there both documented and waiting to arise. Don’t assume there will be no mistakes. There will be; it goes with the territory. As with any pitfall you encounter, document and learn from the errors then factor them into your ongoing virtual management strategies. Hopefully your walk-in closet will remain organized and uncluttered with plenty of available space!
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.