Microsoft Virtual Desktop 101 – making sense of VDI, RDS, App-V, MED-V and desktop virtualisation

Desktop virtualisation is a hot topic right now. It seems wherever I go and whatever I read about the desktop and where it’s headed, virtualisation is something that people want to talk about. Often these conversations are about VDI (virtual desktop infrastructure) but in part that seems to be because VDI is such a buzzword at the moment, and people want to know more about it.

One of the problems if you’re new to the topic is getting to grips with the concepts and technologies. Because it’s hot there is no shortage of information but in some ways that’s part of the problem: there’s too much information and most of it seems to assume that you already know a whole lot about the subject and tends to dive right in to a level of detail that, as a newcomer, you really don’t need. I think people want the big picture but are finding instead a jumble of jigsaw pieces.

So here’s my attempt to put the jigsaw together. It’s not perfect by any means, and I’ve glossed over a few things and perhaps oversimplified in parts, but hopefully this article will give you enough of the essence of the subject that you can go elsewhere to fill in the detail.

Where to start? How about the familiar place everyone can relate to: A copy of Windows installed on a PC on your desktop. Now, let me start by saying there’s nothing wrong with this picture - it’s served us well for many years and is likely to continue to do so for many more. But the emergence of fairly cheap high bandwidth, coupled with fast processors, abundant memory and relatively cheap disc storage has given rise to some new models that give you additional options that might not have been viable a few years ago.

Let’s remember the good things about the local copy of Windows on a desktop PC: Rich user interface, lots of peripherals that you can plug in to enhance your interaction with the PC, portable and available wherever you are, able to take advantage of a network connection when there is one, but able to work perfectly well when there isn’t, ultimate flexibility and customisability, and so on. Of course, there’s a dark side too: Operating system, applications, data and user interface are tightly bound together making it difficult to make changes to one without affecting the others. For example, application conflicts, potential difficulties in deploying applications and updates, etc

Enter virtualisation. In its simplest terms, virtualisation allows you to move some elements that are usually locally installed on the PC to a server running somewhere else (the term usually applied is “a remote server”, although it could be in the same location or the other side of the world, or even in some cases on the same PC in a virtual bubble – but more on that later) in order to provide more flexibility, reduce costs and help make management easier.

We’re going to look at the following ways in which this can be done. Don’t worry about what these mean just yet, we’ll spend some time drilling into each of them:

  • Application virtualisation (App-V)

  • Virtual Desktop Infrastructure (VDI)

  • Session Virtualisation (probably better known by its old name of Terminal Services)

  • Virtual copy of an operating system running on your local PC (Microsoft Enterprise Desktop Virtualisation or MED-V, and XP Mode on Windows 7)

There are various other flavours and variants that I’m not going to go into here, but the above scenarios should give you a reasonable grounding into the options available. So let’s take them on one at a time:

Application Virtualisation, or App-V

What is it?

If you buy an application today, maybe a packaged application like Microsoft Office, you normally stick a DVD into your drive and install it on your machine. If you work for a big company it may be installed over the network instead but the end result is the same: a copy of Office is installed on your PC. An alternative is to use App-V, which works as follows: The application (eg Microsoft Office in our example) is packaged up on a server in a way that can be squirted down the network and, instead of being installed on the local PC, is instead run on the PC in a local “bubble” that is completely isolated from the client operating system but contains everything that the application needs in order to run – drivers and dlls and registry entries etc. From the user’s point of view the application appears to run exactly as if it were locally installed, however they won’t find it in the list of programs installed via the control panel. All of the application code is being streamed from the server and executed on the local PC in its virtual bubble. It will do so intelligently, only streaming down the parts you need as you use them and, once it has streamed it, it is cached on the PC so that it doesn’t have to stream it every time you use it. It also means you can use the application while you’re offline.

It’s worth bearing in mind that App-V can be used on virtual desktops as well as traditional “rich” desktops. More on this later.

What’s the advantage?

There are a number of advantages to streaming the application in this way instead of installing it locally:

  • It resolves conflicts between applications because they are completely isolated from each other. So for example you could run Office 2003 and Office 2007 on the same machine

  • Deployment is simplified

  • It’s easy to keep applications up to date, simply update the server copy and the new version will stream down when it’s next used

  • Improves business continuity – if your machine dies, you can log onto a new machine and all of your applications will be streamed to it without having to go through a series of installs

  • No reboots required after installs

  • It’s easier to keep track of which users have which applications, which could help with licencing. Instead of installing a whole ton of applications for every user on the off-chance they may need them, they only get the applications they actually need to use

What are the disadvantages?

There aren’t many, and on the whole they are massively outweighed by the advantages:

  • Not all applications can be made to operate in an App-V environment

  • Increased server resource

  • Requires a client runtime (app-v client)

  • Some delay when the application is run for the first time as it is streamed over the network. The problem is worse for bigger applications obviously

Virtual Desktop Infrastructure (VDI)

What is it?

Simply put, VDI is running your client operating system (eg Windows 7) on a server instead of on your local PC. The server then presents the user interface over the network to a local PC, and captures keyboard strokes and mouse moves, sending them back over the wire to the server. From the end user’s point of view it can be made to appear very much as if Windows is installed on their local PC whereas actually there is nothing installed locally. A few things worth bearing in mind about VDI:

  • While you’re logged into your desktop session you will be the only one using it. That may seem a strange thing to say (after all, who else would be using it?) but it will become clearer when we talk about Session Virtualisation – but more on this later

  • When you log off there is a choice about what happens: Either any changes you make (application installed, settings amended, files created or amended, etc) are retained and are still there when you log in next time; Or all of your changes are lost and the desktop refreshes back to its original pristine state. You might wonder why you’d need the second of these options, and in fact it might seem a bit weird. After all, you're probably used to your desktop or laptop with a locally-installed operating system, and you'd be pretty upset if every time you logged off you lost all of your work and were presented with a clean-install of Windows 7 next time you logged on. The reason is more about the capacity of the server, and the ability of your IT department to keep better control of your desktop than for your benefit. Let me explain: Imagine you have 100 users all having a VDI desktop which is stored on a server. Each of these desktops will have Windows 7 installed, and probably a number of applications, and some files and data like your Word documents, spreadsheets, etc. How much disk space will these need? Maybe 50GB per user? So for 100 users than means you need 100 x 50GB = 5TB of server disk space. And every user you add gobbles up another 50GB. So how can you address this problem? Actually there are a number of ways but let me just focus on one for now: If you maintain just one "gold" image that has Windows 7 and some critical applications, you only need 1 x 50GB of space. Now you can present this to every user that logs on each time rather than an image that is individual to them. What about their personal settings and files they may have stored? You can achieve this with so-called "roaming profiles" that remember your settings and switch them on accordingly as you log in (so you get your own wallpaper for example), and folder redirection means that files you think you're saving to your Windows 7 image are actually redirected to a server store. All of which means that you appear to have an individual copy of Windows 7 that retains your settings and data, but is actually just a gold image that everyone uses.

  • As mentioned above, because you’re the only person using the desktop you can reboot it whenever you like. In fact, you can have “admin” access

  • You will need to have a reasonably good internet access to use your desktop because, obviously, it’s stored somewhere else and will only be available over a network

What’s the advantage?

There are a number of advantages to VDI:

  • Manageability and control: Because your entire desktop is stored in the datacentre, the IT department is able to keep tabs on it much more easily, applying patches and fixes, installing and upgrading applications, backing up, etc

  • Along similar lines, there are security advantages: As your desktop never actually leaves the datacentre there is far less risk of losing confidential information

  • Business continuity: Fancy way of saying that if your laptop or desktop is stolen or breaks you can just use another way and get exactly the same desktop. In other words, you’re not tied to a specific device

  • Deployment: If you need to upgrade to a new operating system it’s a pretty simple process for your IT department to simply provision an upgrade for you as it’s all under their control. They can keep your applications and data and move you, say, from Windows XP to Windows 7 pretty easily

  • Access to multiple desktops: If you need to use multiple desktops then VDI is a real boon. This is the case in high security situations such as police forces: They often need two desktops, one for ultra-secure network access and one for general use. With VDI it’s simple to just provision two separate desktops that they can switch between

  • You may be able to reduce your power consumption by using lower power PCs on each physical desktop

  • Multi device usage: You can get access to your desktop from a wide range of devices eg your work PC, your home PC, a "thin client" device - even some smart phones

What are the disadvantages?

There are some disadvantages to be aware of:

  • As mentioned above you need a good network connection to use your desktop. If you’re offline then your desktop will not be accessible. This is fine if you’re sat at a desk in an office with high speed network access, but probably not if you’re travelling

  • The user experience may not be quite as good as you have been used to. Rich graphical applications like CAD or high-def videos might not work as well. Technologies like Citrix’s HDX or Microsoft’s upcoming RemoteFX will help with this, but ultimately you’re somewhat reliant on the network bandwidth available to you

  • Some peripherals may not work, eg web cams or unified comms. Again, as the technology matures these issues are being dealt with but if you are reliant or peripherals you will need to make sure they still work ok via VDI

  • Obviously your server architecture will need to be able to cope with the increased processor, memory and storage requirements. For example, if every VDI desktop requires 2MB of RAM and 50GB of disk space, then you may need 200MB of RAM and 5000GB of disk space for every 100 desktops you provision. Now, as explained above you can help address this by having a gold image with roaming profiles and folder redirection, but there are other technologies that help to reduce this load: Citrix’s provisioning server allows cloning, whereby a master image is stored once and only differences for each desktop are stored separately (after all, the bulk of the operating system files will be identical for every desktop); Some SANs can do similar things eg remove the need to store duplicate data; And memory overcommit allows you to stretch the RAM using the same concept as airlines overbooking flights: they do so on the basis that not everyone will show up. In this case, you can allocate RAM to virtual desktops that is actually more in total than the capacity of the server on the basis that not all virtual desktops will be using their maximum RAM allocation at the same time

  • Pretty obviously there may be implications on your network bandwidth requirements. This is an important consideration that you can't afford to overlook - if you start using VDI for a large number of users you need to ensure the network is up to it. And remember that there may be some considerable peaks eg between 9am and 9.15am when everyone gets to their desk and fires up their virtual desktop

  • Power consumption in the datacentre will increase. You may be able to offset this somewhat by automatically “powering off” virtual desktops that aren’t being used (eg at night)

  • Disk I/O: Multiple users accessing multiple virtual images on a server equates to spiralling disk IOs. This can be a complex area and is affected by a number of factors but it's worth factoring into your decision making process when considering VDI

Session Virtualisation (aka Terminal Services)

What is it?

Session Virtualisation has been around a while and at first glance it might appear similar to VDI. Like VDI it involves accessing a desktop on a server rather than having the operating system installed on a local PC. There are two big differences however:

  1. Session Virtualisation connects you to a server operating system like Windows Server 2008 R2 (remember VDI connects you to a client operating system like Windows 7). The server operating system can be mocked up to look very much like Windows 7 but under the covers it's actually quite different. In fact, some applications simply won't run in this server environment which is one of the drawbacks of session virtualisation that we discuss below
  1. Other people, potentially a lot of other people, are likely to be logged into and using the same desktop as you at the same time you're using it. Remember Windows Server is a multi-user operating system designed to have multiple people accessing it. This whole concept of a number of people accessing the desktop at the same time has advantages as well as disadvantages which we'll cover below

What’s the advantage?

Session virtualisation shares pretty much all of the advantages listed under the VDI section. The big additional advantage session virtualisation has over VDI is cost - because people are sharing the same desktop you can generally pack far more users onto a server with session virtualisation vs VDI (referred to as a higher "user density") which in turn means lower costs - less servers, less resources, etc.

At this point you might be wondering why people need VDI at all - if session virtualisation has the same advantages as VDI but with lower costs, then why not use session virtualisation for everything? Cue the disadvantages:

What are the disadvantages?

Actually all of the VDI disadvantages (apart from ROI) pretty much apply to session virtualisation as well. Some of these are less of an issue eg server architecture and disk IO, but on the whole it's a similar picture. But there are some additional drawbacks to session virtualisation that don't apply to VDI:

  • As you're running your desktop on a server operating system that, frankly, hasn't been designed to be used as a client desktop, you may find some problems. For example, some applications simply won't work on the server. With VDI, because you're running a copy of Windows 7, you're far less likely to have problems on this kind

  • As multiple people are potentially using the desktop at the same time as you, you can't have admin access. And of course you can't reboot the session. And there will be some limits on configuration changes and applications that are installed. So generally session virtualisation works best if you have groups of users that have very similar needs in terms of applications and desktop configuration. If you're developing software for example, then you'll almost certainly want to be going the VDI route if you need to virtualise the desktop, not session virtualisation

Microsoft Enterprise Desktop Virtualisation (MED-V)

What is it?

If you've used Virtual PC before then you'll understand MED-V pretty quickly. If you haven't, here's what MED-V does: It allows you to run a virtualised operating system on top of another operating system. For example, you could have Windows 7 installed on your PC and, via MED-V, have a copy of Windows XP running "on top of" Windows 7. How does this work? It uses an application (called a hypervisor, specifically a "type 2" hypervisor but don't get hung up about it) that simulates, in software, a physical PC. This means you can install Windows XP onto this "virtual" PC just as if it was a real PC. As far as XP knows it's being installed onto a real PC but actually it's being fooled - the software is simulating a PC and XP can't tell the difference. Well actually it can, but let's not get side-tracked. Once you have XP installed onto this virtual PC you can use it pretty much as normal, installing applications and creating files etc. Why would you want to do this? Mainly so that you can continue to run legacy applications that only work on XP and don't, for example, work correctly on Windows 7. So you can continue using Windows 7 for your usual work and dip into the virtual copy of XP to run those applications that can't run on Windows 7.

MED-V makes the whole experience pretty seamless too. For example, an application installed on your virtual copy of XP can appear in the Windows 7 start menu, or you can create desktop shortcuts to it. When you launch it, it actually launches and runs on the virtual copy of XP rather than on Windows 7 but this can be made pretty much transparent to the user. Actually you can decide how obvious you want to make it that the application is running on the virtual machine eg by using Windows XP-style borders.

It also works really well for Internet Explorer: If you have an application or web site that only works on IE6 for example, then MED-V can allow you to configure IE8 on Windows 7 so that when you visit a URL that requires IE6 it automatically launches the virtual copy of XP and loads up the web page on IE6 within the virtual machine (again, you can make this pretty transparent to the user if you want to). When they move off the site back to one that works with IE8 it will automatically switch you back to IE8.

MED-V, as the name suggests, is primarily for enterprise customers who need to manage large numbers of desktops and keep them updated. Therefore as you'd expect it allows remote management and patching, updating etc to ensure that the virtual PC is as up-to-date and secure as the physical PCs.

What’s the advantage?

As mentioned above, the main advantage is around application compatibility:

  • MED-V allows you to run older applications that might not work on modern operating systems, which can make it easier for you to migrate to Windows 7 for example

  • You can run multiple operating systems at the same time. This could be useful if you need to test whether an application works on Windows XP, Windows Vista and Windows 7 for example - in this case you'd have virtual machines running XP and Vista

  • As mentioned above, it can be particularly useful if you have applications that require IE6

  • MED-V doesn't require a network connection, unlike VDI or session virtualisation, so you can use if offline with no problem

What are the disadvantages?

The main issues with MED-V are related to the fact that you need enough resource on your PC to run two operating systems:

  • Running another operating system on top of the one you have installed on your machine means you need a reasonable amount of RAM and processing power (and disc space of course)

  • You may need a licence for the other operating system

  • You will still need to patch and maintain the virtualised operating system, although as mentioned this is made easier in MED-V than with other similar products

  • MED-V is not suited for heavily graphical applications like games, and you might have trouble with some peripherals

Windows 7 XP Mode

What is it?

If you've understood MED-V, then XP Mode is going to be simple: Essentially XP Mode on Windows 7 is like a trimmed down version of MED-V, here are the main differences:

  • It's free if you have a valid Windows 7 license

  • You get a free copy of Windows XP built into the virtual machine

  • It doesn't have the remote management and patching capabilities of MED-V

Other than that it does a very similar job. Generally XP Mode is aimed at home users or very small businesses, and MED-V is aimed at larger businesses.

What’s the advantage?

The main advantage is the same as with MED-V: It allows you to run older legacy applications on XP while still using Windows 7.

What are the disadvantages?

In the main these are similar to MED-V's disadvantages:

  • Running another operating system on top of the one you have installed on your machine means you need a reasonable amount of RAM and processing power (and disc space of course)

  • You will still need to patch and maintain the virtualised operating system, and XP Mode doesn't have MED-V's remote patching etc capabilities

  • Like MED-V, XP Mode is not suited for heavily graphical applications like games, and you might have trouble with some peripherals

What else do you need to know?

As you can tell, there's quite a lot to desktop virtualisation and to be honest we've only scraped the surface here. However, let me leave you with a few other titbits to consider:

  • While we've described how App-V can be used to stream applications to your "normal" (ie non-virtualised) desktop, you should be aware that it's perfectly possible and actually quite desirable to use App-V with VDI and session virtualisation. So instead of installing Microsoft Office on every VDI desktop, you can use App-V to stream Office applications to your VDI desktops when they're required. That means that most of the App-V benefits accrue to your VDI implementation

  • Most organisations will want to mix and match these capabilities. Some users might need VDI, some session virtualisation, almost everyone will benefit from App-V, etc. Which means typically a first step will be to segment your users to figure out who gets what. For example, if your workforce is mostly mobile and out on the road then VDI or session virtualisation might not be a good solution given they need a reasonably good internet connection for you to access your desktop

  • XP Mode isn't included with the standard Windows 7 install, but you can download it from http://www.microsoft.com/windows/virtual-pc/download.aspx

  • App-V and MED-V are a part of the Microsoft Desktop Optimization pack, known as MDOP

  • Session virtualisation and VDI are available via Microsoft's VDI Suites

  • If you're using VDI, whether via Microsoft's products or anyone else's, you will need a special licence for your virtual copy of Windows known as Virtual Desktop Access, or VDA. This allows you to access your remote desktop from any machine and gives you rights to run up to four different VDI desktops. Note that session virtualisation is licenced differently, via RDS CALs. Read more about licencing from this document.

Next Steps

Let me close with a few web resources if you want to learn more: