We've been writing about RemoteFX for over a year now, although most of the focus has been using it to connect to Windows 7 VMs running on Hyper-V for VDI scenarios. But did you know that you can also use RemoteFX to connect to Remote Desktop Session Hosts (Terminal Server)? And did you know that it's actually really, really cool?
As a matter of fact, using RemoteFX to connect to Terminal Server sessions might turn out to be even better than connect to Terminal Server sessions via pure RDP!
As a quick re-cap, in order to use RemoteFX for VDI scenarios, your desktop VM must be Windows 7 SP1 running on Hyper-V 2008 R2 SP1. In that scenario you also need to install a graphics card with a GPU in your Hyper-V server. (Microsoft uses the GPU to do the RemoteFX compression.)
Now if you want to connect to a "traditional" Terminal Server with via RemoteFX, here's what you need to know:
First of all, your Terminal Server (err, Remote Desktop Session Host) has to be running Windows Server 2008 R2 SP1. But if you're using Terminal Server, you do NOT need to have a GPU installed on the server. (To repeat: You do not need a GPU in your server to connect via RemoteFX to a Terminal Server.) In fact a using a GPU on a Terminal Server is not even supported, so if you do have one it's not even used.
From the protocol standpoint, if you enable RemoteFX on a Terminal Server, the RemoteFX protocol is 100% identical to a VDI instance running on Hyper-V using RemoteFX with a host-side GPU. If you look at the wire with a network sniffer, it will look the same either way. That means that the client devices that Microsoft supports are the same either way, (which is either a Windows 7 SP1 client, a new Windows 7 embedded client, or a Windows 7 TPC client running the 7.1 version of the Remote Desktop client, or a thin client with the RemoteFX-specific ASIC chip in it).
In the case of a Terminal Server running RemoteFX, you'll actually have an increase in CPU usage on the server since you can't offload the RemoteFX encoding to the GPU. (The exact amount of the increase will vary depending on your workload.) However, the actual traffic over the network will decrease since you're spending more effort on the host encoding and compressing the traffic. You'll also typically end up with a better user experience because of this! (That's right! A Terminal Server running RemoteFX with the CPU-based encoding will typically provide a better overall user experience than a non-RemoteFX RDP session!)
There are a few downsides though. First, RemoteFX running on a Terminal Server does not work with Aero. This is because the RemoteFX encoder actually installs a fairly generic non-WDDM capture driver that just doesn't support Aero. [TECHNICAL UPDATE: My explanation for why Aero won't work on a Terminal Server was wrong. It's not that RemoteFX installs a non-WDDM driver, it's that the RemoteFX driver (which is WDDM) is designed to be used with the vGPU you get by running a Win7 host on Hyper-V. Since Terminal Server has no Hyper-V vGPU, that driver won't work, so RemoteFX actually doesn't install a driver. "Ok," you might be thinking, "So RemoteFX itself doesn't actually enable Aero, but you can already use Aero with RDP 7.0 running from a Win7 client connecting to a RD Session Host on 2008 R2. That's been around for awhile, so why can't you just use Aero in that way?" Microsoft engineers explained that the Aero remoting in regular Session Host is done via some other compositing called Media Infrastructure Layer remoting where the Aero components are intercepted in a different way than the actual contents of the windows. Unfortunately since RemoteFX captures the entire screen via a video driver on the host, if that video driver doesn't support Aero, then RemoteFX can't see Aero.]
Also, on Terminal Server you will NOT get the USB device redirection features of RemoteFX that you get when using it to connect to a VDI desktop.
On the plus side, Microsoft has announced that certain partners will eventually release host-side hardware-based RemoteFX encoder cards that will offload the RemoteFX encoding. Those cards will work with both RemoteFX for Win7 VDI VMs on Hyper-V and Terminal Servers with no GPUs. Microsoft isn't talking about those cards too much today, but we can assume that they'll both lower the overall CPU load and provide a better overall user experience.
Second, since using RemoteFX on a Terminal Server today doesn't use (and cannot use) a GPU, that means that a Terminal Server running as a VM will work with RemoteFX. And actually this will work (and will be supported) on ANY hypervisor -- not just Hyper-V.
Third, since RemoteFX is just an enhancement to the existing RDP protocol stack, you're also able to leverage the other RDP features with it such as multimedia redirection. Time will tell whether it's better to go this route versus just letting RemoteFX handle everything, but it's nice to know that it's an option.
In case you're wondering, the unofficial reason that RemoteFX will work with a Terminal Server natively is actually related to Microsoft MultiPoint Server. The story is that in order to get the ASIC-based MultiPoint thin client cost point as low as possible, Microsoft had to enable RemoteFX for Terminal Server. (MultiPoint is based on Terminal Server.)
Also interesting is the fact that since Terminal Server can use RemoteFX without a GPU and running as a VM on any platform, it's theoretically possible that you could have RemoteFX-based VDI on any hypervisor if you ran your Windows VM guests as single-user Terminal Servers instead of Windows 7. (I'm not sure whether that's practical, but it's definitely possible.)
The bottom line is that while RemoteFX has been generating a lot of buzz for the VDI use case, those requirements are fairly steep while the use case is fairly small. But using RemoteFX for Terminal Server? That might actually turn out to be pretty huge!
One question that still remains: We know Citrix will release a version of XenDesktop that will support RemoteFX (when running on Hyper-V with a GPU). But will XenApp also support RemoteFX when running on bare-metal without a GPU? And will this provide a better user experience than what XenApp can provide natively? Stay tuned...