How it started: A real requirement for a Multi-User RDP Windows Hack

Once upon a time ...

... I was confronted with an interesting and (at that time) challenging task:

A medium-sized retail chain with 150 branch offices has decided to migrate 150 branch office servers from Linux to Windows.

Each branch office had at least two (or up to a maximum of five) thin clients (Neoware/HP/Wyse). The local servers hosted the merchandise management system/database, provided the associated GUI via X11 to the thin clients and had many, other tasks like printing services, access control and work time tracking, etc.

These Linux servers actually were just standard office PCs with software RAID and most of them equipped with four GB of RAM.

However, the overall system was designed to work without any network connection to the headquarters. A  VPN with really low bandwidth was in place for remote management, database backup/synchronization and software update tasks, running during night hours.

Now the new requirements for the servers were simple (at least from their CTO's point of view):

• Host the new inventory management software and serve the associated Windows GUI to the existing thin clients.
• Keep doing all the other tasks

We've intensively researched and tested a Wine-based approach but failed horribly at that time. In addition the manufacturer of the inventory management software declined any support if the software was not running natively on "Windows" and suggested a Windows Server based approach:

• The servers should be loaded with Windows 2008 Standard (which already included a 5-User CAL) plus the required amount of Remote Desktop Device CALs to serve the Windows GUI via RDP to the existing thin clients.
  
• The other Linux system tasks either should get ported to Windows or the Linux system could be virtualized on the Windows Server's HyperV and continue to run as usual.

However, since the server part of the new merchandise management system was perfectly supported on Linux and only the GUI required a Windows host, I've suggested to virtualize only the Windows Remote Desktop Server for hosting the Windows GUI via KVM.

This had the big advantage of virtually no required changes to the update and synchronization procedures. The updates to the Windows VM could be done via incremental binary diffs to the latest reference disk image.

A test setup was quickly created and the performance was acceptable.

But sadly not the investment/licensing costs:

• A few RAM upgrades (acceptable)
• 150 Windows Server 2008 R2 Standard Licenses
• 500 Remote Desktop Device CALs

I don't exactly remember what the best offer for the server licenses was at the time but somewhere around € 600,-- and a RDS DCAL was around € 80,--

You can do the extrapolation and needless to say (if you had known that company) that was way out of budget.

Dead End

Now what do you answer if you're confronted with the question:

Isn't a Windows Server a totally INSANE OVERKILL for simply serving a few database GUIs via RDP !?

Yes, of course! But what is the alternative?

1. Replacing the Linux Thin Clients with Windows XP Embedded?
2. Using 3 to 5 dedicated Windows 7 Professional VMs where the Qemu-gui is served via X11 or where the Thin Clients would RDP into each VM?
3. Serve the Windows GUI on a Remote Desktop Server in the Headquarters via RDP over the VPN?

None of these ideas were feasible: too costly (1), too low resources/performance (2), too low bandwidth (3).

I've worked quite some time to implement the solution with multiple dedicated Windows 7 VMs. I've created a stripped down golden Windows 7 image and used Linux device mapper to run KVM from multiple overlays, one for each VM. Basically it was not unsuccessful but the future requirements for the Windows  VM (maybe some office apps, oh my ...) and the low-end hardware with limited RAM and slow hard disks brought this experiment to a quick end.

Apparently the project had hit a dead end ... until, in my despair, I googled:

• Enable more than one RDP session
  
• Allow multiple RDP sessions
• Prevent single user remote desktop limit in Windows
• Concurrent remote desktop connections to Windows
• How to allow multiple RDP sessions in Windows?
• ...

Wow! I was not alone and Google provided links to many tutorials and forums. Obviously there was a simple hack to get multiple concurrent RDP connections to Windows 7 by simply replacing the "termsrv.dll" file in the Windows System32 folder with some leaked/patched version together with a few registry modifications.

I've tested this on my Windows 7 VM and voila! it worked. Multiple concurrent remote desktop connections to a Windows Workstation OS.

Is this legal?

Honestly, at this point nobody had seriously questioned the legal aspect of this solution.

Of course the company would have "taken" a single Windows 7 Pro license from their Microsoft Volume license deal for each Windows VM, but some Microsoft consultant/representative told them this solution was illegal and they would have to buy RDS CALs.

However, there are no RDS CALs for Windows 7.

They confronted him with the alternative to use one VM per Thin Client, each VM with a separate Windows 7 License.

Now it got crazy:

According to §3.f of the Windows 7 Professional Software License Terms

f. Remote Access Technologies You may access and use the software installed on the licensed computer remotely from another device using remote access technologies as follows.

- Remote Desktop. The single primary user of the licensed computer may access a session from any other device using Remote Desktop or similar technologies

...

Other users may access a session from any device using these technologies, if the remote device is separately licensed to run the software.

Just to be clear: "the licensed computer" is the Windows 7 VM, "the remote device" would be the thin client and "the software" means Windows 7.

And according to MS only one single primary user would be allowed to access the VM via RDP and they were "unsure" if remoting the KVM Qemu Console via X11 would fall under the "Remote Access Technologies" usage rights or not.

Also, when MS could not tell if a 50 feet VGA cable must also be considered "remote access" that licensing discussion has reached a point of unseen ridiculousness.

However, according to §3f , any other users from the "remote devices" (as in Linux thin clients) would be allowed to access the VM if that "remote device" is  "separately licensed" to run Windows 7.

And how do you license a Linux thin client to run Windows 7? 
You buy a license and keep it in your desk - problem solved.

That's what has been agreed to in the end and also MS stopped teasing them regarding the termsrv hack since it wouldn't have made any difference regarding the amount of Windows 7 licenses sold.

Not everything that glitters is gold

The rollout went perfectly fine but soon the strict security update policies fired back.

Each time a Windows update replaced the termsrv.dll someone wanted to kill me.
I don't know how many hours I've spent with roll backs and searching the dark corners of the web for patch instructions for the latest version of termsrv.dll. 

rdpwrap - RDP Wrapper Library by Stas'M

I think it was 2012 when I first stumbled over the open source rdpwrap project. Basically a multi rdp hack that did not modify the termsrv.dll on disk and which ...

... works as a layer between Service Control Manager and Terminal Services, so the original termsrv.dll file remains untouched. Also this method is very strong against Windows Update

Awesome! After a few tests we've immediately switched all the VMs to rdpwrap.

Windows 10 and a commercial RDP wrapper alternative

rdpwrap served me and a few of my customers very well for quite some time but it is not generally unaffected by Windows updates, on the contrary!

Under Windows 7 rdpwrap did often work a long time without requiring an update but since Windows 10 this has dramatically changed.

There were continuous periods of several months where rdpwrap stopped working after each and every single Windows update and I was back to square one.

Fortunately, most of the time the community behind rdpwrap came up quite quickly with working patch instructions.

Nevertheless I was sick of having to deal with this "crappy" situation over and over again.

Especially larger installations with many users accessing a rdpwrap terminal server absolutely depend on this service and I as a consultant get all the hate if it stops working.

Of course over the years I've learned to clearly inform the customers of the legal and downtime risks if they choose rdpwrap over a much more expensive official Microsoft RDSH solution.

Yes, I did implement many projects that  would not have been possible without rdpwrap because of budget restrictions. Also, I do get payed for my support time if rdpwrap stops working but I've always preferred to earn my money with interesting project work instead of having to perform disaster relief all the time.

THINSTUFF

RDP is also great for remote management. Unfortunately many of my "single-/two- or three-person company customers" have Windows 10 computers running Windows 10 Home Edition which does not offer RDP out of the box.

A colleague of mine told me that he always installs Thinstuff's free Remote Desktop Host on these Home Editions and it has just been working for years.

Quoting from their product page: 

Remote Desktop Host (RDH) is a lightweight single-user Remote Desktop solution using the standard Microsoft Remote Desktop Protocol (RDP). It is compatible with all versions of Windows 7, 8 and 10. 

Unfortunately Microsoft has removed the Remote Desktop Host feature from the Windows Home/Starter/Basic editions. In order to access those Windows editions with any RDP client you have to install an alternative RDP Host solution like Thinstuff RDH (single user) or Thinstuff XP/VS Server (multiple concurrent users). 

Never heard of Thinstuff, XPVS or RDH before (although they seem to exist since 2005 already).
RDH is really neat. It comes with a nag screen on connect but for the few times I need it I've never considered buying a license (sorry guys). And the best thing is that it has always survived at least a complete Windows 10 major feature update cycle without update.

Ok, so keep in mind that RDH only enables one single RDP connection and you end up with Windows Pro Edition regarding the Remote Desktop features, also kicking out the connected console user when connecting remotely. A nice free addon for Windows Home Editions but useless for most of my business use cases.

However, that XP/VS multiple concurrent user thingy really got me interested.

Basically I'd consider Thinstuff XP/VS a commercially supported RDP Wrapper alternative with many more features, extremely resilient against Windows Updates and it was exactly what I needed!
    

Now I could offer my customers the rdpwrap (free, risky), Thinstuff XPVS  (very cheap, less risky) or Microsoft (expensive) solution and if anything breaks, Thinstuff will support them (which they do outstandingly well).

Also very nice: Thinstuff's licenses have always been and still are perpetual. Yes, that means no yearly renewals, buy once and use it forever.

On top of that I get reseller conditions .... so that's a win-win for me.

To be continued

I hope you've liked this post and you can expect some more about awesome, affordable solutions I've implemented with rdpwrap, Thinstuff and similar solutions in the last 5 years.

Feel free to comment, especially on which solution you would have proposed/implemented 10 years ago for the described scenario above!

Also I'd like to read your experiences with rdpwrap and/or Thinstuff or similar RDP alternatives!