Can you connect to a Terminal Server via RemoteFX? Yes! (Here's what you need to know.)

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)?

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...


Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

We've been playing with RemoteFX (both vdi and session host) since the early beta days (both running on Hyper-V) and performance of session host RemoteFX is stunning. for 90 - 95% of our average workloads/apps it's awesome. Everything from flash, silvershite to manipulating images in Word/Visio. Remote/seamless apps also work nicely. Looking forward to vWowkspace 7.2 MR1 and what that brings to the table.

I really want to know why we can't have RemoteFX non-gpu for standard win7 VM's!?

Your right... RemoteFX for TS will be huge and allow TS to reach more use cases.


Wow. That's great news and a great question. I'll forward it on to Microsoft, although I'm sure they'll say you can't use RemoteFX on standalone Win7 because they want to push Hyper-V... Although that's kind of a *** move if it's true.


Great question Brian, I've been wondering this for some time now... It'll take a voice as loud as yours to get an answer I suspect :)



I know it's not in their nature, but maybe Microsoft dont want to piss citrix off either?

A very capable remoting protocol, which might challenge ICA, allowing direct connect to a Win7 desktop would be a big blow to the Citrix 'broker' model!!



I don't think that is the case... MS still need their partner echo system, Quest, Citrix and Co to add value to their stuff. Quest and Citrix will be doing a lot in the RemoteFX space. It's in their interests to engage and embrace.

The non-Citrix partners NEED MS to do something because they have no option or it would upset MS that their competing against RDP if they came up with their own alternative.

I also agree with Brian in that RemoteFX is ultimately about the Xbox... Thought that when Calista were purchased... If that is true then they wont give a $*it about Citrix as that is minimal $$$ compared to their gaming revenue. All this desktop remote graphic nonsense is R&D work for them and we're their guinea pigs!  :)

@Brian Ask them about XP end-point/client support for RDP 7.1(remotefX) too! XP isn't going anywhere just yet for most and I can't think of anyone who would update both front and back ends. For those who went down the XPe thin client route.... Wont be happy as they think that investment is good for another 3 - 5 years!


@DanielBolton how's the bandwidth consumption and WAN performance?


@appdetective can't give you any hard facts at present - at home (will post our findings from RC1 tomorrow/Monday) but I can say... From a GPU/RemoteFX setup, bandwidth consumption is pretty big and WAN performance sucks considering we have a 1GB up/down link and I have a pretty decent broadband connection. However it's not a fair test as our crappy VPN box throttles bandwidth and I can't put the connection through vWorkspace (until 7.2 MR1). I don't like using WAN emulation tools - they never EVER represent real life situations.

RemoteFX for TS/RDSsh works very over our crappy VPN connection - no complaints. I'll get DUmonitor or something installed on a machine at home this weekend and do some tests. I'll disagree with Brian, it does use more bandwidth (only just) than traditional RDP on average but I've not tested the final build of SP1 - might have our test rig re-installed tomorrow or Monday to see if that makes any difference.

The EOP Xtream stuff from Quest will be tested as soon as I can. - Expecting some good results.

One thing to add... Bandwidth for RemoteFX can be an odd beast as it captures ALL so depending on what's going on, screen rez, etc, all have to be factored in. I will do some bandwidth tests ASAP based on the different resolution with a set of pre-defined "workloads" and post the results. Not done ANY testing with the USB redirection feature or bi-directional audio regarding bandwidth yet - solitaire MS Paint work well.

Yes I'm a Quest fanboy - they have recently published a white paper on what EOP can do for RemoteFX - interesting stuff non-the less.

Any particular result your looking for? - I can always redo some tests if needed.


Forgot to say - GPU mode sucks of a decent CISCO wireless network too!

Que Ericom Blaze employee sales pitch!


Hey Brian. Yes, RemoteFX opens up some great possibilities. I had one comment on this line in your article: "the actual traffic over the network will decrease since you're spending more effort on the host encoding and compressing the traffic"

The process for encoding the graphics display in RemoteFX and "traditional" RDP are quite different - RDP previously used a lot of graphics primitives from the GDI layer in Windows to deliver a highly efficient WAN-friendly protocol. ICA/HDX does the same. RemoteFX works at a higher level and compresses the bitmaps as they are generated by Windows, which is why it typically uses more bandwidth. The same is pretty much true for PCoIP.

RemoteFX is fantastic for LAN and (with a little help from vWorkspace) high-bandwidth WANs, since it can remote graphics displays very efficiently that have rich media, e.g. Aero, Silverlight, Quicktime, WPF apps, whatever ... But it generally will use more bandwidth than RDP 7.0, especially if Aero is disabled, because it's compressing bitmaps and not "drawing instructions".

