Remote Desktop Services (Terminal Services) Team Blog

2000 Seat VDI Deployment Benchmark

2013-05-23T03:47:15Z

Hey all,

If you are interested in an “incrementally expandable” Virtual Desktop Infrastructure (VDI) pool architecture and want to hear about some benchmarking results we just completed, you are in the right place!

Recently we partnered with Dell to build a 2000-seat VDI deployment (all pooled virtual desktops) at our Enterprise Engineering Center (EEC) in Redmond, based on a reference architecture we had developed jointly that allows easy, incremental expansion of capacity with minimal impact on the shared storage or the storage network. The lab environment was fully isolated to minimize interference from the corporate network, and the networking back bone was built on 2x10 GB network infrastructures.

The key idea of this architecture is that VDI compute and storage are per host; think of these as VDI pods, and you can just add more pods to host more users. The key advantage of such a design is that we only need high availability (HA) type storage for user docs and settings, and typically such an infrastructure already exists in an enterprise. If not, it can be built mostly independent of the VDI. And just to complete the picture, some shared storage might be required depending on your preference for HA configuration of back-end services such as SQL, although the VDI-specific services have application-level HA and can work either way.

Following is a high level overview of our deployment.

In the preceding diagram, please note that the capacity of this deployment is primarily a function of the number of VDI hosts; one could easily add more hosts to grow capacity without upgrading the management infrastructure, but bear in mind that you may need to increase storage for user docs and settings (this analogy holds for traditional desktops with roaming or redirected folders too). That said, another benefit of this architecture is that the design of storage for user docs and settings is decoupled from the VDI design, which makes it especially ideal for pooled virtual desktops.

So with that quick intro, let’s jump into the details and results!

Results

We deployed a Win8-x86 virtual machine with Office 2013, and optimized the virtual machines for the VDI workload. Each virtual machine had a single vCPU, and was allocated about 800 MB of RAM to start with. We also enabled Hyper-V’s Dynamic Memory for better memory utilization (especially helpful for the VDI workload). The R720 hosts came with 256 GB of RAM.

We built a VSI benchmarking infrastructure (v 3.7) to run the VSI Medium workload (http://www.loginvsi.com/) on this deployment. All launchers were virtual machines on a pair of Dell 910 Hyper-V servers; we used about 100 launchers (20 connections per launcher).

Although we could have pushed each host to maximum CPU, we decided to keep them at 80% and run 150 virtual machines per host to test a closer to a real-world use case, allowing some headroom for unexpected surge. That said, I’d like do another blog just to describe a single host’s behavior when pushing CPU to max, but that’s a side note.

So following is the VSI benchmarking results for our 2000-seat pooled virtual desktop deployment, where the VSI maximum was not reached.

The logon interval was over a period of one hour, so 2000 logons in 60 minutes, where each virtual machine would start running the VSI medium workload within ~15 seconds after logon.

The load on the VDI management infrastructure was pretty low too, that’s why such a deployment can easily grow by adding more hosts, since the management infrastructure shows a very light load based on this 2000-seat run.

Network load

In the LAN environment that we had set up (2x10 GB), the RDP generated load on the network was about 400 kbps (average) per pooled virtual desktop running the VSI medium workload, so user traffic for this 2000-seat deployment would be about 800 Mbps. This is well below the capacity of the network infrastructure we had deployed.

SQL load

The following chart shows the CPU and IO load on the SQL virtual machine.

As some of you may know, SQL is a key part of our high availability (HA) RD Connection Broker model in Windows Server 2012, where the HA RD Connection Broker servers use SQL to store deployment settings (for more info, please see the following post). There are several HA models for SQL that customers can choose to build an e2e HA brokering.

Please note that the load on the SQL virtual machine is very small, about ~3% CPU and very little I/O. This means that we can easily host more virtual machines or handle faster logons.

SQL configuration

4 vCPUs, 8192 GB (~6 GB free, only ~2 GB used)
2000 connections in one hour
SQL virtual machine running on R720s

Load on the HA RD Connection Broker server

Similarly, the CPU load on the RD Connection Broker server is ~2%, which means that we have plenty of CPU to handle user logons at a faster rate.

RD Connection Broker configuration

2 vCPUs, 8192 GB (~6 GB free, only 2 GB used)
Broker virtual machines running on R720s

Following is the CPU and storage load on one of the 14 VDI hosts.

As you can see, the CPU consumption is about 75% with 150 virtual machines running the VSI medium workload.

The per-host local storage consists of 10x300 GB SAS 6 Gbps 15K disks configured as RAID1+0, easily handling the necessary IOPS.

For a tighter logon period, our recommendation is to replace one or two of the spindles with a small size SSD (for the virtual desktop template), as the I/O load during a shorter logon cycle can exceed I/O capacity of the local spindle-disks.

It is hard to say exactly when, but a good rule of thumb is to estimate I/O capacity of the 10-disk array at about 2000 read-IOPS and 1000 write-IOPS, and since the I/O load from 150 virtual machines over an hour-long logon period is about 1743, the same workload at about 30 minutes will be about 3500 IOPS, exceeding the I/O capability of the local array.

A 250-GB SSD for the virtual desktop template should easily provide the additional performance necessary for faster logons under a heavier workload.

And finally, let’s take a look at the memory consumption of a single virtual machine.

In the following chart, we see that a guest-VM is running/idling initially at about ~800 MB; CPU is pretty flat too. Then at about 11:25 AM (marked by the vertical green line), a user logon completes and moments later the VSI workload starts running. When benchmarking starts, we see that CPU usage picks up and so does the memory usage, where Hyper-V’s Dynamic Memory provides additional RAM, and finally the guest RAM settles to about 1 GB. This pattern repeats for all virtual machines on a VDI host where about 150 GB of memory is consumed by the 150 virtual machines at a cumulative CPU usage of about 75% CPU. We have plenty of headroom for CPU spikes and real world workload that could demand more memory as each server is configured with 256 GB of RAM (but remember that some portion of the 256 GB of RAM is reserved for the services running in the parent partition).

This post should help customers that are looking to set up a modular and scalable VDI solution, bringing deeper insight into some of the key performance and resource requirements that help the planning of large scale deployments.

Ara Bernardi

RDS Team

Windows Server 2012 RemoteApp and Desktop Connections: Default Connections and File Type Associations

2013-05-22T03:58:52Z

Hi all, I’m Travis Howe, a developer on the Remote Desktop Virtualization team. Today I’d like to talk about a few improvements that we made to the RemoteApp and Desktop Connections feature in Windows Server 2012: support for default connections and file type associations.

Default connections

When we added the RemoteApp and Desktop Connections feature in Windows Server 2008 R2 and Windows 7, many administrators wanted to be able to push connections to their users by using Group Policy. To help enable this, we supported a “silent install” API that allowed a user to be signed up for a connection without any prompts. Administrators had to push something like this script on Script Center to their users by using Group Policy.

In Windows Server 2012 and Windows 8, we improved this scenario. We have added a new Group Policy container under “Remote Desktop Services” called “RemoteApp and Desktop Connections,” and within that container have defined a new policy setting called “Specify default connection URL.” Enabling this policy setting causes users to be subscribed to RemoteApp and Desktop Connection at the specified URL. RemoteApp and Desktop Connections that have been installed by using this policy setting have a special name: default connections.

There are a few differences between default connections and ordinary connections:

On a given machine, a user can only have one default connection.
Default connections cannot be removed by using the Control Panel UI (the “remove” button does not exist for default connections). The only way to remove them is by changing the Group Policy setting.
Default connections are able to install file type associations.

Support for file type associations is a somewhat deep subject, so I’ll spend the rest of this post talking about it in more detail.

One more note about default connections: they are unfortunately not supported on pre-Windows 8 clients. That means, if you want to push a RemoteApp and Desktop Connection to end-users running Windows 7 PCs, you must continue to use the script-based approach.

File type associations support: what does it mean?

So what do I mean when I say that default connections are able to install file type associations? When an administrator is publishing RemoteApp programs, they can also choose to publish file types that should be associated with that program. Then, when the RemoteApp program is installed as part of a default connection, we associate the RemoteApp program with those file types on the client machine.

The next time the user tries to open a file of that type, the standard Windows 8 file type association behavior will be used to determine which of the registered programs should be used to open the file. Often, the user will be given a choice. For example, if Microsoft Paint has been published as a RemoteApp program with the .bmp file type association, the user is presented with the following options.

There is one caveat with this feature: when deciding which file type associations to publish for a RemoteApp program, administrators can only choose from a list of available file types for that app. We calculate this list based upon the file types that the app is associated with on the collection endpoints (Remote Desktop Session Host servers in a session collection, or virtual desktops in a virtual desktop collection). This is necessary because when you double-click a file that is associated with a RemoteApp program, the endpoint also needs to know how to open that file type with that program. As a rule, it doesn’t have that information for arbitrary file types. As a result, we do not support associating RemoteApp programs with arbitrary file types on the client.

So, how exactly does one publish file type associations?

Publishing file type associations using UI

As I mentioned earlier, when a RemoteApp program is published, we calculate the list of file type associations that it can support when running as a RemoteApp program. To see this list, open up the properties of a published RemoteApp program in the new Server Manager UI, and navigate to the File Type Associations tab:

In the previous screenshot you can see the list of file types that Paint is capable of launching as a RemoteApp program. To publish file type associations for this RemoteApp program, simply select the file types that you want to be made available to end-users and click OK or Apply.

After you have published file type associations for your apps, they will automatically be installed for all users who are subscribed to the RemoteApp and Desktop Connection as a default connection. That installation will happen the next time the user’s client updates the connection (by default it updates every night around midnight).

Publishing file type associations using the Remote Desktop Services module for Windows PowerShell

This feature can also be managed by using the Remote Desktop Services module for Windows PowerShell. After loading the RemoteDesktop module by typing import-module RemoteDesktop, you can get the list of file type associations available to be published for a RemoteApp program by using the Get-RDFileTypeAssociation cmdlet:

PS C:\Windows\system32> import-module RemoteDesktop
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint

CollectionName       AppAlias   FileExtension  IsPublished
--------------       --------   -------------  -----------
Test                 mspaint    .bmp           False
Test                 mspaint    .dib           False
Test                 mspaint    .emf           False
Test                 mspaint    .rle           False
Test                 mspaint    .wmf           False

In the previous code sample we again see the list of file types that Paint is capable of launching as a RemoteApp program. To publish a file type association for this RemoteApp program, use the Set-RDFileTypeAssociation cmdlet:

PS C:\Windows\system32> Set-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp -IsPublished $true
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp

CollectionName       AppAlias   FileExtension  IsPublished
--------------       --------   -------------  -----------
Test                 mspaint

Now we have published the file type association for “.bmp” files.

I hope this overview has been helpful and that now you have a better understanding of what makes the default RemoteApp and Desktop Connection different, and how you can leverage it to publish file type associations for your RemoteApp programs.

RD Connection Broker Performance and Scalability

2013-04-26T04:03:12Z

We have published a white paper that analyzes RD Connection Broker performance in Windows Server 2012.

In Windows Server 2012, RD Connection Broker provides the following functionality:

Allows users to reconnect to their existing virtual desktops, RemoteApp programs, and session-based desktops.
Enables you to evenly distribute the load among RD Session Host servers in a session collection or pooled virtual desktops in a pooled virtual desktop collection.
Provides access to virtual desktops in a virtual desktop collection.

In Windows Server 2012, RD Connection Broker functionality has been extended to enable easy collection creation in addition to its connection routing and load-balancing capabilities. This white paper presents performance and scalability testing results for RD Connection Broker. It describes the most relevant factors that influence the performance of this role service.

For more information on Remote Desktop Services, refer to the TechCenter.

Get the best RDP 8.0 experience when connecting to Windows 7: What you need to know

2013-04-10T02:54:12Z

The Remote Desktop Protocol (RDP) 8.0 update for Windows 7 provides many advantages for the remote work experience; for all the details, see KB2592687.

However, to benefit from the experience enhancements in RDP 8.0, you must configure your client and server correctly, as instructed in KB2592687. So if you want the best RDP 8.0/Windows 7 remote work experience, make sure you do the following three things:

1. Install updates KB2574819 and KB2592687 on the Windows 7 (not Windows Server 2008 R2) system you’ll be connecting to. If you’ll be connecting to this system from a Windows 7 PC, install these updates on that system as well. (If you’re running Windows 8 on your client PC, you’re all set. Sorry, there’s no RDP 8.0 support for Windows Vista or Windows XP.) After the installation, restart your computer.

2. RDP 8.0 is disabled by default, so you must enable the following Group Policy settings on the Windows 7 system you’ll be connecting to:

“Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Enable Remote Desktop Protocol 8.0” should be set to “Enabled”
“Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections\Select RDP Transport Protocols” should be set to “Use both UDP and TCP”

Important: After these policy settings have been configured, restart your computer.

3. Allow port traffic: If you’re connecting directly to the Windows 7 system, make sure that traffic is allowed on TCP and UDP for port 3389. If you’re connecting via Remote Desktop Gateway, make sure you use RD Gateway in Windows Server 2012 and allow TCP port 443 and UDP port 3391 traffic to the gateway.

When you connect, look for the connection quality indicator on the Connection bar. If you click it, you should see a message saying that UDP is enabled. If you don’t see either of these two items, you’re not getting the full RDP 8.0 experience and you should check your configuration. If you see both of these, congratulations, you’re on RDP 8.0!

Please do note that while RDP 8.0 for Windows 7 provides many advantages, it has some limitations as well. For more information about these particulars, see KB2592687.

For more information about all the great improvements that come with RDP 8.0, see the following blog posts:

Register for the next Microsoft Jumpstart on April 18: Using Microsoft VDI to Enable New Workstyles

2013-04-04T23:57:48Z

If you are new to the benefits of a Virtual Desktop Infrastructure (VDI), not sure when or why to use session-based or virtual machine-based desktop deployments, or have questions about the architecture (including App-V and UE-V), consider taking the new Jump Start course on April 18, 2013.

This free one-day course will cover the latest approaches to desktop virtualization and the business cases for each, guidance for choosing appropriate virtual desktop types according to requirements, and architectural guidance for building a VDI.

For all the details, see Using Microsoft VDI to Enable New Workstyles Jump Start.

RemoteFX vGPU Setup and Configuration for Windows Server 2012

2013-04-01T17:43:36Z

I’m happy to let everyone know that thanks to Claus Emrich, we now have a TechNet Wiki post about how to set up and configure a RemoteFX virtual graphics processing unit (vGPU) using Windows Server 2012. This guide includes an overview of what RemoteFX vGPU is, what the requirements are, and how to install and configure it.

For all the details, see the RemoteFX vGPU Setup and Configuration Guide for Windows Server 2012.

—The RDS Team

What’s new in Windows Server 2012 Remote Desktop Gateway

2013-03-14T20:51:54Z

Hi, I’m Venkat Bodapati, a software development engineer in Test on the Remote Desktop Virtualization (RDV) team. The purpose of this post is to highlight the key features added and enhancements made in Remote Desktop Gateway (RD Gateway) in Windows Server 2012. To get the most out of this article, you should be familiar with RD Gateway in Windows Server 2008 R2. (For more information about this, see Remote Desktop Gateway Manager).

In this document, I’ll discuss several changes and improvements to RD Gateway in Windows Server 2012, including:

Transport changes to enable the WAN improvements in Remote Desktop Protocol (RDP) 8.0
Management console changes to facilitate using these new protocols
IIS configuration changes
Load balancing changes to complement the new protocols

Transport changes

In Windows Server 2008 and Windows Server 2008 R2, RD Gateway supports only the RPC over HTTP transport. This is the only transport being used when a client makes an RDP connection via RD Gateway from inside or outside the corporate network.

In contrast, RD Gateway in Windows Server 2012 supports three types of transports: RPC over HTTP, HTTP, and UDP. The following table explains which transports are used when a client connects to various RD Gateway server versions.

Client	RD Gateway Server	RD Host	Transport(s) used
Windows 8 Windows 7 SP1 with RDP 8.0 update	Windows Server 2012	Windows 8 Windows Server 2012 Windows 7 SP1 with RDP 8.0 update	HTTP UDP RPC over HTTP (fallback)
Windows 8 Windows 7 SP1 with RDP 8.0 update	Windows Server 2012	Windows XP SP3 Windows Server 2008/R2 Windows Vista Windows 7	HTTP RPC over HTTP (fallback)
Windows XP SP3 Windows Vista Windows 7 without RDP 8.0 update	Windows Server 2012	Any	RPC over HTTP
Windows 8 Windows XP SP3 Windows Vista Windows 7	Windows Server 2008 Windows Server 2008 R2 SP1	Any	RPC over HTTP

The RPC over HTTP transport is for RDP 7.1 and previous clients.
Beginning with Windows 8, Windows Server 2012, the RDP 8.0 update for Windows 7 SP1, and Windows Server 2008 R2 SP1 (KB 2592687), RDP clients always use HTTP as the default transport, falling back to RPC over HTTP if the pure HTTP transport is not available. The HTTP transport uses the Secure Sockets Layer to establish secure connections between the remote desktop client and the remote desktop server through RD Gateway.
When connecting to remote desktop servers running Windows 8, Windows Server 2012, or the RDP 8.0 update for Windows 7 SP1 via Windows Server 2012 RD Gateway, UDP connections may be utilized to improve WAN performance. The UDP transport uses a Datagram Transport Layer Security (DTLS) handshake to establish secure connections between the remote desktop client and the remote desktop server through RD Gateway. For more information, see the blog article RemoteFX for WAN: Overview of Intelligent and Adaptive Transports in Windows 8 and Windows Server 2012.

UDP connections can’t be created as stand-alone; UDP connections are established only after a main HTTP connection has been created between the remote desktop client and the remote desktop server. The following table describes the ports being used by different transports in RD Gateway:

Transport Type	Default Port used
HTTP (includes RPC over HTTP) over SSL	443*
UDP	3391*

*These ports are configurable in the RD Gateway management console.

Management Console Changes

In Windows Server 2012, the RD Gateway server creates three internal connections for each user session: one HTTP connection and two UDP connections. The HTTP connection is used to maintain client communication with the target server, and the two UDP connections are used to support a rich multimedia experience. These three connections can be viewed in the monitoring node of the RD Gateway management console. In the case of Windows Server 2008 R2, only one connection appears for each user session. These changes in Windows Server 2012 will help administrators use the RD Gateway management console to verify that users are able to connect by using appropriate transport protocols.

Administrators can make changes to the HTTP and UDP transport settings by using a new tab called Transport Settings that was added to the Properties dialog box in the RD Gateway management console.

IIS Configuration Changes

In Windows Server 2008 R2, RD Gateway has a strong dependency on Internet Information Services (IIS). Installation of the RD Gateway role creates Rpc and RpcWithCert virtual directories on the IIS default website. It also configures default authentication methods being used to authenticate clients on the IIS server.

In RD Gateway in Windows Server 2012, the IIS configuration is applicable only for clients that are using the RPC over HTTP transport. Any legacy client that requests a connection through RD Gateway in Windows Server 2012 has to use the RPC over HTTP transport. The new HTTP transport doesn’t rely on IIS server; as such, IIS configuration settings will not affect Windows 8 remote desktop clients that request a connection through RD Gateway in Windows Server 2012.

IIS configuration settings continue to be applicable when Windows 8 remote desktop clients request a connection through legacy RD Gateway servers (for example, Windows Server 2008 R2). To use new remote desktop clients with legacy RD Gateway servers, anonymous authentication must be enabled for the IIS default website. Otherwise, client authentication can fail due to the new HTTP transport features. If this is not set correctly, users will observe an error stating that “the logon attempt failed” in the Windows 8 remote desktop client.

Load Balancing Changes

RD Gateway has another important feature called load balancing. The typical load balancing scenario consists of an RD Gateway farm with multiple RD Gateway servers. Previous versions of RD Gateway (Windows Server 2008 R2) support three types of load balancing mechanisms: Hardware, Software, and DNS Round Robin load balancing. All of the RD Gateway servers in the farm are used to load balance the end-user connections based on the traffic.

In Windows Server 2012, RD Gateway doesn’t support DNS Round Robin load balancing when used with the new HTTP transport, because this transport uses two HTTP channels (one for input and one for output) which must be routed to the same RD Gateway server (DNS Round Robin does not guarantee that both connections will be routed to the same server). However, hardware and software load balancers that support IP affinity, cookie-based affinity, or SSL ID-based affinity (and thus ensure that both HTTP connections are routed to the same server) can be used with RD Gateway. Furthermore, the UDP and HTTP connections may be handled by separate RD Gateway servers. Microsoft Network Load Balancing (NLB) supports IP affinity and thus can be used as a load balancer for RD Gateway.

Conclusion

RD Gateway in Windows Server 2012 offers new HTTP and UDP transports designed to allow remote users to take advantage of the WAN improvements in RDP 8.0 outside the corporate network. Take advantage of this support as well as the management console features, IIS configuration, and load balancing to provide a quality, scalable RDP 8.0 experience for your users!

Integrating App-V with Microsoft VDI

2013-03-12T17:37:53Z

Often I’m asked by customers if they should use App-V with Microsoft VDI. The answer is a resounding yes! App-V 5.0 is designed to be easy and efficient to use in VDI environments (both session-based and virtual machine-based desktop deployment), allowing IT to make the best use of expensive disk resources without changing the way they get their jobs done. It lets IT simply choose to turn off local application storage, dramatically reducing disk requirements for VDI while leaving the application provisioning and update process unchanged.

By using App-V with Microsoft VDI IT can achieve higher session densities (incompatible applications can be hosted on the same Remote Desktop Session Host server) and lower storage costs. In addition, App-V can be leveraged across both physical as well as VDI deployments as part of an overall desktop strategy.

Read all about it in the new white paper: Integrating App-V with Microsoft VDI White Paper.

Microsoft VDI vs. VMware View: Freedom of choice

2013-03-06T19:32:52Z

Adam Carter just put up a good blog describing the overall value that session-based and virtual machine-based desktop deployment provides in response to a VMware datasheet.

For anyone considering session-based and virtual machine-based desktop deployment, definitely worth a look.

Windows Multipoint Server 2012 Now Available Including Zero Client Support

2013-02-20T16:51:21Z

I’m happy to announce that not only is Windows MultiPoint Server 2012 generally available, but last week, we added support for USB-Over-Ethernet Zero clients.

Windows MultiPoint Server is a product that uses Remote Desktop Services to offer a tailor-made experience for schools.

Congratulations to everyone who worked on this release.

If you’re interested in evaluating Windows MultiPoint Server 2012, click here.