Microsoft announces "RemoteFX" the Calista-based Hyper-V-requiring PC-over-IP competitor.

Today is a huge day for desktop virtualization. Microsoft, Citrix, and several other partners are announcing a slew of new things specifically related to desktop virtualization, and we'll dig deep into each of them over the next few days.

Today is a huge day for desktop virtualization. Microsoft, Citrix, and several other partners are announcing a slew of new things specifically related to desktop virtualization, and we'll dig deep into each of them over the next few days. There's even a dedicated website,, setup for the announcements.

The first announcement we'll dig into today is that Microsoft's Calista-based graphics remoting capabilities will be called "RemoteFX" and shipped as part of SP1 for Windows 7 and Windows Server 2008 R2. I've written quite a bit on Calista in the past, including Microsoft's purchase of the company over two years ago and some updates (1, 2) on their progress along the way.

For those who don't know, RemoteFX is an enhancement to RDP's graphics remoting capabilities. The goal of RemoteFX is to deliver the full modern Windows desktop experience—including multiple displays, Aero, and multimedia—to all types of client devices including very thin, sub-$100 thin clients. RemoteFX does this via a technique known as host-based rendering, which means the entire final composited screen image is rendered on the remote host and then compressed and sent down to the client. (In effect this moves more computing into the datacenter and lessens the importance on specific client devices or client specs.)

Fundamentally RemoteFX is just a codec (like H.264) that's been written for real-time encodes. (H.264, on the other hand, is meant for content that can be pre-rendered not in real time, like TV shows and movies.)

There will be several initial ways RemoteFX will function once it's released, including:

  • Full software-based encoders on the host.
  • a GPU/CPU-based encoder (with extensions to Hyper-V to let GPUs be shared between multiple VMs).
  • A custom chip-based encoder, either on a plug-in card or built-in to the host.

Similar variations will exist on the client side, with traditional PCs being able to decode RemoteFX fully in software (either running on the CPU or, if available, the client GPU). There will also be options for chip-based plug-in cards to fully offload the decoding from the client CPU, and new lines of thin client devices with the decoding circuitry built-in to their hardware.

