How it started: A real requirement for a Multi-User RDP Windows Hack
... I was confronted with an interesting and (at that time) challenging task:
Once upon a time ...
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
- 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.
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.
- A few RAM upgrades (acceptable)
- 150 Windows Server 2008 R2 Standard Licenses
- 500 Remote Desktop Device CALs
You can do the extrapolation and needless to say (if you had known that company) that was way out of budget.
Dead EndNow 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 !?
- Replacing the Linux Thin Clients with Windows XP Embedded?
- 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?
- Serve the Windows GUI on a Remote Desktop Server in the Headquarters via RDP over the VPN?
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.
- 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?
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
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
Windows 10 and a commercial RDP wrapper alternativerdpwrap 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!
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.
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.
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).
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.
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!
To be continued
Also I'd like to read your experiences with rdpwrap and/or Thinstuff or similar RDP alternatives!
Nice bunch of information.ReplyDelete