Connecting to RemoteFX from Windows XP: Possible? Yes. Legal? No.

Lately I've been messing around with the idea of using Windows XP to connect to RemoteFX sessions.

Lately I've been messing around with the idea of using Windows XP to connect to RemoteFX sessions. The official Microsoft line is that RFX is only supported on Windows Server 2008 SP1, Windows 7 SP1, and Windows Embedded Standard 7 at this point, but "not supported" and "doesn't work" are two completely different concepts, so I set out to see what, if anything, could be done. On the nerd side, it piqued my interest to see if it could be done. On the practical side, I wondered whether or not it made sense to do it. Last, on the worrywart side, I wondered if it was even legal.

Nerd Side

I've you've never gotten so much as a speeding ticket, skip to the next section, square :) This section contains content of questionable legality (which usually means elevated awesomeness).

Let's get right to the point - it IS possible to connect to RemoteFX sessions from Windows XP. I've done it. I've gotten everything but USB redirection to work, but that's only because I ran out of time (I think). This section is intentionally vague, but if you want to try this should get you in the right direction.

Windows 7 RemoteFX session running on a Windows XP client (here's how to tell)

There are two issues you need to deal with in order to RFX connection via Windows XP. One is finding the appropriate client files on a Windows 7 SP1 computer. The other is actually getting them to stay on a Windows XP system. Without a workaround, Windows File Protection will foil every attempt you make at replacing the important RDC file, most notably mstsc.exe.

My workaround for the latter problem was to download the most recent Windows XP RDC package and replace the files inside it with the ones that I pulled from my Windows 7 SP1 machine. You can modify the update.xml file in the package to include/exclude new files and operations, as well. This essentially becomes a custom hotfix that skirts the Windows File Protection system, allowing the clean installation of the new files. It's an old trick, but a good one. 

Finding the appropriate files is a little bit programatic and a little bit trial and error. I started with trial and error, which got me some succes, but mostly because the resulting error messages told me what to look for next. The real leaps and bounds came from doing a file snapshot before and after installing SP1 on Windows 7. This told me the files that were changed, and helped me isolate which ones should be part of my "hotfix."

The USB driver has been a tougher nut to crack, and I suspect it's signed so that it will not run on XP without some massaging. There's also the possibility of another component that I'm missing. At this point, I'm hoping someone in the community has some time to spend working it through. Hopefully if someone figures it out, they can report back with what they did.

I should also add that I've only tried this on two machines, one virtual and one physical. It worked on both, but that's a small test base. Your mileage may vary.

Practical Side

So what's the use case for connecting to a RemoteFX-enabled session via Windows XP? My first inclination is that means that you can repurpose your Windows XP machines as thin clients (locking them down or using a product like ThinLaunch) instead of upgrading the hardware to run Windows 7. Or how about in a disaster recovery site, where the machines are usually hand-me-downs from past PC refreshes. 

Now, a lot of XP machines may not have the hardware to be able to access RemoteFX sessions, since the RFX client is made to run on Windows 7-era hardware, and there are some local resource considerations to be made. That means that maybe the two example situations above wouldn't work in every case. Still, I can see a lot of organizations wanting to use their existing machines to connect to RemoteFX sessions running on Windows 7 VMs and, perhaps even more so since it doesn't require a GPU, Windows Server 2008 SP1.

That said, I'm sure there are more use cases that I haven't thought of. If you can think of any, please let us know. 

Worrywart side

Ok, so this isn't legal, but neither is virtualizing IE6 and running it Windows 7, which a lot of people are doing. It's a risk/reward thing, and if an organization needs to do this, they can usually find a justification to make it happen.

Assuming it is just plain against the rules to buy a Windows 7 license, pull out the bits, and deploy them to all my XP machines, I decided to take a different approach when asking Microsoft about this. Specifically, I asked if it was acceptable to do this if I owned a version of Windows 7 that gave me downgrade rights to Windows XP. Here's the response I got:

"...The Windows EULA does not allow decompiling or disassembly of the software, so a user will be in violation of the EULA if he/she copies and moves the binary from the Windows Operating System and uses it outside of the OS.  Microsoft understands that some customers may have the need to leverage their existing hardware to upgrade to Windows 7 Operating System, and we are actively working on addressing this need..."

So it seems that, no matter how you slice it, taking bits from Windows 7 SP1 out of Windows 7 SP1 is a bad idea from a EULA/legal standpoint. Again, we've learned that companies will take risks when the rewards are great, and this may or may not end up being one of those situations. There's a lot of value, though, to using your existing hardware and software to access new technology as if it were deployed to the end user directly. With RDSH on Windows Server 2008 R2 not even requiring a GPU to run RemoteFX, there could be a lot of people in that boat.

I did learn, however, that Windows ThinPC will support RemoteFX when it is released, which may be the answer to the hardware repurposing problem that I'm trying to address. If you subscribe to SA or have bought VDA licenses, you'll be allowed to use ThinPC, which is a slimmed down version of Windows 7 made specifically to do what we've been talking about. That only solves the problem for people who want to convert their existing machines to thin clients, though. Those that want a rich OS locally and can't or don't want to upgrade to Windows 7 might not be happy with ThinPC. Stay tuned for a deeper look at ThinPC as we get closer to release.

Wrapping it up

So, is there a worthwhile use case for connecting to RemoteFX from Windows XP? I suppose if you don't have SA and haven't bought VDA, you don't have rights to ThinPC (but then again, since you don't have VDA, you don't have rights to connect to a remote desktop). Ultimately, I think ThinPC will solve a lot of this (at least for those that would want to use XP as a thin client), but it's always nice to geek out for a bit and make things do something other than their original intent. I'm looking forward to seeing your thoughts, so post them below!

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

well done Gabe!

Good to see you're still a techy at heart :)


Well... This is where Quest and Citrix, etc can add value by offering RemoteFX support for XP (and OS X) end-points...

Some use cases:

- People who thought they would get another 4 - 5 years out of their Windows XPe thin clients investment... Their not going to want to upgrade both back and front end services!

- People who need to carry on using XP for legacy reasons who use a blended mixture of hosted and physical or just going through that "transition" phase.

I don't think people should underestimate just how useful XP RemoteFX could be - possible increase the use case for it.

WinTPC is pretty cool (if you have SA)... RemoteFX support works well.



I suspect the answer to finding all the RDP 7.1 files for XP lies in Windows Embedded Standard 7 + SP1.  Find the package for Remote Desktop and dissect it.


We have been playing with WinThic here over the last week and unless it is going to get castrated before finalization, I think it would absolutely solve this issue.  

We have found almost nothing that we can't do with it yet (the exception being the FEP installer says it doesn't support this version of windows).  We even went as far as installing some very 'fat' apps like SPSS, SAS, Starcraft II, Office 2010, and they all run just as expected.

The real puzzling part (I guess bloat is worse than I thought) about it is how this all works with such a small footprint.  The install was jsut over 2GB, and the memory usage was under 400MB.  This should be released as windows 7 R2.

I think this thing has some real potential to be used as a VDI OS too.  With the reduced fottprint, and no noticable limitations it is a perfect cnadidate.  Although, I'm sure there will be some legal issues there as well.



Oh look you can just connect with no Broker BS in the middle and use commodity PCs and avoid BS from WYSE etc and still run some apps locally if Reverse Seamless was not $15 from the thieves at RES. I have been touting this for years on this forum.

It's why the brain dead XenDesktop team should have release HDX Connect for certain use cases. Same goes for Quest and VMW. Ericom have tried but they have no traction in the market. For small use cases where you need a few virtual hosted desktops it's simple, map users to machines with anything simply (login script) and off you go. No brokers to fail in the middle of the day. It's good enough for many use cases.


"...The Windows EULA does not allow decompiling or disassembly of the software, so a user will be in violation of the EULA if he/she copies and moves the binary from the Windows Operating System and uses it outside of the OS."

I don't know whether what you propose is legal or not, but decompiling and disassembly have specific meanings - generating either source code or assembly language from the binaries. This is not what you are doing, and so it is not prohibited by the license condition that you quoted. It is possible that there is a different license condition that prohibits it though.


@Martin - That's the official response I got from Microsoft about whether or not this is more than just unsupported. I understand what you're saying, though, and decompiling is definitely not happening. Disassembly in the programming sense isn't, either, but it wouldn't be since we're not talking machine code. Still, I see where you're coming from, and that's one of those risks that a company would have to evaluate. Do they want to challenge the meaning of "disassemble" in court? :)


Hi Brian,

would you mind sharing a list of the files from 2k8 R2 that need to be transferred to XP.



Thanks for this, I was able to upgrade Windows XP x64 to RDP 7.1 this way (by first installing KB925876 and KB2481109 and then copying over the new files needed)