Microsoft has stressed that the RemoteFX codec is the same regardless of whether it's running in software on the CPU, the GPU, or a custom plug-in card. And any client/host combination of software, GPU, or plug-in card will work, because the data on the wire is the same regardless of how it was created or how it's being decoded. (I visited Microsoft's Silicon Valley Campus earlier this week and recorded a video demo of RemoteFX in action on several clients.)

As I briefly mentioned before, RemoteFX is just an enhancement to RDP's virtual channel that handles graphics remoting. It's not a replacement for RDP. This means that all the "other" RDP characteristics and capabilities are the same. (Same ports, same encryption, same printing and client device remoting, etc.) It also means that you don't have to have a RemoteFX-enabled client to connect to a RemoteFX-enabled host as the client and host will auto-negotiate their capabilities (or lack thereof) around RemoteFX just like any other RDP component.

The first implementation of RemoteFX will be focused on LAN scenarios, which is code for saying it takes more bandwidth than RDP's traditional client-based rendering and doesn't like latency. Microsoft has said they'd like to (or enable partners to) extend RemoteFX to work in WAN scenarios, although they also point out that there are already ways to handle the WAN with traditional RDP, so the ultimate WAN solution might be RemoteFX or might be traditional.

Microsoft hasn't announced a ship date for RemoteFX yet, although they said it will be part of Service Pack 1 for Windows 7 and Service Pack 1 for Windows Server 2008 R2 (for Hyper-V and Remote Desktop Session Host). So I guess as soon as we get a ship date for SP1 then we'll know when we get RemoteFX. (Oh, and what ever happened to Service Packs not adding capabilities?)

Make no mistake: RemoteFX is about Hyper-V

In order for a remote Windows 7 VM (i.e. VDI) to use RemoteFX, that VM MUST be running on Hyper-V. Period.

At first you think this makes sense, since the new (SP1) version of Hyper-V is needed to virtualize and share GPUs between multiple guests. But then you think, "Wait a second... Isn't there a software-only encoder for RemoteFX?!? If so, then why do I need Hyper-V? Couldn't I just run the software-based encoder inside my VM on ESX?" And actually RD Session Hosts (Terminal Servers) can run on bare metal and still host RemoteFX sessions. (Presumably with the software-based encoder, although it will be interesting to see whether they can leverage GPUs or add-in cards across sessions.)

Even if you could theoretically run the software-based RemoteFX encoder inside a Windows 7 VM on a competing hypervisor, Microsoft is not allowing it. (We'll have to wait and see what the EULA for Win7 SP1 says to see if this is a licensing thing or there's a technical reason it can't happen.) [UPDATE: It just occurred to me that maybe the software-based encoder still needs that virtual GPU, and maybe the TS bare metal use case works only when there's a physical GPU. I guess we'll see?]

Either way, it's clear (and Microsoft fully admits) that the RemoteFX is all about pushing Hyper-V. So if you want RemoteFX for VDI, you need to run your VMs on Hyper-V.

And true to their "platform" role, Microsoft doesn't even care whose desktop delivery stack you use (as long as it's on Hyper-V). They're making the RemoteFX capabilities (on both the host and client side) available just like any other platform capability, so partners will be able to embrace and extend them as they see fit. In fact Citrix has already announced that they'll ship a RemoteFX-enabled HDX (ICA) stack six months after Microsoft ships RemoteFX. So imagine that. Citrix used to be 100% agnostic when it came to the hypervisor that powered XenDesktop (and in fact most XenDesktop deployments are on ESX). But now there will be a real reason to run XenDesktop on Hyper-V. Doing so will give capabilities that don't exist on XenServer or ESX.

How will VMware respond?

Obviously RemoteFX and PC-over-IP are similar in many ways. Both promise rich media to thin clients with most of the work being done on the host side. Both offer bandwidth scalability (with RemoteFX falling back to "traditional" RDP and PC-over-IP scaling back its dynamic quality). Both offer combinations of hardware- and software-based encoders and decoders.

Right now it looks like RemoteFX is more flexible (in terms of hardware/software combinations) than PC-over-IP, but I would imagine that VMware's already working on a similar capability for ESX where they too could virtualize and share GPUs among guest VMs. And since they already did that massive port to move PC-over-IP from hardware to software, I would imagine they could tweak their software implementation to work well on virtualized GPUs, perhaps giving a better experience or at least allowing PC-over-IP encoding to be offloaded from the CPU cores which should allow for better VM density.

If I was at VMware right now I would just move PC-over-IP out of View and into ESX. Make PC-over-IP part of the ESX/vSphere platform and make it available to any VM running on ESX--so then a Citrix XenDesktop customer could get RemoteFX if they chose Hyper-V and PC-over-IP if they chose ESX. (Hey wait.. isn't this exactly what we wrote in November with our article "Is the future of remote display protocols based on hypervisor integration?") That will put the final nail in the "remote protocol is a commodity" coffin and then we can all move on.

What's next?

We're just scratching the surface of RemoteFX now, so keep an eye out over the next few weeks for more discussion and analysis of what this means. In the meantime, what do you think?

Also: Check out the video I recorded of Microsoft's Tad Brockway explaining RemoteFX and showing it on a few different clients.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I’ve been saying this for a while. MS was going to F VMware with Calista. Citrix have a made a brilliant move by using it in HDX and will make it work over the WAN etc over time I guess, or hedge and make a better version for XenServer if indeed host based rendering lives up to the promise....... Citrix is also smart by not putting the protocol into the hypervisor, that is exactly the reason people like me will run away faster from those who do. So I totally disagree with Brian’s premise that this is where things will go. Well at least anytime soon. Only certain features will become hypervisor specific. Being open is key to winning here, hypervisor diversity will be normal.

The other story here that springs out is, this is only for Windows 7. This from what I can tell means, that TS/XA workloads don’t have RemoteFX. I wonder if they ever will. Does the technology work on TS?

I guess the other huge and more impactful story for today that I am sure Brian will also write about is good bye VECD if you have SA. I feel a lot better about that, than trying to shove MDOP up my a$$ to force SA. There is real value with this, even for VMware.


The software only version looks pretty much similar to PCoIP. If it is LAN only, I do not see too much competitive advantage here.

Let's wait to see.


As always, thanks for the fine article.  The design of Calista / Remote FX reminds me of what I've heard about the SPICE protocol... with a virtual GPU.  Gabe said he was going to write an article about SPICE real soon now... but I haven't seen it yet.  Please?

And since Microsoft has pulled back the curtain on RemoteFX it might be useful to compare SPICE and RemoteFX to see what, if any, similarities there are.


Hey Scott,

I'm still trying to collect as much info as I can so I don't leave much to conjecture.  I'll try to get it wrapped up this week and posted up next week.

Thanks for keeping me on it!



Originally branded a heretic in November I feel vindicated with this release from MS which ties benefits of remoting with the hypervisor.

IMHO, the only reason MS has not integrated RemoteFX fully with HyperV is that they have a Windows 7 + 2008 Server agenda they are promoting. (No near term interest in providing superior remoting for legacy-Windows or non-Windows guest VMs)

I expect to see more announcements regarding ESX-PCOIP and KVM-Spice capabilities in response.



Thanks for providing such great coverage.  

Couple things: lock-in, lock-in, an end-user, I am so sick of this.  Open, extensible, and heterogeneous benefit the customer not lock-in.  At least they allow different end point platforms, but couldn't even mention the word Linux (how childish).

Allowing SA Licensed customers to virtualize without VECD is nice (and common sense imho).

Whether it's RemoteFX, SPICE, or PCoIP, I'm curious to know what percentage of the end-user population 'require' these high performance graphics protocols.  I mean, if they've been using Citrix/TS for many years, what is the impetus driving the need for RemoteFX, SPICE, or PCoIP.

I can see where general graphics, flash/HTML5, audio compression/optmization, and latency reduction can be a universal benefit because they apply to LAN and WAN connections, but it just seems a lot of effort is going into new remote graphics technologies that have a very limited deployment scope and audience.



Maybe some people missed this, but RemoteFX will be made available for endpoint devices that are thin clients/zero clients as well other other client OSs.  This does mean that you'll have to pay the higher $100/device cost, but at least it's MS recognizing that there is a market for low cost discardable devices with little to no management costs.  Of course it implies LAN based scenario.




You're blowing the vendor lock-in out of proportion. They are actually a trade off, trading one lock-in for another.

Notice that you can buy a GFX card off the shelf to offload workload on the GPU? Try doing that with PCoIP.

Also, I would have to argue from an Enterprise IT service orientated perspective end user experience and performance is a requirement that is at the top and needs to be addressed first and foremost to gain attraction.

There is a reason that MS, Citrix, and VMware are all heated up over this.


Shawn, I suspect that this FX-decoder would be part of a future mstsc.exe, not just in thin client ASIC.  So if one were to repurpose a PC with Windows Fundamentals, or to access the Hyper-V Guest with any Windows RDC that's FX-enabled, you should be fine.


@Patrick - I know there's soft client capability.  I was answering the statements about lock-in by stating that they are offering alternative endpoint OSs as well as zero client/thin client offerings.  So while it is vendor lock in on the hypervisor and host OS front, it's getting more open than Microsoft has ever really seemed they were from a client perspective.  Yes they've always had third party RDP implementations, but this is a little different.

Ultimately though I disagree with the hypervisor lock-in approach and I really wish there was another way to leverage RemoteFX without being tied to Hyper-V.



Fine to see that @appdetective is as wrong as Alessandro (over at his) as regards to "Windows 7 only". Not so. Even as I am (in my work), my true colors are in the local from purerly egoistic motives, I take defence for developers and IT-pro's as much as I take defence for any that so requires.  IMO we are the ones to virualize - not become victim thereof. Who is the "task worker", who is the "knowledge worker"?  None! None should,


NComputing has announced support of Remote FX today in the form of a chip that promises to "reduce client costs to zero":


I am willing to bet that MS used VECD to keep VDI adoption at a low pace until they and their partners were more ready to take on their competitors with their hypervisor offerings.

It would have been a nightmare for MS and their partners if VDI was all run on ESX/vSphere.


@Icelus, whoa.. interesting thought.. maybe that's worthy of its own article next week? "Did Microsoft use arcane VECD to artificially stall adoption of VDI until Hyper-V was ready?"


Icelus - Depends on who they bought desktop virtualization from doesn't it. Sure if they locked themselves into a certain chargeable hypervisor, then they might be now kicking themselves... Then comes the desktop virtualization package - anyway, it seems that if they did buy view, all isn't lost...


@Mr. Incredible

That's correct!

But since VECD was a sore point in every Windows VDI deployment from all vendors, it really set VDI back in terms of early adoption due to extra license costs.

If you were apart of the early adopters of VDI chances are you have ESX on the backend.

However, for the majority of people who haven't succumed to the VDI craze MS and Citrix still have a chance to get their Hypervisor in there.

On another note: If Citrix integrated HDX into XenServer, and since "RemoteFX will be included for HDX connections"  as quoted from Tad Brockway can I assume that RemoteFX will eventually be available on XenServer if the HDX is integrated???

With WS2008r2 SP1 Hyper-V and XenServer 5.6 coming out that have new Memory Management that they bashed VMware for, it is my biased opinion that VMware won't be able to match the competition for much longer.

Sorry VMware, I think it's time to bring down your prices and be more competitive, your Memory Management argument that you held onto for so long seems to be crumbling from underneath you.


I don't think my last post was really to the point.

My thought was that VECD was a Server Virtualization play, not a Desktop Virtualization play.

Hopefully I got my point out now...



Great comments. Please keep up!

As regarding MS willigly holding back VDI I assume the same as you. However afaik there is no evidence to bring to the table, but I concur - It's indeed a very valid question to ask. So, hell yeah @Brian Madden please do a write up on this!


Micheal Roth eluded to the Microsoft stall tactic in his 60 second analysis yesterday -

Quote -  "I have always said that Microsoft will only lower the price of VECD when they feel they are ready for the battle with VMware. Today they feel they are ready" - End Quote.


@Kimmo let me clarify my Window 7 only statement. I am referring to Windows 7 only support for RemoteFX via HDX. I see no evidence that HDX for XA workloads will be supported. I do see a statement from MS that TS workloads will be supported as per the following link:

So this worries me. We need the HDX support for both XA (desktop and app) and XD (VDI) workloads. Without this we are stuck with $$$$ VDI. I worry that MS is too fixed on just VDI and screwing ESX in the datacenter via VDI. They can screw them more with RemoteFX for HDX on TS. Without it, a massive value drop in SA so Microsoft really need to fix that with Citrix if I correct which I am not currently 100% sure about. So anybody who knows further details it would be great to hear.

Reality is that RemoteFX is LAN only which tells me that it will likely suck bandwidth like PCoIP/SPICE, and hence a smart move by MS reaching out to Citrix. @Brian bandwidth matters a lot delivering user experience. Choke my bandwidth and my user experience is dead.... Regardless I am still skeptical how successful any of these host rendering solutions will be. Do I really want to put chips in the server? Sure this may help the thin client market, and as others have posted they will take advantage like NComputing. I am sure Wyse are building a RemoteFX thin client right now while VMWare is kissing ass to do one with a Teradici chip set. They will likely do both, but will MS want them to. What will Wyse do? MS are kings at OEM INFLUENCE :-)

Hence I believe more can be done at the client side to deliver user experience, and again I don’t buy it with custom chips from anybody. So I think net net, HDX is the most vendor neutral, hypervisor agnostic choice for me, and oh yeah it actually works on a network for most cases with many users on a link over latency.....


@AppDetective - from reading the link you posted I'm seeing that RemoteFX is for Windows 7 guest on Hyper-V and Windows Server 2008 R2 SP1 - for delivery of both virtual and session hosted desktops - so that includes RDS/TS too.

Citrix talked about be ready to support RemoteFX within HDX with 6 months or so of RemoteFX launch - it would seem kinda crazy of them to do only one side of the story - HVD and not their core of RDS/TS too. The article mentions the collaboration with Citrix - remember XenDesktop isn't HVD only anymore, it also includes XenApp.



For the first time I want to correct you, hopefully I am right.

RemoteFX is a feature released for WS2008 R2 SP1 and W7 SP1 so it will be available for all RDP connections on those platforms. They Say it WILL work for TS workloads because it's RDP. What they don't explicitly say is that through their joint partnership with Citrix RemoteXP will be available for HDX connections.

My interpretation is that XenApp and XenDesktop will be supported.

I totally agree with your stance on the client side computing.

The concept of centralizing distributed computing will never be full swing due to offline use. I don't care how good the user experience/hardware performance is, there will always be a need for distributed computing as long as users want to work offline.

These announcements and the further anticipation of XenClient might make June 2010 a reality for Brian!

I still think he had inside information about that date from the vendors!



Thanks for your update

Come to think of it, I haven't actually read anything from Citrix official sources on RemoteFX support on XenApp. Can't remember XenApp being mentioned on the webcast. For cetrain is that Harry Labana didn't mention XenApp in his post on Citrix blogs.

That said I would be rather baffled if Citrix didn't support RemoteFX in XenApp, especially since it will be there day 1 in RDS and, assumingly in Quest and others RDS-based products.

Now then, with RemoteFX being Host rendering technology, bandwidth hungy and hardware hungry (though suggested, not by any necessity dependent on custom ASIC) the question arises:

How will all of this fare in WAN scenarios (both VDI and RDS)?

Well,I do not know particularly much of anything but I think it's quite the challenge and lot of space to being old fashioned and innovate ;)


@Icelus I really hope you are right and I am wrong on this one :-) Correct me anytime you like, it’s not a competition.


