RemoteFX and a Rich RDP Experience

All Windows OSs use RDP for remote connectivity. As a greater percentage of users have become mobile, the devices used to connect to remote workspaces have become more diverse and the expectations of users for a rich, high-fidelity, completely remote experience have increased. To keep pace with the increased importance of a rich remote experience, native RDP has evolved by leaps and bounds in the past few generations.

RDP 7.0, which was released as part of Windows Server 2008 R2 and Windows 7, has an awesome feature set, including the following:

For the Aero Glass experience and rich multimedia playback, RDP uses remoting and essentially redirects the desktop composition and graphics/audio rendering from the remote session to the local client, taking advantage of the local client’s capabilities and resources to provide a great experience. For example, instead of a Windows Media Video (WMV) file being rendered on the remote server and the bitmap screen updates being sent over UDP for display on the local client, with Windows Media Player remoting, the data contained in the WMV file (the primitive) is sent over RDP to the local client. The local client then performs the decoding and rendering of the WMV file, saving a lot of bandwidth and providing very smooth playback because we aren’t sending a huge amount of screen updates over the network.

This means when I connect to my remote session from a rich client, such as a Windows 7 desktop, I get a pseudo-local experience, with full graphics fidelity. However, if I connect from a more basic client that doesn’t have Aero support or multimedia redirection, I don’t get any of the Aero experience. In addition, media playback isn’t as smooth because it’s rendered on the remote desktop, giving a far more basic experience and likely the dreaded jagged playback. This is true when connecting to a session-based solution, such as a Remote Desktop (RD) Session Host server, or a virtualized client OS solution, such as a Windows 7 Virtual Desktop Infrastructure (VDI) environment. RemoteFX solves this inconsistency by giving a consistent end-user experience regardless of the capabilities of the end client.

What Is RemoteFX?

RemoteFX was introduced in Server 2008 R2 SP1 and actually consists of three technologies that are aimed at VDI environments running Hyper-V 2008 R2 SP1–enabled servers, with Windows 7 SP1 running as the client OS in the virtual machines (VMs). The great news is that RemoteFX is available in both Server 2008 R2 SP1 and the free Microsoft Hyper-V Server 2008 R2 SP1 server OS. This free OS is commonly used in VDI implementations because you don’t need the server virtual guest rights that exist in the Enterprise and Datacenter editions if you’re running a client OS–only virtualized environment.

RemoteFX actually evolved from technologies first created by Calista Technologies and acquired by Microsoft in 2008. These technologies focused on providing a richer thin-client experience and are now part of the core Windows platform.

Virtualized GPU. RemoteFX consists of three technologies, one of which provides the ability to virtualize the graphics processing unit (GPU) in the server and make these virtual GPUs available to the VMs running on the Hyper-V server. The virtual GPU allocated to the VM can be leveraged by the Windows 7 SP1 guest OSs running in those VMs. Windows 7 SP1 includes updated integration services, which lets guest OSs see the virtualized GPU and use it without additional software installation. This means the virtual Windows 7 SP1 guest now sees a full-featured GPU, which allows advanced graphics to be rendered server-side.

The screen output is then sent to the RDP client for display, including server-side rendering of Aero effects, multimedia, and other types of media and applications not previously possible, such as Adobe Flash and Microsoft Silverlight and DirectX applications. Because all the rendering is performed on the Hyper-V server within the VM, the actual client capability no longer matters. You can connect from a full, rich client or a basic thin client; the experience and graphics fidelity will be the same because all the graphics processing can be done server-side. The only requirement is that the end client must support RDP 7.1, which was introduced in Windows 7 SP1 and includes RemoteFX support.

After a client VM is RemoteFX enabled and is connected to from a RemoteFX-capable client, it will appear as if the VM actually has a GPU and an amount of graphics memory based on the RemoteFX configuration for the VM. Running DxDiag on the client will show the presence of a Windows Display Driver Model (WDDM) graphics driver and the Microsoft RemoteFX Graphics Device along with support for DirectDraw, Direct3D, and AGP texture acceleration, as Figure 1 shows. The initial RemoteFX release supports DirectX 9.0c.

Figure 1: Running DxDiag from within a RemoteFX-enabled Windows 7 SP1 VM

DirectX support in the virtualized OS is very important. Many applications and services leverage DirectX, such as Silverlight, Internet Explorer (IE) 9.0, and even Microsoft PowerPoint 2010. With the availability of DirectX in remote environments, most of the previous restrictions regarding the type of applications that can be run are eliminated. In addition, applications now run with full fluidity; because all the rendering is performed server-side, the client you’re using has no relation to what you can do. For example, you can be on a basic client that supports RemoteFX, and in that remote session you can be running Flash, Silverlight, and pretty much any other content. The only limitation you’re likely to encounter regarding DirectX is the amount of graphics memory that’s visible to the VM, which is based purely on the resolution and number of displays you configure the VM with—which I cover later in the article.

A question that often comes up is whether multimedia redirection is still performed with RemoteFX. The answer is that multimedia redirection is still used if you have a rich client that has multimedia rendering capabilities. If you can leverage local processing capabilities and reduce the server’s processing load, you should do so; however, the key point is you’ll get the same experience regardless of whether your client supports multimedia redirection—but the rendering will be performed on the server rather than the client.

Another common question is whether OpenGL is supported. OpenGL is still used by certain applications. Although RemoteFX does support OpenGL, support is limited to OpenGL 1.1, which is provided out of the box in Windows. This version is quite old. Of course, we’d love to see more up-to-date OpenGL support in a future version of RemoteFX.

Because the GPU is virtualized, we don’t need a discrete GPU for every VM that will be RemoteFX enabled. Just like CPU virtualization, in which a single logical CPU (such as a core) can be mapped to many virtual CPUs, a GPU can be virtualized to as many as 12 virtual GPUs, allowing great scalability. One key consideration when we virtualize the GPU is the amount of graphics memory each VM will need. You can’t overcommit GPU memory; therefore, to achieve the 12:1 ratio, you need to ensure that the graphics card has sufficient video RAM for all the VMs.

Server-side rendering of advanced graphics content is great, but it also means that more screen update data will need to be sent over the network to the client for display—especially with all the additional graphics-intensive applications that are supported. To ensure a good client experience, RemoteFX is supported only for LAN connections in the initial SP1 release. This ensures enough bandwidth and low latencies. If you select any connection speed less than LAN (10Mbps or faster) on the Experience tab of the Remote Desktop Connection client, then RemoteFX will be disabled.

New codec. Even if you ensure that RemoteFX is used only on LAN connections, you’ll still experience a lot of screen updates and therefore bandwidth usage. The second part of the RemoteFX technology package is a new codec that was designed to efficiently encode and decode the display updates associated with the more intensive RemoteFX-enabled workloads. This is the only part of RemoteFX that’s available to RD Session Hosts, formerly known as Terminal Servers. A Server 2008 R2 SP1 RD Session Host can take advantage of the new RemoteFX codec for encoding of the screen updates. Separate hardware encoder modules are available for offloading of the encoding work.

Enhanced USB redirection. The final piece of the RemoteFX technology, enhanced USB redirection, is often overlooked. However, this feature truly completes the ability to have a full-featured remote desktop experience by enabling the redirection of basically any USB device from the local client to the remote session.

Prior to the RemoteFX USB redirection feature, there were advancements in the type of devices that could be redirected to a remote session—for example, keyboard, mouse, microphone, smart card, disk, imaging devices with Inbox-type functionality, and a few others that can be redirected. However, these devices are all redirected by abstracting the device into one of the supported high-level RDP redirection device types. This means we can access these devices on the remote session without needing any drivers on the remote OS installed, but it also means we might miss device-specific functionality. In addition, many types of USB devices can’t be redirected if they don’t fall into these high-level types, such as multi-function printers, advanced communication devices, scanners, barcode readers, USB foam missile rocket firing devices, and many more.

RemoteFX’s USB redirection solves this problem by actually redirecting at the USB port level in a similar way to how RDP handles redirection of serial and parallel ports. With RemoteFX USB redirection, the actual USB request blocks (URBs) are intercepted from the client and sent to the remote session. Thus, basically any type of USB device can be redirected using the RemoteFX USB redirection feature; however, this doesn’t mean you shouldn’t continue to use RDP high-level device redirection for supported devices. RemoteFX USB redirection is designed to supplement RDP high-level device redirection to add support for devices that don’t work with the standard RDP.

For RDP high-level supported device redirection, such as input (keyboard/mouse), audio, drive, smart card, port, printer (RDS Easy Print), and Plug and Play (PnP), optimized protocols are used for each of the redirection types to minimize bandwidth usage and to ensure the best responsiveness and optimal experience for that type of device. In addition, RDP high-level device redirection doesn’t require extra drivers in the remote session, and multiple remote sessions can access the same local device simultaneously. Because of these optimizations, RDP high-level device redirection can be used in both LAN and WAN environments.

Next, consider RemoteFX USB redirection in which you’re redirecting at the USB port level to the remote session. Because the port is being redirected, no device- or load-specific optimizations can be made. In addition, the device driver must be installed in the remote session because on the remote session it will look as if the device has been plugged in to a virtual USB port, so it needs the driver to use the device. Also, because we’re redirecting at the port level, only one session can access a device at a time, including the local client. Therefore, if you redirect a device using RemoteFX USB redirection from your local client, no other session can see the device, nor can your local client. (So, make sure you don’t try to RemoteFX USB redirect your keyboard!) RemoteFX USB redirection is also optimized for LAN environments and can’t be used on WAN connections.

Figure 2 shows several devices that I can use RemoteFX’s USB redirection capability to redirect. I couldn’t have used standard RDP to redirect all these devices. This powerful feature means I can have pretty much any USB device available in my remote sessions after I install the driver. Combined with high-level RDP redirection, RemoteFX USB redirection provides a great experience.

Figure 2: RemoteFX exposes your USB devices as candidates for redirection to a remote session

By default, RemoteFX USB redirection is disabled on clients. You can enable it through a local policy or through Group Policy. Navigate to Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Connection ClientRemoteFX USB Device Redirection, and set the Allow RDP redirection of other supported RemoteFX USB devices from this computer option to Enabled. Next, select the option to indicate who has RemoteFX USB redirection rights—either administrators only or administrators and users. Finally, click OK and close Group Policy Editor (GPE). After the policy change takes effect, the option to redirect RemoteFX USB devices will be available in the Remote Desktop Connection client.

Although RemoteFX USB redirection doesn’t use any GPU resources, it’s closely tied to the RemoteFX experience and can’t be used with RD Session Hosts or a non-RemoteFX–enabled Windows 7 SP1 VDI VM. If you want RemoteFX USB redirection, you need GPUs in your Hyper-V servers and must enable your VMs for RemoteFX.

RemoteFX Requirements and Usage

This all sounds great; we have a consistent high-fidelity graphics experience regardless of the client resources, the ability to run advanced graphics applications using server-side rendering, efficient use of bandwidth, and redirection of any USB device to the remote session. So how do we actually obtain access to RemoteFX capabilities?

First, you need to know which versions of Server 2008 R2 SP1 support RemoteFX. Server 2008 R2 SP1 Standard, Enterprise, and Datacenter full installations all support RemoteFX, in addition to the Server Core–based free Hyper-V Server 2008 R2 SP1. Server Core installations of Server 2008 R2 SP1 don’t include RemoteFX; as I noted, you need to be running a full installation of Server 2008 R2 SP1 or the free Hyper-V Server 2008 R2 SP1 if you want Server Core (which is the version of Windows you’d typically be running for VDI environments anyway).

What about hardware? Remember that we’re virtualizing the GPU in the server and making virtual GPUs available to the VMs that actually perform the server-side graphics rendering. Therefore, the first requirement is to have a GPU in the Hyper-V server. This GPU must support both DirectX 9.0c and DirectX 10.0 and have dedicated video memory. In addition, if you have more than one GPU in a Hyper-V server, the GPUs must be identical. The amount of memory required will vary depending on the number of VMs you plan to RemoteFX enable.

Figure 3: Enabling RemoteFX functionality on a Windows Server 2008 R2 SP1 server

Enabling RemoteFX on a Hyper-V server is very simple as long as the server meets all the requirements. RemoteFX is part of the Remote Desktop Services role, so to enable RemoteFX we use Server Manager and enable the RemoteFX role service, which is a component of the Remote Desktop Virtualization Host role service, as Figure 3 shows. You need to reboot to complete the installation. If you’re running the free Hyper-V server, you can use the following PowerShell commands to enable RemoteFX:

Import-Module ServerManageradd-windowsfeature -name RDS-RemoteFX

After RemoteFX is installed on the server, you need to enable a VM for the technology. To do this, use Hyper-V Manager to view the VM settings. Under Add Hardware, select the option to add a RemoteFX 3D Video Adapter and select the maximum number of monitors and the maximum resolution. These settings are used to calculate how much video RAM should be assigned to the VM, as Figure 4 shows. The more monitors you assign to a VM, the lower the maximum resolution. Table 1 shows the combinations possible for number of monitors and resolution, as well as the amount of video RAM assigned. For more information about performance counters related to RemoteFX, see my FAQs “Exactly how much GPU memory is allocated to a virtual machine (VM) based on the number of monitors and resolution set?” and “Are there any performance counters to monitor the performance of RemoteFX?”.

Figure 4: Setting the number of monitors and maximum resolution

Note that you don’t have to use all the monitors configured for a VM or the maximum resolution; this information is used for the video memory assignment so the VM can support the configured number of monitors and resolution if needed. Also notice that we max out at 330MB. If you have an application that requires more graphics memory than 330MB, RemoteFX isn’t the right solution for you (yet). Enabling RemoteFX uses an additional amount of normal system memory for each VM, which varies based on the number of monitors and the resolutions. The amount of video RAM a server needs depends on the number of VMs you RemoteFX enable and the number of monitors and resolution configured for each.

Beyond just the GPU and video memory, you should be careful about video card and driver selection. Although a consumer graphics card might work fine in a lab environment for a single VDI client just to play around with RemoteFX, for production environments with multiple VDI-enabled VMs you need professional-grade GPUs. Equally important is the WDDM GPU driver. To help make the GPU selection easier, Microsoft started a RemoteFX certification program for the GPU and driver to help find a GPU that will deliver a great RemoteFX experience. For information about RemoteFX partners, see the Remote Desktop Services (Terminal Services) Team Blog. One problem you might run into on your servers is that the installation of the required WDDM driver might break the use of remote baseboard management controllers that need XDDM drivers. For a solution to this issue, see my FAQ “I use a DRAC/ILO to manage my Hyper-V server but since enabling RemoteFX on the server the DRAC/ILO no longer works. Why not?”.

Today, many servers don’t have GPUs or even PCI Express slots suitable for installing a GPU. This oversight makes implementing RemoteFX difficult. In the future, more server hardware partners will be releasing servers with multiple GPUs and PCI Express slots specifically to enable GPU virtualization for VDI implementations.

Another requirement to enable RemoteFX is that the processor must support Second-Level Address Translation (SLAT), which is known as Extended Page Tables (EPT) by Intel and Nested Page Tables (NPT) by AMD. Although not a requirement, RemoteFX encoders can also be installed on servers to offload some of the RemoteFX encoding and increase a server’s scalability. (I discussed this topic earlier in the article in reference to using the RemoteFX codec with RD Session Hosts.) Another RemoteFX requirement is that the OS running in the VM must be Windows 7 Enterprise SP1 or Windows 7 Ultimate SP1.

The final requirement is the client itself—that is, the device with which you connect to the RemoteFX-enabled VM. The client must support RDP 7.1 and RemoteFX. Although obvious choices such as Windows 7 SP1 work great as clients, as does the new Microsoft Windows Thin PC, a whole new generation of thin clients are being released that are very small in form factor but have full RemoteFX support, providing a great end-user experience with hardly any hardware footprint and minimal power use.

The Best Is Yet To Come

RemoteFX is an awesome technology that totally changes the capabilities available to users connecting to Microsoft VDI environments and eliminates many of the past restrictions. Although the hurdle of no GPUs in servers might be an initial challenge, this obstacle will be overcome with new server lines being released in the future. In addition, RemoteFX is only in version 1.0; I expect the technology to improve with age.

For information about enabling RemoteFX in a Windows 7 SP1 VM, check out my FAQ “How do I enable RemoteFX for my Windows 7 guest OSs?". See Microsoft’s RemoteFX page for some performance tweaks. Finally, see RemoteFX in action at my video page on SavillTech.com.