7 Considerations Before Deploying Hyper-V VDI

The most common application for Hyper-V is server virtualization, but can include hosting resources for clients, such as Hyper-V VDI. While Server virtualization is a use case that has almost obvious benefits, it’s not nearly as common to find desktop operating systems on the server platform (as opposed to Client Hyper-V or any of the various type 2 hypervisors). However, it is perfectly suited to the task.

The real question is: is desktop virtualization a solution to your problems? Such a solution is called a virtual desktop infrastructure (VDI). Creating and managing VDI are not trivial tasks in Hyper-V VDI (or any other hypervisor) and can end in disaster if not properly planned. My goal with this article is to reach you during the contemplation phase where you’re trying to determine if Hyper-V VDI is worth tackling.

Here are 7 things to think about before even starting a pilot project:

1. Learn Your Letters

Searching on Hyper-V VDI is going to lead you into a morass of TLAs (three-letter acronyms) and FLAs that make it difficult to know what you’re reading. Let me help:

• VDI: virtual desktop infrastructure
• RDS: Remote Desktop Services — this is an umbrella term for VDI on Microsoft platforms, including Hyper-V VDI
• RDVH: Remote Desktop Virtualization Host — a Hyper-V host specialized to run Windows desktop operating systems as guests
• RDSH: Remote Desktop Session Host — a Windows Server host that runs one operating system for many concurrent users
• RDGW: Remote Desktop Gateway — a Windows Server system that funnels many users through a single keyhole so that they don’t need to directly access their desktops
• RDCB or RDB: Remote Desktop Connection Broker: a Windows Server system responsible for directing user connections to their virtual desktop
• RDWA or RDW: Remote Desktop Web Access: a Windows Server system that presents a web page that presents a user-friendly way to connect to a virtual desktop

2. VDI is Probably not Going to Save Any Money

We’re accustomed to server virtualization resulting in a cost savings. Those savings don’t translate into the VDI space in general, or Hyper-V VDI. Here are some of the costs you’ll need to be prepared for to build a successful Hyper-V VDI deployment:

• No hardware savings. Server virtualization enables hardware consolidation: many unique Hyper-V VDI requirements include server deployments on much less hardware than physical deployments. It works very well because end users really don’t care how many towers are in the closet or how many rack slots are filled in the datacenter. They only care that their services are accessible. If you try telling 30 employees that they’re all going to have to share a single desktop computer on the same shift, you’ll get a noticeably less positive response. Even if they all have their own virtual desktop, they’ll still need unique devices to access them, and those cost money. It is possible to drive down the average cost of a virtual desktop to the $300 range, but once you add the remote device back in, you’re probably right back at the cost of a regular desktop (or higher).
• VDI Licensing is almost definitely more expensive. Hyper-V VDI licensing varies wildly. One thing is for certain: you won’t find anything quite like the guest virtualization rights for server when it comes to virtualized desktop operating systems. You can, of course, use non-Windows desktops in your virtual environment, but there are lots of asterisks and conditions to go with that. I’m not going to go into them here, but I will say that I would likely not use Hyper-V VDI as the VDI platform of choice if I weren’t going to use Windows desktops. So, you have to license the Windows environment for the virtual desktop, you have to license whatever operating system is on the device that your users access their virtual desktops from, and, depending on your particular VDI environment and licensing scheme, you probably have to license the fact that they’re connecting to a virtual desktop. You’re not going to come out ahead on licensing versus just buying a bunch of desktops or laptops with OEM Windows.
• High availability isn’t cheap. Having one desktop go down is an annoyance. I don’t know anything about your organization, but I’m guessing that having a virtual desktop host crash and take 200 virtual desktops with it is likely to be categorized as “unacceptable”. You’re going to need to build up your hardware infrastructure to support your virtual desktop infrastructure, and that’s going to be expensive. You’re also going to have to buy enough licenses to cover every host in the Hyper-V VDI cluster.
• You need more than Hyper-V on the server for implementing Hyper-V VDI. Hyper-V alone does not make a virtual desktop infrastructure make. You’re going to need at least one other fully-licensed Windows Server system and really, that’s not going to be enough.
• Plan to pay for support in the realm of Hyper-V VDI. If you can follow the TechNet lab guides and build an environment that’s 100% acceptable for production, you’re ahead of the game. The tools are not robust and do not fare well once you start trying to make exceptions. Hyper-V VDI isn’t the most popular application of Microsoft technology, so there’s not as much publicly available information or as large of a community-based experience pool to draw on compared to other Microsoft tech. That means that if you run into problems, you’re probably going to need to lean on Microsoft or consultants. From my experience, the regular support at Microsoft Product Support Services does not have a very solid grasp of VM-based Hyper-V VDI. If you can get into the upper tiers, that story changes dramatically; some of my best support experiences with Microsoft have come from the top-tier RDS support staff. That level of support does not come cheap and maybe not at all if you haven’t got an agreement.

These mentioned costs are just for initial deployment. There will be others that will be discussed in the upcoming points.

When it comes to the financials, there are other points that may or may not be negatives, depending on your organization.

• Hosting Hyper-V VDI on-premises means really large, but infrequent, capital expenditures. Every organization does accounting its own way. Some are able to leverage new debt in their favor. If that’s you, then Hyper-V VDI might make sense. If it’s not, Hyper-V VDI’s total cost might be made worse by the fact that it’s one large hit all at once. To just install a Hyper-V VDI environment on day one requires that you purchase at least one very capable server-class system along with the necessary Windows Server and Windows licenses. If you’re going all-in with a highly available architecture, you’ll need another host, centralized storage, and more licenses. In contrast, many organizations rotate physical desktop and laptop purchases so that they spend a relatively small amount at any one time.
• Hyper-V VDI can make sense for organizations with many remote users, especially those that work from home. Bring-your-own-device (BYOD) is becoming all the rage, but it’s tricky to enforce if you want to have your users pay for their own systems to access a virtual desktop. However, it’s not entirely uncommon to make ownership of a reliable computer be a condition of working from home, so you can offload that cost to your workers. Overall, I wouldn’t expect it to save much, if any, money, but it can help defray the costs. I want to talk about this in another point, so I’m going to leave this here.

The takeaway on this point is that VDI in general is not cheap, and this includes Hyper-V VDI.

3. The Body of Your Datacenter Will Change

Without VDI, you can make a crystal-clear distinction between the datacenter environment and everything else. The moment that you stand up your first VDI system, including Hyper-V VDI, the lines are immediately blurred. This is an especially critical consideration for high-security environments, as they commonly place an extra layer of firewalls around their datacenter that distrust the non-datacenter networks. Even when security isn’t that tight, there are usually patterns and practices around handling datacenter systems that are distinct from those around user systems. The full impact of hosting desktops in your datacenter may not be obvious at first.

4. The Face of Support Will Change

Whether you like it or not, your server administrators are suddenly going to find themselves troubleshooting desktop operating system issues and your help desk staff are going to be scratching their heads over server issues. Go ahead — put your foot down and insist that it will never happen. I predict that proclamation survives no longer than the first week. If you want a smooth rollout, you need to be well-prepared for this. Your help desk staff, your server staff, and your networking staff need to be prepared to cooperate with this before it happens or your users are going to be mired in a lot of useless finger-pointing.

5. There is More than One Way to VDI

VDI is a pain to get good information on because you have options. In a Microsoft environment, there are three ways.

Session-Based VDI

This is the traditional model that you might know as “Terminal Services”. Some of us who have been around for a while compare to Citrix’s Winframe and Metaframe environments. This approach is now called session-based virtual desktop. It doesn’t use desktop operating systems at all. Instead, you have one server operating system instance that everyone connects to. Upon attaching, a user receives his/her own “session”. This session has its own processes, but shares the same services and kernel as everyone else.

The benefits of session-based VDI:

• It’s usually lighter in the licensing department since you don’t need to cover multiple operating system instances.
• An administrator or delegated user (like a supervisor) can easily observe another user’s session via shadowing. This can be for the purpose of spot-checking that someone is working. A better use (in my opinion) is for aiding a user in distress.
• Tracking of logins, logouts, and session lengths is fairly trivial.
• Install software once for everyone.
• You can offload session-based VDI to Azure or another cloud provider.

Session-based VDI does have a number of limitations:

• Not all applications participate well in a session-based environment.
• Licensing software in a session-based environment can be very expensive and might require you to over-buy.
• Only one computer-based Group Policy can be applied.
• Everyone runs the same operating system.
• No desktop-specific features, such as RemoteFX graphics acceleration.
• A blue screen for one is a blue screen for all. Misbehaving applications affect everyone.
• No clear division of server vs. desktop support responsibilities, meaning that you are best served by hiring staff that are experts in session-based virtual desktops as opposed to generalists.
• It is possible to exhaust soft resources (like open handles) on a single session-based host while there are still plenty of physical resources. This means that session-based hosts are unlikely to reach very high densities.
• Mapping of end-user devices into a session-based virtual desktop may not function as expected; printers usually work, but many other devices do not. Some may require a software installation, and that impacts everyone.

In Microsoft VDI terms, the physical computer that users connect to for session-based VDI is called the “Remote Desktop Session Host” (RDSH). Typically, an RDSH is a physical machine with an operating system installed directly to the hardware. While there are ways to leverage Hyper-V to some advantage in a session-based deployment, it is not a necessary or preferred component. The Microsoft RDSH platform helps to answer the question of what protocol should i use to connect thin clients to Hyper-V VDI as it relies on the standards built around Remote Desktop Protocol.

Virtual Machine-Based VDI using Hyper-V VDI

The alternative to session-based VDI uses virtual machines on Remote Desktop Virtualization Hosts (RDVH), and this is where VDI Hyper-V enters the picture. This option itself has two options:

• Pooled. A pooled virtual desktop collection uses a single base image, such as a Hyper-V VDI Windows 10 image, that is specialized per user as they connect. The special environment is destroyed when the user exits. Their personalizations are saved to a separate location, however. Under the hood, what is effectively happening is that a checkpoint is taken when the user logs in and that is what they use. Upon the end of their session, the checkpoint is discarded. A pooled environment allows you to manipulate a single master image and have it affect everyone that uses the pool.
• Personal. A personal virtual desktop collection is built from a single source, just like the pooled. However, a completely distinct copy is made when a new user connects. This copy persists until it is destroyed. Changing the personal collection’s master image does not affect any desktops that have already been deployed from it.

The benefits of virtual machine-based VDI:

• Users have their own, distinct environments. They do not share their virtual machines with anyone else. If a user crashes his session, no one else even notices that anything happened.
• It is possible to host different environments on the same physical host. You simply create more collections with whatever design you need. Windows 7, Windows 8, and Windows 10 can all perfectly co-exist on a Hyper-V Server host. Any of them can be upgraded independently of the others.
• Microsoft’s deduplication technology really shines for virtual machine-based VDI with Hyper-V VDI. It operates while the guests are on and results in tremendous savings levels. The more desktops deployed, the higher the savings.
• RemoteFX is enabled, granting high-performance graphics and enhanced desktop-grade performance. Some people have even designed their VDI environments to play demanding video games remotely.
• There is a vivid distinction between the server and the desktop, although overlap will still occur.

The drawbacks of virtual machine-based VDI:

• VM VDI is an expensive solution. Licensing costs alone cause many to turn away.
• You’re on your own with VM VDI. You can’t host this yourself in Azure (but you can of course use Windows 365 or Azure Virtual Desktop). I’m not sure about Windows 10, but earlier Windows desktop licenses precluded them from being run in a hosted environment.
• There are a number of maturity issues around the VDI management tools in a Microsoft environment. From my perspective, they’re not quite as severe as the state of Hyper-V’s management tools, but I recommend taking your time to really vet what the tools can and cannot do before moving out of your VDI pilot phase.
• You need several server components. You can host most of them on one system, but if you want a robust, highly available system, you won’t.
• Documentation is spotty. Resources are spotty. Community knowledge is spotty. Support is spotty. VM-based VDI will challenge you.

Windows 365 Cloud PC

For those that do not want the headache and management costs of managing their Microsoft-based VDI solution on-premises, Microsoft recently announced Windows 365 Cloud PC. It provides a way for organizations to have Windows PCs in the cloud that are fully managed from an underlying infrastructure perspective.

Even though it is a new solution, the writing is on the wall that Microsoft is going all-in on cloud desktop technologies providing a way for businesses to have a fully-hosted solution that allows moving past the management aspect of VDI into consumption only. You can learn more about Cloud PC here: Windows 365 Cloud PC | Microsoft

If you want more control over the VMs and all aspects of your virtual desktops in the cloud you can also consider Azure Virtual Desktop, AVD which gives you many more options than the simple, SaaS based Windows 365 offering, at the cost of more configuration and management overhead. Learn more here:  https://docs.microsoft.com/en-us/azure/virtual-desktop/overview 

Choosing Session-Based VDI or Virtual Machine-Based VDI using Hyper-V VDI

This isn’t a guide, unfortunately. This is the take-away for this bullet point. You have to decide between these two for on-premises installations. They could be forced to work together, but they have very different personalities and I would not recommend allowing them to become cozy. The decision is best made in the light of your organization’s needs and capabilities. Don’t forget that abandoning Hyper-V VDI and continuing with the traditional physical desktop model is always an option. The new Cloud PC / AVD options from Microsoft also provides a compelling option for organizations looking to do away with the traditional on-premises VDI implementation and move their VDI solution to the cloud.

6.You Can’t Do VDI Partway

It’s tempting to just stand up an RDVH host and go. Unfortunately, immediately upon rebooting, you’ll discover that you can’t live that way. It’s immediately going to tell you that it wants to talk to an RDS Licensing host or it’s going to stop working in a few days (and not nearly enough days for a solid pilot, unfortunately). That’s not all. Have you ever read that kid’s book, “If You Give a Pig a Party”? That’s sort of what VM-based VDI is like:

• If you set up an RDVH, it will want an RDS licensing system and an RDCB.
• If you get a user on RDVH, s/he will want to connect more easily, so you’ll have to stand up an RDWA.
• If you get a user on RDWA, s/he will tell everyone else, and they’ll want to get on it, too.
• If you get lots of users on RDWA, they’ll want to connect from home.
• If users want to connect to RDWA from home, you’ll have to set up an RDGW.
• Once you have all these users on RDGW and RDWA and RDCB and RDWA, you’ll have to start scaling those roles out for HA.
• If you scale out RDCB, it will want a separate SQL Server.
• Once you set up an RDGW for RDWA with an RDCB on a SQL Server for RDVH, you’ll have to grant single-sign on. Doing that well means buying lots of SSL certificates.
• Once you have an HA RDGW and RDWA and RDVH and RDCB on a SQL Server with single-sign on, your pilot is no longer a pilot and you have to buy more hardware to make more RDVHs. (Start over at the beginning)

As you embark on this journey, you’ll find that there is a fairly steep, although somewhat short, learning curve to VDI. There are many Hyper-V VDI best practices to take note of to ensure the implementation is production-ready.

7. VDI Brings Many Benefits

While I want you to be aware of all the potential deal-breakers, I also want you to be aware of the fact that Hyper-V VDI does solve problems and it is being used to great effect in some places. Here are just some of the things that Hyper-V VDI gives you that cannot be matched by other technologies:

• Through a single Internet-facing keyhole, your users can access their virtual desktop from anywhere in the world. This grants you the ability to maintain a high level of security while also granting a high level of accessibility.
• No VPN necessary.
• Much tighter control over resources. You can prevent the user from connecting any device at all, greatly reducing the data that can be transferred back to remote systems. No more company files walking off on USB drives!
• Much easier control over desktop deployments. You can build a single gold image and push, and re-push as necessary.
• [Re]deploying a VDI image is very fast. I despise “administrators” whose first solution to every problem is to re-image a user’s computer, but there’s no doubt that it’s sometimes the most appropriate action. For those times, Hyper-V VDI can operate much more quickly than your average desktop hardware.
• Unparalleled control over desktops. For example, if a user has been terminated, you can unassign that user’s desktop and shut it off immediately.
• Users can start a long-running process and walk away from it. They can reconnect from any computer at any time. For instance, do you have any developers that need to start a large compile job but also need to be able to monitor it as they walk from meeting to meeting? No problem with Hyper-V VDI.
• Users can access much more powerful hardware at an overall lower cost than can be provided with traditional desktops. By leveraging Dynamic Memory, you can stretch your hardware dollar even further.
• In a VM-based Hyper-V VDI deployment, a user can be granted access to as many pools as necessary to perform his/her duties. If developers need to be able to work with Windows 7 and 8 and 10, it’s no longer necessary to place multiple physical machines in their work spaces or have them multi-booting.
• Many security features are baked right in. By default, a user cannot directly remote to his/her desktop; s/he must go through the connection broker. This is because the user’s account is not granted access to the local administrators or remote desktop users groups. The connection broker handles this portion. Also, the entire conversation is encrypted.

VDI is a Major Undertaking

While it would be nice to compile a simple, short introduction and tutorial, VDI is too large of a topic to be appropriately handled in that fashion. Make sure that you have your head wrapped around all of these concepts and have organizational willingness to handle them before you even begin architecting a VDI solution. This is not the final word on the issues that you’ll be confronted with along the way.