Desktop virtualization is a growing trend of measurable outcomes. The steps involved in preparing a VDI deployment are the same as those involved in any large-scale IT project: collecting criteria, defining partners, setting benchmarks, assessing progress targets, performing testing, choosing suppliers, planning test/production implementations, gathering input, going online, and shutting the loop on any remaining problems.
However, there are several specific issues with VDI which should be prevented. Here are five examples.
1. Inadequate resource planning
Before, after, and much after the VDI rollout, keep track of how the services are being used. It’s necessary to know the difference between what your modules should be doing and how they really do. For example, ensure that you are deeply acquainted with the network traffic, subnets, and the hosts/applications running over these so that you don’t have to rely on guesswork if problems occur.
2. Failure to make use of available capital
Many vendors can persuade you that you must think about buying all new hardware for your data centre, not to forget a fleet of gleaming thin clients for your users. As we said in statement #1, you must not skimp on providing enough capital, but you really should also manage with what you have where relevant.
Don’t think that a Windows virtual machine must be wired to a server or thin client; tablets and handheld devices could also be used (based on the network and remote management abilities), which is where the BYOD software can really help.
Do you want a simulated testing environment? Don’t waste bandwidth on your development VDI hardware; if possible, use older servers. Don’t expect that every other user will require one license/virtual desktop; consider whether they can share these if feasible (for example, part-time users or workers who work alternating shifts) – the available choices will, of course, differ on the provider.
3. Not controlling the sprawl
Virtualization sprawl is not a new issue, but it can be especially damaging in a VDI setting. Standardize visual images as much as possible to reduce the amount of maintenance and cleaning needed by each one. If a group requires specific programs, consider moving them out via Group Policy or System Center Configuration Manager (or virtualizing the apps entirely) after the user enters in. This allows you to focus on a single “vanilla” Windows image for all users rather than a different image containing those required programs.
If you do use several files, learn about user expectations and, if possible, arrange the images by the task in a distributed desktop model (e.g., a web developer who requires a lot of RAM, a salesperson who will communicate through VPN and needs quick response times, an intern who shouldn’t have access to those applications or the opportunity to use USB drives, and so on). Maintain the documents and decommission inactive virtual desktops as users update or leave the enterprise.
4. Not preparing staff/users
As per an old adage, you can never be too rich or too thin. Although one will disagree with either idea, it is undeniable that the customers will never get enough preparation or advance warning of what to expect with any new release. Make sure they understand how and when they should and can use their virtual desktops, whether from the VPN or through their devices, what passwords to use, how/where to save data, and so on. Identifying consumers as project partners and shadowing their actions to see if you can translate them into a VDI rollout would be invaluable in this situation.
Any disadvantages of VDI should be communicated to users so that they are aware of device lag, long login times, video difficulties, etc. If you have sharing capabilities, such as Sharepoint, Google Sites, or a Wiki page, you may require users to log queries on a “VDI issues” page on the intranet throughout a pilot.
When deploying VDI, function in phases and loop back after each phase to check up with users and also get feedback. Learn from their preferences and needs. The belief that “no news is successful news” is incorrect.
5. Not having a plan for outages
System outages are unavoidable. If you’ve done some research on VDI, you’ve probably heard the phrase “putting all your eggs in one pot.” Hence, it’s important to compare using unified virtual desktops on a single device to using one of those useful password manager programs – there’s only one password to recall now, so if you lose it, you’re out of luck.
Get it obsolete. Servers, storage, network links, network switches, routers, and even pictures are all part of the picture. Not just that, but consider what you’ll do if the VDI environment fails anyway. Is there on-site maintenance? Contracts for assistance? What for backups?
What do workers do if they can’t reach their virtual desktops? A physical server set up for people to link to and operate from (albeit perhaps without the backdrop of their sailboat) would come in handy here.
Draw a diagram of the entire virtual desktop architecture and examine the connections between the elements. It is where the problems, as well as the solutions to those problems, can emerge.
Conclusion
This is by no means an exhaustive list of VDI pitfalls to avoid; there are plenty more out there, both known and waiting to happen. So, don’t believe that your VDI will never fail or make an error. There would be; it’s part of the territory. As for every stumbling block, log and learn from your mistakes before incorporating them into your current virtual management techniques. Let’s hope, your walk-in closet will stay organized and uncomplicated, with plenty of room!
If you’re looking for professional guidance on creating and executing a successful VDI, consider contacting our professionals at AccOps today.