Performance Tuning Remote Desktop Virtualization Hosts

Remote Desktop Virtualization Host (RDВ Virtualization Host) is a role service that supports Virtual Desktop Infrastructure (VDI) scenarios and lets multiple users run Windows-based applications in virtual machines hosted on a server running Windows Server and Hyper-V.

Windows Server supports two types of virtual desktops: personal virtual desktops and pooled virtual desktops.

General considerations

Storage

Storage is the most likely performance bottleneck, and it is important to size your storage to properly handle the I/O load that is generated by virtual machine state changes. If a pilot or simulation is not feasible, a good guideline is to provision one disk spindle for four active virtual machines. Use disk configurations that have good write performance (such as RAID 1+0).

When appropriate, use Disk Deduplication and caching to reduce the disk read load and to enable your storage solution to speed up performance by caching a significant portion of the image.

Data Deduplication and VDI

Introduced in Windows ServerВ 2012В R2, Data Deduplication supports optimization of open files. In order to use virtual machines running on a deduplicated volume, the virtual machine files need to be stored on a separate host from the Hyper-V host. If Hyper-V and deduplication are running on the same machine, the two features will contend for system resources and negatively impact overall performance.

The volume must also be configured to use the «Virtual Desktop Infrastructure (VDI)» deduplication optimization type. You can configure this by using Server Manager (File and Storage Services -> Volumes -> Dedup Settings) or by using the following Windows PowerShell command:

Data Deduplication optimization of open files is supported only for VDI scenarios with Hyper-V using remote storage over SMB 3.0.

Memory

Server memory usage is driven by three main factors:

Operating system overhead

Hyper-V service overhead per virtual machine

Memory allocated to each virtual machine

For a typical knowledge worker workload, guest virtual machines running x86 WindowВ 8 or WindowsВ 8.1 should be given

512В MB of memory as the baseline. However, Dynamic Memory will likely increase the guest virtual machine’s memory to about 800 MB, depending on the workload. For x64, we see about 800 MB starting, increasing to 1024 MB.

Therefore, it is important to provide enough server memory to satisfy the memory that is required by the expected number of guest virtual machines, plus allow a sufficient amount of memory for the server.

When you plan server capacity for an RDВ Virtualization Host server, the number of virtual machines per physical core will depend on the nature of the workload. As a starting point, it is reasonable to plan 12 virtual machines per physical core, and then run the appropriate scenarios to validate performance and density. Higher density may be achievable depending on the specifics of the workload.

We recommend enabling hyper-threading, but be sure to calculate the oversubscription ratio based on the number of physical cores and not the number of logical processors. This ensures the expected level of performance on a per CPU basis.

Performance optimizations

Dynamic Memory

Dynamic Memory enables more efficiently utilization of the memory resources of the server running Hyper-V by balancing how memory is distributed between running virtual machines. Memory can be dynamically reallocated between virtual machines in response to their changing workloads.

Dynamic Memory enables you to increase virtual machine density with the resources you already have without sacrificing performance or scalability. The result is more efficient use of expensive server hardware resources, which can translate into easier management and lower costs.

On guest operating systems running WindowsВ 8 and above with virtual processors that span multiple logical processors, consider the tradeoff between running with Dynamic Memory to help minimize memory usage and disabling Dynamic Memory to improve the performance of an application that is computer-topology aware. Such an application can leverage the topology information to make scheduling and memory allocation decisions.

Tiered Storage

RDВ Virtualization Host supports tiered storage for virtual desktop pools. The physical computer that is shared by all pooled virtual desktops within a collection can use a small-size, high-performance storage solution, such as a mirrored solid-state drive (SSD). The pooled virtual desktops can be placed on less expensive, traditional storage such as RAID 1+0.

The physical computer should be placed on a SSD is because most of the read-I/Os from pooled virtual desktops go to the management operating system. Therefore, the storage that is used by the physical computer must sustain much higher read I/Os per second.

This deployment configuration assures cost effective performance where performance is needed. The SSD provides higher performance on a smaller size disk (

20 GB per collection, depending on the configuration). Traditional storage for pooled virtual desktops (RAID 1+0) uses about 3В GB per virtual machine.

CSV cache

Failover Clustering in Windows ServerВ 2012 and above provides caching on Cluster Shared Volumes (CSV). This is extremely beneficial for pooled virtual desktop collections where the majority of the read I/Os come from the management operating system. The CSV cache provides higher performance by several orders of magnitude because it caches blocks that are read more than once and delivers them from system memory, which reduces the I/O. For more info on CSV cache, see How to Enable CSV Cache.

Pooled virtual desktops

By default, pooled virtual desktops are rolled back to the pristine state after a user signs out, so any changes made to the Windows operating system since the last user sign-in are abandoned.

Although it’s possible to disable the rollback, it is still a temporary condition because typically a pooled virtual desktop collection is re-created due to various updates to the virtual desktop template.

It makes sense to turn off Windows features and services that depend on persistent state. Additionally, it makes sense to turn off services that are primarily for non-enterprise scenarios.

Each specific service should be evaluated appropriately prior to any broad deployment. The following are some initial things to consider:

Service	Why?
Auto update	Pooled virtual desktops are updated by re-creating the virtual desktop template.
Offline files	Virtual desktops are always online and connected from a networking point-of-view.
Background defrag	File-system changes are discarded after a user signs off (due to a rollback to the pristine state or re-creating the virtual desktop template, which results in re-creating all pooled virtual desktops).
Hibernate or sleep	No such concept for VDI
Bug check memory dump	No such concept for pooled virtual desktops. A bug-check pooled virtual desktop will start from the pristine state.
WLAN autoconfig	There is no WiFi device interface for VDI
Windows Media Player network sharing service	Consumer centric service
Home group provider	Consumer centric service
Internet connection sharing	Consumer centric service
Media Center extended services	Consumer centric service

This list is not meant to be a complete list, because any changes will affect the intended goals and scenarios. For more info, see Hot off the presses, get it now, the Windows 8 VDI optimization script, courtesy of PFE!.

SuperFetch in WindowsВ 8 is enabled by default. It is VDI-aware and should not be disabled. SuperFetch can further reduce memory consumption through memory page sharing, which is beneficial for VDI. Pooled virtual desktops running WindowsВ 7, SuperFetch should be disabled, but for personal virtual desktops running WindowsВ 7, it should be left on.

Supported configurations for Remote Desktop Services

Applies To: Windows Server 2016, Windows Server 2019

When it comes to supported configurations for Remote Desktop Services environments, the largest concern tends to be version interoperability. Most environments include multiple versions of Windows Server — for example, you may have an existing Windows Server 2012 R2 RDS deployment but want to upgrade to Windows Server 2016 to take advantage of the new features (like support for OpenGL\OpenCL, Discrete Device Assignment, or Storage Spaces Direct). The question then becomes, which RDS components can work with different versions and which need to be the same?

So with that in mind, here are basic guidelines for supported configurations of Remote Desktop Services in Windows Server.

Best practices

Use Windows Server 2019 for your Remote Desktop infrastructure (the Web Access, Gateway, Connection Broker, and license server). Windows Server 2019 is backward-compatible with these components, which means a Windows Server 2016 or Windows Server 2012 R2 RD Session Host can connect to a 2019 RD Connection Broker, but not the other way around.

For RD Session Hosts — all Session Hosts in a collection need to be at the same level, but you can have multiple collections. You can have a collection with Windows Server 2016 Session Hosts and one with Windows Server 2019 Session Hosts.

If you upgrade your RD Session Host to Windows Server 2019, also upgrade the license server. Remember that a 2019 license server can process CALs from all previous versions of Windows Server, down to Windows Server 2003.

If you are creating a highly available environment, all of your Connection Brokers need to be at the same OS level.

RD Connection Brokers

Windows Server 2016 removes the restriction for the number of Connection Brokers you can have in a deployment when using Remote Desktop Session Hosts (RDSH) and Remote Desktop Virtualization Hosts (RDVH) that also run Windows Server 2016. The following table shows which versions of RDS components work with the 2016 and 2012 R2 versions of the Connection Broker in a highly available deployment with three or more Connection Brokers.

3+ Connection Brokers in HA	RDSH or RDVH 2019	RDSH or RDVH 2016	RDSH or RDVH 2012 R2
Windows Server 2019 Connection Broker	Supported	Supported	Supported
Windows Server 2016 Connection Broker	N/A	Supported	Supported
Windows Server 2012 R2 Connection Broker	N/A	N/A	Not Supported

Support for graphics processing unit (GPU) acceleration

Remote Desktop Services support systems equipped with GPUs. Applications that require a GPU can be used over the remote connection. Additionally, GPU-accelerated rendering and encoding can be enabled for improved app performance and scalability.

Remote Desktop Services Session Hosts and single-session client operating systems can take advantage of the physical or virtual GPUs presented to the operating system in many ways, including the Azure GPU optimized virtual machine sizes, GPUs available to the physical RDSH server, and GPUs presented to the VMs by supported hypervisors.

GPU vendors may have a separate licensing scheme for RDSH scenarios or restrict GPU use on the server OS, verify the requirements with your favorite vendor.

GPUs presented by a non-Microsoft hypervisor or Cloud Platform must have drivers digitally-signed by WHQL and supplied by the GPU vendor.

Remote Desktop Session Host support for GPUs

The following table shows the scenarios supported by different versions of RDSH hosts.

Feature	Windows Server 2008 R2	Windows Server 2012 R2	Windows Server 2016	Windows Server 2019
Use of hardware GPU for all RDP sessions	No	Yes	Yes	Yes
H.264/AVC hardware encoding (if suppported by the GPU)	No	No	Yes	Yes
Load balancing between multiple GPUs presented to the OS	No	No	No	Yes
H.264/AVC encoding optimizations for minimizing bandwidth usage	No	No	No	Yes
H.264/AVC support for 4K resolution	No	No	No	Yes

VDI support for GPUs

The following table shows support for GPU scenarios in the client OS.

Feature	Windows 7 SP1	Windows 8.1	Windows 10
Use of hardware GPU for all RDP sessions	No	Yes	Yes
H.264/AVC hardware encoding (if suppported by the GPU)	No	No	Windows 10 1703 and later
Load balancing between multiple GPUs presented to the OS	No	No	Windows 10 1803 and later
H.264/AVC encoding optimizations for minimizing bandwidth usage	No	No	Windows 10 1803 and later
H.264/AVC support for 4K resolution	No	No	Windows 10 1803 and later

RemoteFX 3D Video Adapter (vGPU) support

Because of security concerns, RemoteFX vGPU is disabled by default on all versions of Windows starting with the July 14, 2020 Security Update and removed starting with the April 13, 2021 Security Update. To learn more, see KB 4570006.

Remote Desktop Services supports RemoteFX vGPUs when VM is running as a Hyper-V guest on Windows Server 2012 R2 or Windows Server 2016. The following guest operating systems have RemoteFX vGPU support:

• Windows 7 SP1
• Windows 8.1
• Windows 10 1703 or later
• Windows Server 2016 in a single-session deployment only

Discrete Device Assignment support

Remote Desktop Services supports Physical GPUs presented with Discrete Device Assignment from Windows Server 2016 or Windows Server 2019 Hyper-V hosts. See Plan for deploying Discrete Device Assignment for more details.

VDI deployment – supported guest OSes

Windows Server 2016 and Windows Server 2019 RD Virtualization Host servers support the following guest OSes:

• Windows 10 Enterprise
• Windows 8.1 Enterprise
• Windows 7 SP1 Enterprise

• Remote Desktop Services doesn’t support heterogeneous session collections. The OSes of all VMs in a collection must be the same version.
• You can have separate homogeneous collections with different guest OS versions on the same host.
• The Hyper-V host used to run VMs must be the same version as the Hyper-V host used to create the original VM templates.

Single sign-on

Windows Server 2016 and Windows Server 2019 RDS supports two main SSO experiences:

• In-app (Remote Desktop application on Windows, iOS, Android, and Mac)
• Web SSO

Using the Remote Desktop application, you can store credentials either as part of the connection info (Mac) or as part of managed accounts (iOS, Android, Windows) securely through the mechanisms unique to each OS.

To connect to desktops and RemoteApps with SSO through the inbox Remote Desktop Connection client on Windows, you must connect to the RD Web page through Internet Explorer. The following configuration options are required on the server side. No other configurations are supported for Web SSO:

• RD Web set to Forms-Based Authentication (Default)
• RD Gateway set to Password Authentication (Default)
• RDS Deployment set to «Use RD Gateway credentials for remote computers» (Default) in the RD Gateway properties

Due to the required configuration options, Web SSO is not supported with smartcards. Users who login via smartcards might face multiple prompts to login.

For more information about creating VDI deployment of Remote Desktop Services, check out Supported Windows 10 security configurations for Remote Desktop Services VDI.

Using Remote Desktop Services with application proxy services

You can use Remote Desktop Services with Azure AD Application Proxy. Remote Desktop Services does not support using Web Application Proxy, which is included in Windows Server 2016 and earlier versions.