I am glad to see that RemoteFx will make it out the door (eventually).  Ultimately, I think the enterprises will want a combination of server side software, server side hardware, and client side hardware, and maybe client side software, implementations of graphics processing.  Different solutions to differenet scenarios, needs, and costs.

I recall talking to (begging?) AMD to look into hardware GPU sharing right after buying NVIDIA.  I was thinking of the TS case and not VDI, but it is an option that needs to be available.  With multiple vendors having partial solutions it is pretty much impossible to evaluate capabilities and scenarios.  This is one step to getting us to a point where fuller evaluations can happen, but there will be many more needed.

I also liked the idea of the dynamic memory adjustments shown in the video Brian referenced.  Of course, we'll have to want and see how well it works - but the concept makes perfect sense and I wish I had it today.  And since Microsoft built the ability to change memory on the fly into the OS previously, I would expect that other hypervisors should be able to add similar capabilities quite easily.   ( I had already had this on my "todo" list of things to look into adding ontop of Hyper-V.  Sweet, one more thing off the list).


I don't think I' ready to buy the "VECD complexity was to block VDI" conspiracy theory. I think that is was more of trying to make the round VDI peg fit in the square Windows 7 licensing hole by someone who really didn't understand the value of VDI.

Napoleon said it best: "Never ascribe to malice that which is adequately explained by incompetence."


Ericom Software, a provider of Terminal Services and VDI solutions, plans to support Microsoft RemoteFX when it’s released by Microsoft, as it will complement Ericom Blaze RDP acceleration. Ericom Blaze accelerates RDP up to 25x and is ideal for remote users connecting over slow WANs who need to access graphics-rich content and applications.   RemoteFX delivers a premium user experience for LAN users accessing rich media content and 3D applications, from virtual and session-based desktops.

The combination of RemoteFX and Blaze within PowerTerm WebConnect - Ericom's unified VDI and terminal services access solution will deliver the best user experience for all types of users and connections.

Read more about Blaze and download a free evaluation at:

Or view a video demo at: