Virtual desktop infrastructure (VDI) is rooted in an idea from the beginning of computing: green screen terminals talking to applications. With VDI, thin client software running on a laptop, desktop or mobile device becomes a window onto an application client, web browser or desktop operating system (OS). The real application client is running in a virtual server in a data center somewhere, not in front of the user. All you need to join in is that thin client software. It seems counterintuitive: Why would you dramatically increase your servers and give every user another layer? Well, because deploying VDI comes with huge benefits, such as:
- Improving accessibility and security at the same time by completely isolating apps from end-user mobile devices and desktops, while still allowing users to easily connect to those apps
- Reducing the burden of buying, managing and supporting desktop computers by replacing them with thin clients or mobile devices such as smartphones and tablets
- Controlling software costs closely by purchasing and distributing licenses only to active end users
- Becoming more responsive by leveraging VDI to quickly add server and client resources as needed — and remove them when they’re unnecessary
Some organizations are using VDI to deliver particular apps to end users — apps that require a special thick client, have special licensing or are too heavyweight to install on every workstation.
Other organizations are doing away with client workstations entirely, delivering Windows desktop services via VDI, letting end users have access to “their” Windows desktops through any device they want.
Whichever path you take, implementing VDI can look like a big project, but it’s actually easy with the right plan. Follow these seven basic steps, and you’ll be delivering VDI capabilities quickly:
- Decide the scope of your project
- Pick your VDI vendor
- Set up and scale up your hypervisor server farm
- Review security
- Bolt everything into place
- Distribute clients and train users
- Sit back and enjoy the savings
Step 1: Decide the scope of your project
A VDI project can have a huge scope, but to get started, you have to narrow things down. The fastest way to focus is to decide whether you’re doing a full desktop replacement or just using VDI for specific applications.
Generally, a full desktop replacement requires more work, because you’re replacing each of the business’s PCs with a virtual desktop. Performance and storage are hard to estimate, but there are some shortcuts. For example, some cloud service providers are offering desktop as a service solutions (Amazon calls this Amazon Workspaces) that can scale up and down quickly and shortcut the amount of work required to manage the desktop “golden master” image. But there’s also an additional cost in connecting your data center and Active Directory to the service provider’s cloud, and you’re trading initial capital expenses for increased operational expenses that will never go away.
The alternative to full desktop replacement is to start with a few specific apps that you want to move to a VDI environment. In this case, calculating performance and storage requirements is simpler because you’re not shifting every Windows desktop to the cloud; you’re just delivering specific apps to specific end users.
Your scope here won’t limit the project; you can always expand your VDI later. But focusing on one use case with a clear and defined scope will speed your path forward.
You can use this initial VDI scenario to start capacity planning — a particularly important part of VDI projects. How many users will be using this service simultaneously? Is your internet and in-building network infrastructure prepared for this new load of client-server communications? And, more importantly, does your data center have the server, storage and network capacity? We’ll dive deeper into that question further on.
Step 2: Pick your VDI vendor
You may already have some experience with VDI technology, using remote desktop connection (RDC) clients to connect to servers in your data center. The display technology behind RDC and VDI is fundamentally the same, whether you’re connecting to a single server or handling a farm of 1,000 virtual workstations.
The main difference between using RDC to talk to a server and a true VDI solution is the scalability offered by that simple connection between client and server. This infrastructure — often called a connection broker — is responsible for managing the user portal, handling authentication and authorization, starting and stopping virtual machines that serve desktops and applications and setting up connections between the users and the virtual desktops or applications.
Different VDI vendors use different terminology, but it’s important to understand the difference between the connection broker and the VDI servers themselves. The connection broker is overhead: It’s all of the pieces that are used to set up, report on and manage the VDI connections. For all but the smallest of VDI deployments, the pieces of the connection broker will themselves consume a number of virtual servers.
The VDI virtual servers are what actually run the application or desktop on the user’s behalf. If you’re using VDI to virtualize your Windows desktops, for example, then you need a VDI virtual server for every simultaneous user. You can pack those virtual servers into physical servers running a hypervisor — 10 per physical server, 20 per server, whatever the performance data sheets say for the hardware you have available. But each real user’s VDI client is talking to a unique virtual server somewhere in your VDI deployment. We’ll talk about these physical servers and their hypervisors in Step 3.
When you select your VDI vendor, you’re focusing on that first part: the connection broker. The two big names in this realm are Citrix’s Virtual Apps and Desktops and VMware’s Horizon. Amazon (Amazon Workspaces) and Microsoft (Azure) have also entered into the VDI game, leveraging their reliable and super-powerful data centers to handle both the connection broker piece and the hypervisor piece. Other smaller competitors, including Parallels and Nutanix, may also be able to meet your needs.
Decide whether you want to run the VDI servers themselves in the cloud. For some IT managers, VDI means moving application clients or virtual desktops out of people’s desks and into their own data center. Often, this is for security reasons, or because the app and network topology require users to be “inside” the corporate network for things to work properly.
But that’s not always necessary. If your apps have all been moved to the cloud and you have little or no VPN requirement, then you have the option to run VDI inside the cloud as well. You may still choose to do an on-premises solution with Citrix or VMware, but you have more vendors to consider if the VDI servers can be in the cloud, too.
Step 3: Set up and scale up your hypervisor server farm
If you’ve chosen a cloud service provider such as Amazon or Microsoft, then there’s not much to do here, because these providers deliver both the connection broker and the physical hosts for the VDI virtual machines, using their own technology.
But if you’ve decided to do an on-premises (or hybrid) solution with servers in your own data centers, you’ll have to select a hypervisor and scale it up properly.
Picking isn’t a big decision for most IT managers. You probably have a preferred hypervisor — vSphere, Hyper-V, XenServer, RHEV and KVM are the big names here — and you probably want to stick with whatever you already have experience with. Don’t let a salesperson from your VDI vendor talk you into changing your hypervisor technology. All of the VDI products work with all the major hypervisors.
Go mobile-only with Samsung DeX
Your comprehensive guide to rolling out a mobile-only solution for your workers. Download Now
Scaling the VDI host physical servers requires careful analysis. Remember: Every single VDI user is going to be talking to a virtual server somewhere in your farm of physical servers running the hypervisor, and this can be a huge performance and capacity load to accommodate.
You won’t be able to wedge your VDI host physical servers (and the connection broker ones as well) into an existing infrastructure without some increase in capacity: more physical hypervisor servers, more network-attached storage and very possibly more network.
Make sure you have a good handle on what the server, disk and network performance requirements will be when VDI is fully up and running, and get that hardware installed immediately.
Step 4: Review security
Most VDI deployments are internet-facing, so you need to be sure that the security here is consistent with what your organization needs. Remember: Once someone is logged onto a server in your VDI, they’re effectively inside your network. Building in security at the beginning is a lot simpler than trying to add security once things are already running. Here’s a checklist of things to consider:
- If you’re not using two-factor (2FA) or multifactor authentication (MFA), this should be a minimum requirement for logging onto the VDI. Usernames and passwords are so easily stolen that an internet-facing VDI needs the best authentication you can afford — not just a simple password.
- Now is the time to consider network microsegmentation in your data center. When the VDI infrastructure spins up a new virtual machine (VM) to support a VDI user, that server should be extremely well firewalled from the rest of the data center network. Use traditional network firewalls to keep VDI user VMs isolated from the rest of the data center. Even better, put different types of VDI VMs into different network segments, isolated from each other and with strictly defined access to the rest of your network.
- Make sure the VDI connection broker infrastructure is self-protecting. In addition to the network layer firewall, all connection broker servers should have host-based firewall, antimalware and intrusion prevention systems. Review the security settings for features such as break-in evasion.
- Don’t forget antimalware on the VDI user VMs, especially if you’re running virtual desktop services. The VDI VMs may be wiped between users, but while someone is logged on, there’s plenty of time for malware to infect and propagate through your network.
- Evaluate remote client security. If users will be connecting to the VDI infrastructure from a personal PC, typical VDI features such as USB, file and printer sharing may be inappropriate. Users coming from thin clients and mobile devices, such as smartphones and tablets, have a very different security profile. You may want to approach these more secure clients differently.
Step 5: Bolt everything into place
Installing VDI means getting the connection broker technology in place, as well as any upgrades you need to make to your virtualization infrastructure so it can support the anticipated load. Here’s a quick checklist to guide you to the installation part of your project:
- This is a great time to hire a consultant or use the vendor’s professional services team. Most of the installation steps are one-time operations, and having someone who’s done this many times walk you through may be cost-effective.
- Performance and scalability are a big deal. If you’re installing on-premises, make sure you separately consider virtual server capacity (CPU and memory), storage systems and networking.
- Your internet connection has to handle the VDI load and do so reliably. Evaluate your data center’s internet connection and be sure it has both capacity and redundancy.
- If you’ve chosen a pure cloud or hybrid cloud/on-premises deployment, leave ample time for your network and security teams to set up VPN tunnels and directory connections. The VDI vendors will say it’s easy. It’s not. Having dedicated VPN firewalls for this project is smart and increases reliability. Don’t try to overload your existing data center firewalls with tunnels to cloud data centers.
- Take baseline performance measurements of storage systems and data center networks before VDI is running so you can see the true impact of VDI as things begin to ramp up.
Step 6: Distribute clients and train users
VDI is just another application, but it’s one that can be confusing to end users because they don’t necessarily understand the virtualization or the extra layer you’ve added. Prepare some basic training sessions so that everyone diving into VDI knows what’s happening and why.
Make sure the VDI client gets installed properly. For mobile users, point them to their app store, or push the client down using your mobile device management (MDM) solution. Desktops and laptops can load the client as part of their first connection, but it’s more secure — and faster — for the user if you preinstall the client where possible.
If your VDI will also be used by home users, create a short how-to guide detailing where to get the client and how to install it.
Step 7: Sit back and enjoy the savings
VDI isn’t cheap, and pursuing the upgrade will require a CapEx investment up front: servers, licenses and other infrastructure components. You can shift some of those costs to continuing OpEx operational expenses by selecting a cloud services provider, but there’s no question deploying VDI definitely costs money. After all, you’re taking something that already works and adding an additional layer of hardware and software. That’s never free.
On-premises VDI deployments will deliver some savings, especially if you’re going with full desktop replacement. The job of installing, debugging, supporting, repairing, deploying and redeploying end-user PCs becomes simpler — or disappears entirely — if you shift to thin clients and mobile devices. But don’t predicate your VDI project on saving money.
The goal of VDI is to deliver services to users so they can work more flexibly. With VDI, you can easily accomplish tasks that were once difficult or downright impossible. You can connect end users to Windows desktops without them setting foot in the office. You can provide mobile access to Windows apps so that smartphone or tablet users can use them without a laptop. You can tear down complicated VPN configurations and simply deliver apps from your data center over the internet — a great stepping stone in businesses’ shift to cloud-based hosting.