Taking a closer look at the VDI Functionality in Windows Server 2008 R2

Written on Aug 26 2009 Filed under: Microsoft Remote Desktop, Microsoft, VDI 15,721 views, 14 comments

by Michel Roth

The changes in Windows Server 2008 to Terminal Services as a platform were the most significant changes in Terminal Services since its integration into the Windows (Server) products. Windows Server 2008 R2 marks a similar start of the inclusion another functionality into the base Windows Server OS: VDI. In this article we will be looking at exactly how the “VDI functionality” in Window Server 2008 R2 works and what it exactly offers you (and what it doesn’t).

What do you need?

The VDI functionality in Windows Server 2008 R2 is tightly integrated with the existing RDS (the new name for Terminal Services is Remote Desktop Services) functionality from Windows Server 2008. Let’s take a look at all of the components that are needed in Windows Server 2008 R2 to use the VDI functionality:

RD Virtualization Host

The Remote Desktop Virtualization Host (RD Virtualization Host) is a Remote Desktop Services role included with Windows Server 2008 R2. RD Virtualization Host integrates with Hyper-V R2 to provide virtual machines by using RemoteApp and Desktop. In Windows Server 2008 R2 you can only use the VDI functionality by using the Microsoft Virtualization platform, Hyper-V R2. To use Hyper-V R2 for VDI, you need to enable a role service called “Remote Desktop Virtualization Host”.

This is what Server Manager looks like on a RD Virtualization Host:

RD Virtualization Host can be configured so that:

• each user in your organization is assigned a unique virtual machine and/or
• users are redirected to a shared virtual machine pool where a virtual machine is dynamically assigned (not to be confused with provisioned). An exact explanation of how virtual machines are dynamically assigned is located further on this article.

Note that this configuration actually takes place on the RD Connection Broker. The RD Virtualization Host uses Remote Desktop Connection Broker (RD Connection Broker) to determine where the user is redirected. A high-level overview of what the RD Connection broker does looks like this:

• If a user is assigned and requests a personal virtual desktop, RD Connection Broker redirects the user to this virtual machine.
• If the virtual machine is not turned on, RD Virtualization Host turns on the virtual machine and then connects the user.
• If the user is connecting to a shared virtual machine pool, RD Connection Broker first checks to see if the user has a disconnected session in the pool.
• If the user has a disconnected session, they are reconnected to that virtual machine.
• If the user does not have a disconnected session, a virtual machine in that pool is dynamically assigned to the user, if one is available.

As you can see, the RD Connection Broker does a lot of the lifting here. It’s even stronger than that. More details about what the RD Connection Broker does is listed further down in this article.

RD Session Host in Redirection Mode

A RD Session Host is what we used to call a Terminal Server (in application mode). In Windows 2008 R2 the RD Session Host role can be configured in 4 modes (as depicted below):

To be able to deliver virtual desktops to users in Windows 2008 R2 you will need to configure a RD Session Host to provide virtual machine redirection. When you configure a RD Session Host server to provide virtual machine redirection, the following changes are made to the RD Session Host server:

• The user logon mode is changed to allow reconnections, but prevent new logons.
• All programs are removed from the RemoteApp Programs list in RemoteApp Manager.
• The Authenticated Users group is added to the Remote Desktop Users group.

So yes, this means that you lose this machine as a RD Session Host, since it just redirects. You would not want to use your 128 GB, 16 core box for this (think virtual machine here). If you ever need to connect to this machine for administrative tasks, be sure to use the /admin parameters or you will not be able to connect.

The reason why Microsoft chose to require this RD Session Host in virtual machine redirection mode (a separate server) instead of just having the RD Connection Broker telling the client what virtual machine to connect to is very simple: backwards compatibility. By making a user connect to a RD Session Host in virtual machine redirection mode, clients down to version 5.2 of the RDP client can use this new functionality in Windows Server 2008 R2.

RD Web Access

