Detangling Virtualization Options: The VDI Difference

Giorgio Bonuccelli
By

Last updated on August 17, 2021
  0

In early June, I spent the week manning the Windows Server 2008 R2 Remote Desktop Services booth at TechEd North America 2010. It as an exhilarating, exhausting and educational experience, fielding questions from IT pros from all over the world and trying to come up with solutions to some complex scenarios that I had never encountered before. One thing that struck me was the confusion among many in the IT field about virtualization in general and Microsoft’s various virtualization options in particular – as well as how third party solutions fit into the picture. In this article, I’m going to attempt to “detangle” some of that confusion and help you determine which of the many offerings will work best for your organization and users.

Microsoft’s penchant for renaming its products doesn’t help matters – even when it makes sense. And changing the name of Terminal Services to Remote Desktop Services (RDS) does make sense; RDP is just as often used to deliver desktops to rich clients (full fledged PCs) as to thin clients (terminals). But most IT pros think of “Remote Desktop” as a name that refers to the more limited form of RDP access in XP Pro, Vista Business/Enterprise/Ultimate and Windows 7 Pro/Enterprise/Ultimate, which allows only a single remote connection and locks out local access while an RDP session is in progress.

In fact, Remote Desktop Services in Server 2008 R2 refers to what was formerly called Terminal Services, but this is a much more complex and feature-filled version of TS than you’re used to if you’re coming from Server 2003. Some of the new features were added in Server 2008 (when it was still called Terminal Services) and some in Server 2008 R2. These include RemoteApp, Web Access, Gateway, and Session Broker (all introduced in Server 2008) as well as the new R2 features: Desktop Virtualization (VDI), IP Virtualization, Fair Share CPU Scheduling, and improvements to management, application installation, audio, video and multiple monitor support.

RDS session host desktop delivery vs. Virtual Desktop Infrastructure (VDI)

The question I encountered most frequently from TechEd attendees was “What’s the difference between the Remote Desktop session and VDI – and which one do I need?” It’s easy to confuse the two, because in both cases, you’re delivering a virtualized desktop to your user’s local machine, which the user can access instead of or in addition to the OS that’s actually installed on that local machine. But there’s an important difference.

The RDS Session Host and VDI represent two different types of server-based desktop virtualization:

When you deploy a remote desktop to the user via a Remote Desktop Session Host (the equivalent of what used to be a Terminal Services Application Mode server), the user is working in a shared environment on a server-based operating system, in this case Windows Server 2008 R2. Now, if you enable the Desktop Composition feature, the users’ desktops will look and feel like Windows 7 desktops, with the full Aero experience – but the underlying OS is still Server 2008 R2. On the other hand, when you deploy a desktop to the user via Microsoft’s VDI implementation, which is called the RD Virtualization Host, each user gets a unique, separate virtual operating system that is hosted on a server running in a hypervisor (Hyper-V). So even though in both cases the desktop is presented to the user over the Remote Desktop Protocol (RDP), the way those desktops are stored on the server is very different.

So what are the practical implications of this difference? With the RDS shared environment, you can host a larger number of remote desktops and thus service more users using the same physical server. This means lower cost per user. You only have to buy an RD CAL for each user or each RD client computer (depending on which licensing method you select). With VDI, you have to buy an operating system license for each desktop that you deploy.

NOTE

Typically, an RDS desktop delivery solution can support 250 users on one server; the same server can support 30-50 users. The actual number of VMs per server depends on the hardware configuration, application software, and user workloads.

On the other side, with the VDI environment you deploy actual client operating systems to users, and all users don’t have to use the same OS; e.g., some could use XP, some Vista and some Windows 7. Some applications do a version check and won’t run on the server OS; these apps would run on the client operating systems that you deploy via VDI, so you generally get better app compatibility. In addition, the individual operating systems are more isolated. In the RDS shared environment, users should not be given administrative privileges because they could make changes that affect other users.

The RDS presentation virtualization solution is a more mature technology that Microsoft has offered since the release in 1998 of Windows NT Terminal Services Edition (code named Hydra), which was based on the MultiWin engine created by Citrix for its WinFrame product – a multi-user version of Windows NT 3.51. Although IBM first created virtual machines on its mainframes in the 1960s and VMware introduced virtualization for x86 computers in 1999, the concept of a hypervisor-based virtual infrastructure is a relatively new development, considered by some to have been born of the blade PC in the early 2000s. VDI technology is still evolving, is more complex, and can be more costly in terms of hardware capital expenditures.

Both RDS session host desktop delivery and VDI have security benefits, in that the operating systems are located on centrally managed servers in the datacenter that are generally subject to tight physical security. This makes it easier to control the applications and data and to ensure that security updates are applied, and if the endpoint device is stolen or otherwise accessed without authorization, it doesn’t contain data or apps locally and the user’s desktop is not at risk.

Both solutions also have a disadvantage: dependency on the network connection for users to access their desktops. If the endpoint device can’t connect to the RDSH or RDVH server, the user is cut off from his/her desktop, apps and data. This is the same drawback that has hindered the adoption of cloud computing. High end graphics applications in RDP sessions have also presented problems, but Microsoft is looking to its new RemoteFX technology to change that with both RDS and VDI, supporting full-motion video, Silverlight, 3D apps and OpenGL via GPU virtualization.

RDS/VDI integration

Microsoft has integrated the new VDI functionality into the traditional Terminal Services/RDS function, making the Remote Desktop Virtualization Host a role service within the Remote Desktop Services server role. Remote Desktop Session Host (formerly Terminal Services Application Mode) is also a role service. Both of these are installed from within Server Manager, as shown in Figure 1.

deb7.7.2010 1

FIGURE 1: Installing the Remote Desktop Virtualization Host role service for Microsoft VDI

When you attempt to install the RD Virtualization Host role service, you will be notified of an important dependency: Hyper-V must be installed on the server, as well, because it is the hypervisor that creates and manages the virtual machines deployed via the VDI. Microsoft makes it easy to add Hyper-V within the process of installing the RDVH role, as shown in Figure 2.

deb7.7.2010 2

FIGURE 2: Hyper-V must be installed on the server running the RD Virtualization Host

NOTE

A “gotcha” here is that in order to install Hyper-V, the processor must support hardware-assisted virtualization (Intel VT or AMD-V), and the feature must be enabled in the system BIOS. An interesting caveat is that you can’t install Hyper-V in a VM that’s running on Hyper-V. Or rather, you may be able to install it, but the VMs you create it in won’t run. That means if you have a virtual machine running Server 2008 R2 in a Hyper-V VM and you wanted to make it an RD Virtualization Host, you wouldn’t be able to do so. You probably wouldn’t try to do this in a production environment anyway, but it can be an obstacle for those who like to test such deployments in a virtual environment.

The RDVH servers run Hyper-V and host the desktop VMs, which are delivered to the client PCs (or other RDP client devices) over the network. Users can connect to the VMs from remote desktop PCs, laptops, thin clients or even smart phones and other mobile devices. An important component of Microsoft’s VDI is the Connection Broker, which establishes and manages the user sessions, allocates VMs from a pool, etc. The Connection Broker uses the Active Directory for session authentication and authorization.

The following components work together in Microsoft’s VDI:

Application delivery in the VDI environment can be accomplished via RDS RemoteApp or Microsoft Application Virtualization 4.5 (APP-V).

Microsoft VDI licensing options include:

Why do you need third party products?

Microsoft has attempted to put together a complete VDI solution, but in the process has created some confusion with all the different components. A Microsoft-based VDI deployment can be enhanced by third party products such as 2X Software’s VirtualDesktopServer.

One major problem with the Microsoft solution is that it assumes a pure Windows environment. The reality of the business world is that many networks today are heterogeneous, running different platforms. The 2X VirtualDesktopServer is vendor-independent. It supports not only Hyper-V and Windows Terminal Services/RDS, but also many other common hypervisors, including VMware vSphere, ESX and ESXi, Parallels Virtuozzo Containers, Citrix XenServer, and Sun VirtualBox. You can manage and run virtual desktops on Windows, Linux and Mac computers for the greatest flexibility for both administrators and users. You may also be able to save money by integrating some Linux-based machines into your VDI.

Another problem with going the “pure Microsoft” route is that, in order to get advanced features such as VDI, you’ll need to upgrade your servers to Windows Server 2008 R2 and your clients to Windows 7. That can be an expensive proposition at a time when many companies find themselves in a budget crunch. With 2X products, you aren’t required to run the latest server and client OS in order to get the benefits of VDI.

2X VirtualDesktopServer also gives you centralized management of settings and connectivity options for all users directly from the management console, and supports Deepnet Unified Authentication to give enterprises the security benefits of managed multi-factor authentication using various types of tokens such as MobileID, SafeID, QuickID, GridID and RSA’s SecureID. MobileID and QuickID are especially interesting technologies that turn users’ mobile phones into one-time password tokens.

Summary

If you have already determined that the benefits of a server-based virtualized environment – easier management, more convenient “anywhere” user access, performance, security and reduced TCO – are right for your organization, the next step is understanding all of the virtualization options that are available to you, and how Microsoft’s solutions can be enhanced and made even more functional with third party products. A cost-benefits analysis can help you decide the best deployment route to take in bringing VDI to your network.