I wrote a blog post on this topic last year:


@Jon Rolls, thanks for that link. I missed that post the first time around. :)

As for the statement about RemoteFX taking less bandwidth (depending on workload), I agree 100% with your comment, and it would make sense that RemoteFX would take way more since it's essentially sending a movie of the entire screen.

But that lower bandwidth statement was definitely something that Microsoft said this week. (And I haven't tested the RTM myself yet.) I wonder if they're talking about specific use cases where RDP wouldn't be so great, like lots of changing non-redirect-able media?

I'll follow up with them now, because I think your comment is right.. Nice catch!


I threw up a hyper-v guest the other day and installed 2008r2sp1 on it and set it up as an rdsh.  works pretty well from what I can tell in 10 minutes of testing.  Have a demo with Quest tomorrow to look into vWorkspace and let them have a crack at trying to win us away from xenapp :-)

Very much looking forward to what the next 6 mo will bring - Brian do you have any more info on the hardware asics for rdsh servers?  I can't find any info anywhere...




@Daniel Bolton I'm just trying to get a sense of efficiency on the wire from somebody who is smart such as yourself. I don't believe RemoteFX will perform on the wire to a level that is practical for my use case for years if ever. Hence I think a lot of hype that will lock you into hyper-v. It would also be good to understand from anybody if MS is doing anything to make Hyper-V better for desktop virtualization.  How well does it scale etc?

As a result I don't bye anything Quest says either when it comes to real enterprise scale for desktops on Hyper-V. I just don't see how they can really innovate long term to make RDP/RemoteFX better when they don't control the protocol. Where is the IP in what they do? I get it's a price thing for you, but there are tons of options in that bracket, Ericom, Kaviza, Virtual Bridge for example.  As a result I don't trust MS to lock me into hyper-V, app-v etc when they themselves are not committed to desktop virtualization and hence why I also dislike the Quest message.


Perhaps a good question for the @Brian's of the world to ask is, who at MS gives a crap about RemoteFX outside of the RDS team who are not part of the Windows7 team? Until the core Windows team embraces desktop virtualization, this is just a toy industry for MS who has bigger fish to fry in mobile I.e be number 3 at least, search, gaming, protect office, protect Windows client revenue stream with upgrade to Window 7, Hyper-V in the cloud and more cloud whatever they are thinking. Desktop Virtualization is only a few billion dollars in total market size. That's tiny compared to their current desktop franchise, pales compared to the external threats so this is simply not interesting to them and the only reason they let Citrix/Quest do what they do. Only people in our tiny industry give a damn about this stuff, the average Windows guy I bet does not care or know and I think MS understands this and why RDS and VDI will remain stepchildren left to the ecosystem to solve for.


Hi Brian, in my Lab Test RemoteFX Work with Aero Desktop with Terminal Server Session.

I've install Desktop Experience feature on my Windows 2008 R2 Sp1 Server...


@Gabriele,Your environment is with a GPU. The statement in the article is about using a Terminal Server with no GPU and RemoteFX. (Because with regular RDP, you can still use Aero with a Terminal Server.)

However I thought Microsoft was very clear that a GPU would not enable Aero to work on a Terminal Server because the ability to share it isn't there. But maybe it's not that it won't work, but that Microsoft just won't support it.

I believe the problem has something to do with locking.. some apps request exclusive access to the GPU and on a Terminal Server that would lock out other sessions from those apps.. But if you just want it for Aero, maybe that's ok?

Gabriele, just to confirm since your article is in Italian.. did you have a bare-metal Terminal Server with a GPU running 4 separate sessions via RemoteFX with Aero? Are you sure your sessions were using RemoteFX?


yes Brian, one terminal server 2008 sp1 baremetal installation,(Acer Veriton 490G  Intel® Core™ i3-550 (4M Cache, 3.20 GHz) - 4GB DDR3, 500GB 7200PRM SATA II - VGA Intel® Graphics Media Accelerator X450).

4 RDP session from Windows 7 Professional, Aero and Media Player with DIVX play !


4 RDP session from Windows 7 Professional 64bit, Aero and Windows Media Player with play DIVX.

CPU load is between 8-10% from server taskmanager


Have you seen any information regarding client-side GPU offload?  i'm having a tough time finding info on that.

Also, any idea if all these features will be available in the recently announced WinTPC?


We have some RemoteFX VDI and RDSH thin client ASIC decoder demo's here

We are quite impressed with the RDSH performance, considering this is generation one of the ASIC decoder...


Great article! After reading and re-reading, it appears that we could also run RemoteFX on a physical machine Remote Desktop Session Host - am I correct? I've been trying every which way to enable a RemoteFX session on our physical RDSH without any luck.

Does the RDSH have to be virtual or can it be physical?


@appdetective – wouldn’t say I was smart more fluky :)

Having had our dev RemoteFX lab re-installed (this morning) to the final SP1 release and carried out some initial (while eating steak pie) remote RDSsh tests, I can safely say RemoteFX by itself needs a GOOD WAN connection if it is going to succeed without the likes of Quest, Citrix, etc. Using my 15/2 connection at home it was going from 344kb/sec to 6mb/sec depending on what I was doing and screen rez. For example typing a line or two in word used little BW but scrolling up and down caused choppy performance – the sort of performance I wouldn’t let my users suffer. In fairness standard RDP doesn’t to much better from a performance point of view. This was out of the box RemoteFX – no experience settings altered server side, etc.

GPU enabled RemoteFX went as high as 12mb/sec and was unusable.

Response time was 18 – 22ms in both situations.

Both VDI and RDSsh on the LAN with 0 – 3ms using 100MB to the end-point produced perfect results. - Same sort of BW usage

In summery so far – LAN only without 3rd party molestation and magic WAN fairy dust.

Still a fan and never looked at it as a WAN solution with initial release. If the end-point doesn’t support RFX decoding then standard RDP is used (just making sure it’s not all or nothing). More testing to do for consistency!

RE: Quest – without going off topic too much.... We use Virtual Bridges for our Linux VDI deployment... Costs more than XenDesktop! I was stunned when I found out. Quest gives me the best flexibility to choose VDI, physical, RDSsh and the ability to power the hosts on any hypervisor I see fit or to put it another way which ever hypervisor is the best fit and more sustainable for a given use case. I wouldn’t say Quest have any sort of MS-lock in messages either.



Physical or virtual (as long as min requirements are met)

Have you enabled the RemoteFX experience setting - gpedit?



I am going by Microsoft's checklist ( ) and on Step 4 I am tweaking settings (including RemoteFX Experience in gpedit) and looking for Event ID 2 in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Admin event log.

The only step I cannot seem to perform is on Step 3 - Installing the RemoteFX 3D Video Adapter - because it seems to rely on settings on a virtual machine, which I am doing a physical implementation.

Can you point me to a reference for what I am trying to accomplish? I know this is not exactly the forum for "Tech Support", but thank you anyway. :)



You want:

That's the one for RDSsh - your link was for hosted desktops using a physical GPU.


@Gabriele - I don't think your setup can be running RemoteFX and Aero. As brian and MS say, this is not supported. Almost certainly it is just MIL (and Video) remoting. Do you see the RemoteFX events in Event Viewer when you connect?


Not sure why there are the repeated references to the thinlinx. A hardware asic puts you straight up against the Teradici (PCOIP) asics.

The issue with these is always that you never get a support or life cycle commitment beyond future versions of the protocol. A software solution will offer better flexibility and todays CPUs are more than able to handle the decompression.

This was blogged on here:

Having looked into this in more detail IGEL also offers full ICA, PCOIP, vWorkspace and SPICE support in a single firmware package.


@Brian have been too busy sipping coffee at Starbucks as Aero Glass remoting over RDP have been there from day one in 2008 R2 and WIndows 7. That Citrix still doesn't support this on XenApp/XenDesktop is something completly else.

Do some googling and hey! there!



The issue is not about using Aero with TS, and yeah that's been a feature since 2008. The question is whether he's using Aero via RFX on TS, which is not possible.


@Brian, yeah you're right. I guess I just mixed up and forgot. Sorry for the blunder on my part :(


I've enabled RemoteFX on my with VMware virtualized RDSH following the guide from Microsoft (

But RemoteFX is not working and I'm not seeing the EventID 1000 and 1001 appear in my eventlog. What's going on?


@Brian: I have a DL360 G7 with 2 X5650's and I'm looking to using RemoteFX with RDS on Hyper-V. SLAT or EPT shows as not-available when I run the Coreinfo test, but if I disable No-Execute Memory Protection in the BIOS EPT shows as available, but making that change disables my hypervisor. Ever heard of anything like this? I can have Hyper-V or SLAT but no both. Thanks.


We have a win2008r2 RDS with wyse thin clients, running inside vmware esxi 5.5. users launch chrome browser sessions in a mapping/gps app that does lots of map panning, resizing, etc. Performance is not great.

In a test environment I have gotten remotefx to work in a hyper-v win 2012rs environment.

I don't know if it is possible to do this on a 2008r2 server hosted by vmware, and if it is, how to do it?