Look out Citrix HDX & VMware PCoIP: RDP and RemoteFX in Windows 8 is awesome!

At their Build conference this past September, Microsoft spend a fair amount of time discussing and demoing their plans for RDP and RemoteFX in Windows 8. I finally took the time to watch the videos from the conference, and I gotta say: RemoteFX and RDP in Windows 8 look AWESOME!

At their Build conference this past September, Microsoft spend a fair amount of time discussing and demoing their plans for RDP and RemoteFX in Windows 8. I finally took the time to watch the videos from the conference, and I gotta say: RemoteFX and RDP in Windows 8 look AWESOME!

In fact my first reaction after watching these videos is "RemoteFX on Windows 8 is so cool! Citrix HDX and VMware PCoIP don't have a chance!!" But of course that's a topic that we've been discussing for almost ten years.

In recent years, when people have asked me about the best remoting protocol, I've always given an answer that was some variation of "Meh. They're all... fine." And I don't want to come out and say that what Microsoft is building into Windows 8 is going to blow away anything from Citrix or VMware. But I will say that the remoting protocols in Windows 8 look to be very, very strong, so anyone choosing Citrix XenDesktop, VMware View, or Quest vWorkspace on top of pure Windows 8 will do so based on more than the protocol.

So speaking of the protocol, that's what I want to dig into in this article. Microsoft shared some fairly in-depth details about RDP and RemoteFX in Windows 8 at Build, and I'd like to share what I learned with you. Most of the information this article is based on is from Build Session 642, hosted by Microsoft employees Gaurav Daga and Nadim Abdo. You can watch a video of their session or download the PowerPoint files here.

RemoteFX is basically the new name for RDP

Ok, so Microsoft isn't officially claiming that the word "RemoteFX" replaces the word "RDP" in every use case. But they have pointed out that RemoteFX is the official name for the "full fidelity" desktop experience. And it seems like every one of the slide shows and demos I've seen only mentions RemoteFX. So just like HDX kinda replaced ICA, RemoteFX is kinda replacing RDP.

RemoteFX Adaptive Graphics

In Windows 8, RemoteFX's job is to take the apps and desktop running on the remote system and optimize them for the network, regardless of what it is. So Microsof evolved everything--codecs, progressive rendering, optimized text codecs, media remoting--and packaged them all into a system that dynamically evaluates how it's encoding everything on the fly.

For example, RemoteFX will now use different encoding and different techniques for different regions of the screen. The example Microsoft gave at Build was based on the MSN home page. They explained that for text content, they'll use a codec for text that will send it down clear and sharp and perfect with very little bandwidth. (Even if they're not working with client-side font lists, they can still encode text content with high quality and low bandwidth.)

Then for image content, they'll use a progressive refinement technique where the base image gets down there instantly and then the image is refined as the network can handle it. (This is like VMware PCoIP's "build to lossless" capability, except it only affects the images and not the text. So actually it's like web browsing in the nineties.)

Finally, for any regions of the screen with lots of fast-moving changes (Flash, banner ads, video, etc.), they'll re-encode that with H.264 and send that stream down to the client.

All of this is done dynamically and changes constantly, and they can break up a single screen into as many different regions as possible:

RemoteFX 8 adaptive quality

What's also cool is that RemoteFX in Windows 8 will change which techniques it's using and how agressive it needs to get with stuff based on network and client characteristics. For example, if not too much bandwidth is available, RemoteFX can dynamically decide to start using more CPU on the host to do more compression. That will lessen the bandwidth required but increase host CPU consumption. And if the network is wide-open and there's plenty of bandwidth, the remote CPU doesn't have to work as hard. (This feature, and the limits in both directions, will all be controllable via GPOs.)

This is awesome. Remember the article I wrote "Remote display protocols: low bandwidth, good user experience, low CPU... pick any two." Now we can pick one as "good user experience" and let the system work out the balance between "low bandwidth" and "good user experience." Brilliant! (This also addresses my commentary on the fight Citrix and VMware got into about bandwidth consumption. I always believed that if the network was wide open that the protocol should be allowed to take as much bandwidth as it needed to deliver an experience that was as perfect as possible.)

Delivering RemoteFX via UDP in addition to TCP

By now most of us are aware of the "UDP versus TCP" conversion when it comes to delivering remote computing protocols. (I wrote a primer last year for SearchVirtualDesktop if you don't know what I'm talking about here.)

Long story short: Microsoft is jumping on the UDP bandwagon for RemoteFX in Windows 8. Now this doesn't mean that UDP is replacing TCP. It just means that if UDP is available, and if the characteristics of the network are favorable for it, then RemoteFX will use UDP for some of the virtual channels. (Some, not all.) But RemoteFX will also happily work via 100% TCP. It just depends on the scenario and connection. (This is also controllable via GPOs.)

RemoteFX will also pay attention to what kind of content is being remoted so they know if they have to retransmit any packets (since UDP doesn't retransmit). For example, if they're sending down an H.264 video stream, that codec will heal itself so they don't have to worry about missed packets. But if they're sending down some other screen element via UDP, they'll retransmit if needed.

The new Remote Desktop Gateway also integrates the new UDP option, so it can easily be extended across the Internet.

RemoteFX Media Remoting

RDP and RemoteFX have long supported multimedia "redirection" for certain types of video content. (This is where the remote host identifies a media stream and simply redirects that stream in its original and unmolested format, down to the client where the client decodes and displays it locally. This is much better than decoding and rendering it on the remote host and then immediately trying to re-encode it with RDP to send it down to the client. Citrix HDX has a similar feature.)

In RemoteFX on Windows 8, the media remoting capability will work exactly as it did in the past, and Windows Media Foundation and DirectShow content will be sent from the host right down to the client without transcoding. So that's all the same.

The problem with media remoting in the past was that it only worked for those certain types of Windows media. So if you were watching a QuickTime AVI or Flash video in the session, good luck!

So what's new in RemoteFX for Windows 8 is that if there's a video format that RemoteFX can't redirect natively, the remote host will use an H.264 codec engine to re-encode those moving graphics into an H.264 media stream which is then redirected to the client where it can be rendered locally. So now you can essentially say that RemoteFX can redirect any media format. Of course this H.264 encoding will require a bit more horsepower on the host, but again that's a balance between user experience and host processing, and something that can change dynamically in Windows 8.

Putting it all together for real WAN support

You can imagine that all of these capabilities (adaptive graphics, UDP option, and media remoting) can work together to create a kickass WAN solution, and that's Microsoft's plans too! In fact they specifically called out the WAN use case as a goal for RemoteFX in Windows 8. (RemoteFX in Windows 7 was famous for consuming a ton of bandwidth and was thus limited to LAN-only. Well, unless you used it with something like Quest EOP.)

For the WAN in RemoteFX, Microsoft explained that even "WAN" means different things to different people and encompasses a lot of different experiences. WAN could be remote offices across the country or world, it could be 3G anywhere, it could be various qualities of public WiFi, it could be high-speed home cable modems that are faster than the office connections, it could be airplanes... So rather than trying to identify and work with specific scenarios, Microsoft is going back to the basics in RemoteFX for Windows 8 and focusing on three areas of the network: latency, packet loss, and limited bandwidth.


When it comes to latency, Microsoft believes that the physical speed of light issue is usually not the problem. The main problem is that TCP is not efficient in environments with low bandwidth and packet loss, so being able to use UDP should help with that. And even when using TCP, RemoteFX in Windows 8 is smarter about it. The protocol will now change how it multiplexes packets, for example, based on the network conditions at a given moment.

Packet Loss

Again, Microsoft understands that in the world of TCP, packet loss really just means higher latency. But moving to UDP for the stuff that can handle loss should help them ride it out. And adding UDP support to the Remote Desktop Gateway is huge, so users can actually use UDP wherever they are. (Of course with auto fallback to TCP if UDP is not available.)

Limited Bandwidth

The adaptive graphics stuff mentioned above will be great for scenarios with limited bandwidth. Really anything that takes data off the wire is great. At Build Microsoft showed a demo where they compared RemoteFX on Windows 7 and Windows 8 side-by-side (Benny and Shawn style) to watch a YouTube video (not full screen). Windows 7 consumed 30-50mbps, while Windows 8 only used 3-5mbps. The user experience looked about the same on both.

So combine that with the fact that Windows 8 will dynamically choose between host-side processing and bandwidth, and it looks like RemoteFX could be a great WAN solution!

RemoteFX Multitouch

RemoteFX on Windows 8 will support true multitouch. (So this is not just controlling the pointer with your finger.) They can support as many simultaneous touch points as your client device supports, and they can support them with full pressure sensitivity.

RemoteFX USB Redirection for Terminal Server sessions

RemoteFX running on Windows 7 in a VDI scenario was always able to support USB device redirection, but Windows 8 will add USB support for sessions. They've also figured out how to do it with full security, so that one user is not able to access the USB devices or data from another user.

Metro Style Remote Desktop App

This is something I wrote about on ConsumerizeIT.com last week, but if you haven't seen it (and judging by the numbers, you haven't), Microsoft is building a Metro style Remote Dekstop client. This isn't replacing the classic MSTSC client, rather, it's just a second client option for tablet users. The Metro style and the traditional Windows client will have the exact same features. (They'll both support multitouch, for example.) The tablet client is just easier to use on tablets and will be nice if you want to remote Metro style apps.

More information on the Metro style client and remoting Metro apps is in that article from ConsumerizeIT "Windows 8 "metro" apps & the remote desktop client: how will these work together?"

RemoteFX on Win8: the same experience no matter what GPU or platform

The final cool thing about RemoteFX on Windows 8 is that ALL of these features and capabilities are available anywhere Windows 8 runs. So you have the choice of having a physical GPU, a virtual GPU, or no GPU at all. Regardless of what you use, you can still have all of this--full DirectX support, media encoding, etc. (Obviously some of this is more efficient with a GPU, but if you want to do it all in software on a CPU instead, that's your GPO-controllable option). The same is true for physical or virtual. It doesn't matter whether your remote host is physical or virtual, workstation or server--it's all available.


RemoteFX on Windows 8 looks awesome. Are Citrix and VMware dead?

As I've been writing for years, it's really not a protocol War anymore. HDX and PCoIP are both fine protocols with advantages and disadvantages. Maybe now we can add RemoteFX to that list. Worst case this just raises the bar for everyone and the whole world gets a better remoting experience.

The main limiting factor of RemoteFX is going to be a limited set of client platforms and the complexity of a Microsoft-only solution. Citrix, VMware, Quest, and others can take care of those issues. The other limiting factor will be that RemoteFX is a designed for Remoting Windows desktops. So yay! Microsoft is finally awesome at that in 2012 while the rest of the world is moving beyond Windows. So we might see Citrix/VMware/Quest defer to Microsoft more and more for the Windows remoting protocol while these companies look at the other issues (app stores, HTML5, identity management, data sync, etc.).

If you're interested in learning more about RemoteFX on Windows 8, check out the following three sessions from Build. The videos and PowerPoint downloads are all available for free:

SAC 642T, Remote desktop experience in Windows 8


SAC 217T, Graphics on the server


SAC 428T, RemoteFX thin client & partner opp


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

So you don't read my articles eh?  See the section titled "The Empire Strikes Back"  www.brianmadden.com/.../is-microsoft-finally-closing-in-on-citrix-with-a-look-back-at-ten-years-of-quot-microsoft-is-going-to-kill-citrix-quot-stories.aspx

It will look quite familiar ;)



Yeah but I was thinking that was just one section about RemoteFX on Windows 8 of a larger article that was about the history of protocols. So I was thinking for my article that it would be just about the new stuff for Windows 8 and go into more detail there.

Now, what I forgot was that your article was like 4k words, so probably your little section on Windows 8 was longer than my whole article. :)


Once again, the same old story since 20 years... With this new version, you will not need anymore Citrix and others... Hopefully, Microsoft is getting better each time...but didn't solve the non-microsoft and non-latest-version issues...

Hey guys, wake up ! Remoting something is not just about protocols.


All good, but I want to know...

Will there be an update (SP2) for Win7 to enable it to decode the RemoteFX payload from a Windows 8 desktop? (because this never happened for XP - unless you're Gabe)..

DirectX support for RDSh sessions?

Any advances in OpenGL support?

First question is more important...

I'm glad about the bandwidth improvements - will keep network chaps off my back... 800 RemoteFX vm's creates some pretty impressive charts!



Dan is spot on.  Microsoft's crutch is that they only enable features on the latest/greatest OS platform as part of their desire to drive further Windows upgrades / sales, etc.  If they do this with RFX and not support it downlevel on Windows 7, then it opens up all sorts of ISV moves.



@Brian - Agreed.  Still a bit wordy on my articles.  Happy to have a separate one that calls this out front and center.


In lieu of your article, I have installed shakers in all of the HDX R&D team's boots.


How about just spending that time making a decent Mac client?


Oh snap!


In the RDP 8 demos they specifically state that RDVH and RDSH have the same RDP features.  No crap of full RemoteFX on RDVH and a lite version in RDSH.  That's a thing of the past.

I'm guessing OpenGL support will be left to Citrix?  HDX 3D Pro in XenApp 7.0 perhaps?  Can't wait.  Someone on here said it almost made it to XenApp 6.5 but was withdrawn.

There's an open source project attempting to bring RDP 7.1 to Linux/UNIX, Mac and Windows called FreeRDP.  They eventually want to add RDP8 down the road.


Also... Wouldn't be nice to be able to nominate an application to exclude an app from using RemoteFX?

Some apps believe it or not - just perform better using good old RDP even on the LAN! - specially with the min send interval tweak!

Could be handled easily with GPO's!


I like RFX, but a lot of this isn't new, so I can't quite share the same level of excitement.

Take the 'adaptive graphics' bit (which would probably be better referred to as 'adaptive compression'). This is a base feature of PCoIP - breaking down the graphics output by content type (video, text, image) and applying different compression techniques to optimise bandwidth usage. Text is prioritised over any of the other content types so you only ever see build-to-lossless on images (aka this progressive refinement).

Media and USB redirection are nothing new either - its great to know they are there, but I would say this is an expected option for any such technology.

One point that does stand out is that if the UDP versus TCP decision making could be made location based (which it seems it could be), this would certainly be useful.

There is certainly some other cool stuff in the pipeline for RFX, but when some of this is heavily OS dependant (even down to the bandwidth optimisations), surely this should be more frowned upon than celebrated?


Brian, this is an absolutely great article.  Microsoft is indeed showing that they are serious about the VDI space and that they will make a strong push.  Their adaptive bandwidth usage and encoding techniques for different content are a great example of the progress they are making.

Your blog clearly spells out the benefits of using UDP over TCP for any real time communications or remoting protocol.  The fact is that UC and video conferencing providers realized over 15 years ago that UDP was ideal for delivering real time communications, both on the LAN and over the WAN – any self-respecting engineer would know this.  

The problem is that the dinosaurs over at Citrix created ICA way back when eight-track records were still popular.  ICA, which is TCP based, is not optimized for the WAN and hence requires a WAN optimizer to function with any reasonable performance.  This leads me to my next point – how the HDX brand was born.  Citrix created the HDX brand to hide the inadequacies and inefficiencies of ICA; basically get people to stop talking about ICA and have them focus on HDX.

I will give Citrix credit though.  Through their brilliant marketing campaign, they managed to turn a weakness into a strength.  Here is a perfect example of how Citrix markets to turn a weakness into a strength - The fact that “ICA needs a WAN accelerator” is messaged by Citrix as “ICA supports WAN accelerator”.  Without branch repeater over the WAN, ICA is an eight-track competing against a DVD – welcome to reality!  

Things you can continue to count on from Citrix as this battle plays out:

1) Smear campaigns, attack both VMware and Microsoft

2) Fancy marketing to hide weaknesses in their products

3) Blur the lines between XenApp and Xendesktop

4) Get ready for HDX2 -  ïŠ