Remote Desktop Web Access (RD Web Access), formerly Terminal Services Web Access (TS Web Access), in R2 has gotten a much more prominent role. The reason for this is that:

• RD Web Access services Windows7 clients by means of a RemoteApp and Desktop Connections feed (it uses RSS-like technology). This gives Windows7 users an integrated a list of all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops that they are permitted to use right in their Start Menu (Windows7 only).
• Provides the only way to non-Windows7 clients to access Windows 2008 R2 brokered virtual desktops (since they can’t use the RemoteApp and Desktop Connections feed.

So RD Web Access now provides you with a list all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops you are permitted to use. Of course (but this is not new) RD Web Access also includes Remote Desktop Web Connection, which enables users to connect remotely from a Web browser to the desktop of any computer where they have Remote Desktop access.

This screenshot shows how a virtual desktop pool is presented to a user in RD Web Access (ignore the certificate error ):

For RD Web Access to be able to provide the list of all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host hosted virtual desktops, you need to configure RD Web Access with the source that will provide this information. There are basically two options. Either you provide a RD Session Host or Host as a source or a RD Connection Broker. To be able to show virtual desktops in RD Web Access you need to provide the RD Connection Broker as the source.

This is what that confguration looks like:

RD Connection Broker

The Connection Broker role in Windows 2008 R2 has also undergone some significant changes. First, as all the components, it was renamed. From the Terminal Services Session Broker (TS Session Broker) to the Remote Desktop Connection Broker (RD Connection Broker). Just to quickly recap, these are the features it already had:

• Allows users to reconnect to their existing sessions in a load-balanced RD Session Host server farm. This prevents a user with a disconnected session from being connected to a different RD Session Host server in the farm and starting a new session.
• Enables you to evenly distribute the session load among RD Session Host servers in a load-balanced RD Session Host server farm.

In addition, in Windows Server 2008 R2 it can now also provide users access to virtual desktops hosted on RD Virtualization Host servers. While this may not sound like a whole lot, the way that this feature has been implemented has created the foundation for the RD Connection Broker to be a true connection broker that can broker access to all kinds of applications and desktops, regardless whether this is a virtual desktop running on a Hyper-V host or a RemoteApp program running on a RD Session Host.

Here’s how part of the new RD Connection Broker configuration looks:

How It Works

Even though the scope of this article is limited to just the VDI functionality in R2, I am going to expand a little bit on the bigger RDS picture in R2. The reason for this is that Microsoft in R2 has really started to deliver a pretty comprehensive way to deliver applications and desktops using RDS technology. Instead of making the mistake as viewing VDI and Terminal Services as two separate entities, they view and present the two as an option to deliver applications and desktops to users. It really is very nicely integrated. For example, the VDI and TS sessions share several components, such as the RD Connection Broker, the RD Web Access server, and (not mandatory) the RD Gateway.

Let’s take a look at how these components work together to present the user with a list of all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops that they are permitted to use (courtesy of the Microsoft RDS team):

The way this works as you go the through the steps in the diagram:

1. The client queries RD Web Access via HTTP(S), either via the new RemoteApp&Desktop Connections feed or via the Web Interface.
2. RD Web Access then takes the user credentials and queries the connection broker for the list of applications and virtual desktops.
3. The Connection Broker authenticates the user and retrieves the list all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops and presents it to the RD Web Access. The user can then click an icon to connect. If the client is using Windows 7 then the RemoteApp&Desktop Connections feed will update the list of available RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops in the Start Menu of Windows 7 clients.

So now that we have a list of all RD Session Host-hosted RemoteApp programs and desktops and RD Virtualization Host-hosted virtual desktops that we are permitted to use, what happens if we want to connect to one? Let’s take a look at the example where a user connects to his or her personal virtual desktop (the other option being connecting to a pooled virtual desktop).

1. So first (after clicking the personal virtual desktop icon in RD Web Access) the client connects to the RD virtual machine redirector (aka the RD Session Host in Redirection Mode) This means that the .rdp file that is used to connect actually points to the redirector instead of the connection broker.
2. The RD virtual machine redirector then queries the connection broker to get the virtual machine name.
3. The RD Connection Broker in turn queries Active Directory to find out which virtual machine was assigned to the user (this is a user account property in Windows Server 2008 R2).
   
4. The RD Connection Broker then queries the RD Virtualization Host for the virtual machine and powers it on if necessary.
5. Once that has been done the virtual machine name (DNS name) is passed down to the RD virtual machine redirector.
6. The RD virtual machine redirector passes the virtual machine name (DNS name) on to the client.
7. The client connects directly to the virtual desktop.

This last part is rather important from an architectural perspective: the client connects directly to the virtual desktop. The connection is not maintained through the connection broker or the RD virtual machine redirector. Once the client has been provided with the virtual desktop (DNS) name the RD Connection Broker and the RD virtual machine redirector are complete out of the way. Doing it any other way would severely limit the scalability of this solution.

What’s cool?

So there you have it. You have just seen how you can implement VDI without a single third party piece of software. Is this the end of all the third party vendors in VDI land? To answer that question we need to take a closer look at the features. So what exactly can you do with this Microsoft Windows Server 2008 R2 only setup?

You can:

• Provide AD users with access to Personal Virtual Desktops
  This is where you associate a virtual machine running on RD Virtualization Host with an AD user account.
• Provide AD users with access to Pooled Virtual Desktops
  This is where you create a virtual desktop pool on the RD Connection Broker and add virtual machines running on a RD Virtualization Host to it. When users then click the icon for that virtual desktop pool automatically a virtual desktop is assigned to that user.
• Reset pooled virtual desktop to previous state after user logoff
  This feature is actually very cool. If you create snapshots of all virtual machines in a pool and make sure that the name of the snapshots contains the word “RDV_Rollback” then the virtual machines will be reverted to that snapshot every single time a user logs of from that virtual machine. Pretty cool!
• Connects you to disconnected Virtual Desktop Sessions
  The functionality that was already in the RD Connection Broker for disconnected sessions running on RD Session Hosts also applies to virtual desktops. If you are connecting to a virtual machine in a virtual desktop pool first it will be checked whether or not you have a disconnected session before you are assigned to another virtual machine.
• Powers up Virtual Machines if they are down
  The RD Virtualization Host can power on or resume virtual machines on behalf of the RD Connection Broker if a user connects to a virtual machine that is powered down or saved.
• Saves virtual machine state after users logoff
  It also works the other way around. The RD Connection Broker can be configured to save virtual machines whenever a users log off.

What’s not so cool?

Windows Server 2008 R2 does pack a pretty decent VDI feature set, but let’s take a look at what is not so cool about a Microsoft Windows Server 2008 R2 only VDI setup?

• Non-Windows 7 clients are forced to use RD Web Access to get access to their virtual desktops
  Since the RemoteApp and Desktop Connection control panel applet is only available for Windows 7 clients you need to use RD Web Access if you are not running Windows 7 just to get a clickable icon for your virtual desktops.
• No support for other Hypervisors
  Even though Microsoft Hyper-V R2 is probably going to go places, fact of the matter is that most customers looking into VDI will run some form of VMware ESX. Keep in mind that this is when talking about a Microsoft Windows Server 2008 R2 only VDI setup. SCVMM R2 might very well be able to manage ESX hosts in this scenario as well. Time will tell.
• No provisioning
  Windows Server 2008 R2 itself offers no way to automatically create virtual desktops. They need to be manually created in Hyper-V R2 or by means of other (SCVMM) and/or third party tools. For a decently sized VDI deployment this can quickly become an issue.
• Need for a dedicated redirection host
  For backwards compatibility reasons a Microsoft Windows Server 2008 R2 only VDI setup requires a RD Session Host in virtual machine redirection mode. This does cost you an extra license and gives you another server to manage, although you could very well combine this role with the RD Connection Broker. It also makes the stack a little more complex and adds another potential SPOF. If you want to provide access to a Terminal Server farm as well you will need another, non-dedicated, RD Session Host in redirection mode only this time for a Terminal Servers farm This can be a normal RD Session Host.
• Not all RDP 7 features are available in R2 VDI
  One of the things that make a Microsoft Windows Server 2008 R2 only VDI setup viable which we did not discuss at all in this article are all the enhancements to the RDP protocol that make RDP more suitable for use in a VDI environment. Features like: multimonitor support, multimedia redirection, aero remoting, etc… are not available if you are using anything else but Windows 7 as the virtual desktop. There is seamless “backwards compatibility” though--the RDP features of the appropriate Guest VMs will be available.
• Limited Out of the Box options
  The groundwork of a Microsoft Windows Server 2008 R2 only VDI setup looks to be pretty solid. It is just the intelligence of the Connection Broker that is not quite up to par yet. Examples of situations where you could be left with a little more to be desired include:
  • You can assign a virtual desktop to a user or a virtual desktop pool to a group of users but what if you want to assign a virtual desktop to a particular IP subnet.
  • What if the virtual desktop pools do not have any virtual machines available anymore?
  • What if you want to assign a dynamically chosen virtual desktop when he logs in for the first time but always provide him with that same desktop for all logins after that?
  • What if you want to provide a user with two personal virtual desktops?

The list goes on. I think you get the idea.

• Management Tools
  The bulk of the management of the new VDI functionality in R2 has been built into an entirely new RD Connection Broker configuration wizard. Although the configuration wizard does indeed take you through all the steps you need to take it by no means is takes care of all the management. For example: if you need to manage user sessions you need to use other tools (Remote Desktop Services Manager – which unfortunately has not become more usable). If you need to manage VDI user sessions it looks like you are out of luck.
• Complexity
  Even though Microsoft did a good job in guiding you through the steps you need to take to create a Microsoft Windows Server 2008 R2 only VDI setup, fact of the matter is that it is still a pretty comprehensive setup and configuration just to allow users to connect to virtual desktops. Remember that you at least need a RD Connection Broker, a RD Virtualization Host, a RD Session Host in virtual machine redirection mode, as well as a RD Web Access host. Next to that you also have to maintain local computer group memberships like the Session Brokers Computer group and the Web Access Computer group.

Another pretty complicated aspect of a Microsoft Windows Server 2008 R2 only VDI setup is the steps you need to perform on Windows 7 virtual desktop before it can be used as a virtual desktop. It is almost scary (however, Microsoft is planning on releasing a script to help you deal with this). Most “VDI vendors” take care of this by providing an agent of sorts. With Windows 7 Microsoft would have had the opportunity of a lifetime to make Windows 7 “Microsoft VDI” ready by embedding some client in Windows 7 but they did not. Even the Hyper-V integration components are in there by default. It’s a shame the same did not happen for the “VDI stuff”.

Conclusion

With Windows Server 2008 R2, Microsoft has taken their first steps into the VDI space. These first steps look and feel like solid and confident steps. We should however be honest and objective, though, and establish that these steps are but small steps. This should absolutely not be a surprise, since Microsoft has specifically mentioned that the VDI functionality in Windows Server 2008 R2 is aimed at small and non-complex environments. I am sure that this functionality will be enhanced in future releases. This is similar to what Microsoft has been doing in the Terminal Server/ RDS space for many years now.

To do VDI on any other scale beyond the scope of “small and non-complex environments” you would definitely need additional third party “VDI products” (like –in no particular order- Quest vWorkspace, Citrix XenDesktop or any other Hyper-V compliant VDI solution) and other Microsoft products (like SCVMM R2).

Comments

Michel Roth wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Wed, Aug 26 2009 7:50 AM

Even though the heads-up at the beginning of this article is still in place, I am confident that no changes were introduced in the RTM version of Windows Server 2008 R2 that would necessitate changes or update to this article.

appdetective wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Wed, Aug 26 2009 7:00 PM

You work for Quest!!!!! Jesus things must be bad.....

Michel Roth wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Thu, Aug 27 2009 2:41 AM

Appdetective,

I am not sure I follow (or if your comment requires a response).

Charlie Mason wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Thu, Aug 27 2009 5:58 AM

I can see Microsoft building this as a feature pack for Windows7. I'd actually welcome them to do so more often.

Add features if you want them but don't flood the basic OS with this kind of stuff.

Cool article Michel,

Michel Roth wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Thu, Aug 27 2009 12:57 PM

Hi Charlie,

With "building this as a feature pack", do you mean making Windows7 more "VDI ready" as discussed in the near final paragraphs of my article ?

appdetective wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Thu, Aug 27 2009 5:26 PM

@Michael. My mistake, I thought I was reading a Brian a disclaimer. You do great stuff.

Anyway my question with all of this is x64 VDI ready due to the apps. I don't think so.

Michel Roth wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Fri, Aug 28 2009 2:02 AM

@Appdetective: do you mean if Micrsoft 2008 R2 VDI will run 64 bit VMs?

appdetective wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Fri, Aug 28 2009 7:20 PM

@michael, I'm more concerned about running x32 apps in a x64 R2 world. It's confusing to me why MS thinks if Win 7 is not x32 why they think R2 x64 is valid for R2. Am I missing something?

appdetective wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Fri, Aug 28 2009 7:30 PM

The other thing I am wondering is with R2, after reading the Citrix blog below. Will service providers adopt it to deliver x64 only? BTW I loved the streaming ICA Client demo from a browser. Very fast stream for me.

community.citrix.com/.../viewpage.action

Booth Brennan wrote re: Taking a closer look at the VDI Functionality in Windows Server 2008 R2

on Fri, Oct 30 2009 10:59 PM

This is cool, I like this blog. Very useful and informatic for me. Thanks brilliant!!!

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.

Trackbacks

Taking a closer look at the VDI Functionality in Windows Server … | Windows (7) Affinity wrote Taking a closer look at the VDI Functionality in Windows Server … | Windows (7) Affinity

on Wed, Aug 26 2009 3:00 AM

Pingback from  Taking a closer look at the VDI Functionality in Windows Server … | Windows (7) Affinity

Taking a closer look at the VDI Functionality in Windows Server … | Webmasters feeds wrote Taking a closer look at the VDI Functionality in Windows Server … | Webmasters feeds

on Wed, Aug 26 2009 3:04 PM

Pingback from  Taking a closer look at the VDI Functionality in Windows Server … | Webmasters feeds

Twitter Trackbacks for Taking a closer look at the VDI Functionality in Windows Server 2008 R2 - Michel Roth - BrianMadden.com [brianmadden.com] on Topsy.com wrote Twitter Trackbacks for Taking a closer look at the VDI Functionality in Windows Server 2008 R2 - Michel Roth - BrianMadden.com [brianmadden.com] on Topsy.com

on Wed, Aug 26 2009 4:26 PM

Pingback from  Twitter Trackbacks for                 Taking a closer look at the VDI Functionality in Windows Server 2008 R2 - Michel Roth - BrianMadden.com         [brianmadden.com]        on Topsy.com

4sysops - Download WSUS 3.0 SP2 – WSUS SP2 guides – IE8 via WSUS – Win 7 language packs – VDI in Windows Server 2008 R2 – Amazon private cloud wrote 4sysops - Download WSUS 3.0 SP2 – WSUS SP2 guides – IE8 via WSUS – Win 7 language packs – VDI in Windows Server 2008 R2 – Amazon private cloud

on Wed, Aug 26 2009 4:35 PM

Pingback from  4sysops -   Download WSUS 3.0 SP2 – WSUS SP2 guides – IE8 via WSUS – Win 7 language packs – VDI in Windows Server 2008 R2 – Amazon private cloud