Is RDP to Windows 10 VM from a thin/zero client a violation of the Win10 EULA?

A friend of mine owns a small business with 5 employees. We have been thinking of virtualizing their Windows 10 workstations for the sake of data integrity (KVM on ZFS) and downtime (just use any cheap thin client booting from the network and RDP to the VM, no Windows re-installs and configuration in case of HW failure).

I have been looking into this and I have stumbled upon VDA, SA etc etc quoted as needed to access a Windows 10 VM (from a non-Windows (10) device).

Does a Windows 10 Pro license really not cover RDP to a VM? Is Microsoft really that stupid? I mean, we do own the software, we would just choose to run it on-premise on a centralized server instead of baremetal. Can someone clarify?

1 Like

…actually, you pay for a licence to use the software.

As far as the title “Is RDP to Windows 10 VM from a thin/zero client a violation of the Win10 EULA?”, nope, you can remote in from your phone if you’d like to.

1 Like

You paid for Windows 1Pro, that allows RDP it doesn’t matter where the OS is installed.

You can only have one RDP sessions live at a time though, and you need a license for each Windows 10 VM obviously.

Keep in mind your thin clients will still need licensed, maintained, updated and secured with appropriate controls (you effectively double your work load).

1 Like

Can I use thin clients that use Openthinclient or ThinkstationOS though? Or does the thin client OS have to be compatible with the WIn 10 EULA? That is what I can’t wrap my head around.

EULA has nothing to do with what technology you use.

Whatever you use to connect to the Windows OS needs to be supported by the client machine. In this case RDP.

Essentially whatever features the OS provides are available. the EULA doesn’t restrict much in that manor unless your getting really weird.

The same still applies to your thin clients regardless of OS though, they will still need maintenance, hardening with appropriate controls etc.

I only bring it up just in case it wasn’t on the table as they can quickly become a weak point in your network.

If there are any licensing issues here, it’s certainly something that’s being tested at the moment - lots of businesses are providing remote working continuity right now by connecting users to their usual desktops over RDP.

There is a licensing cost if they are using a Remote Desktop Gateway or any other aspect of remote desktop services on a Windows server to do it, but my understanding is that using some other VPN product to achieve the same (or guacamole) is all good… What you seem to have stumbled onto is the world of VDI which seems to be prohibitively expensive for anyone but large enterprise, due to a combination of Microsoft and Nvidia licensing costs in addition to the expensive hardware.

The larger licensing issue you might face would be if your current licenses are OEM (ie they came with the PC) you can’t transfer that license onto a virtual machine on a different computer. Pretty sure you can’t use them on a vm on the same computer actually.

I’m about two thirds through a thin client project - motivation is that we had to replace an old 2008 r2 session host for remote access anyway, and with the improvements to RDP in Win 10/2016, we might as well set up some thin clients to replace some of our more ancient desktops, as the experience should be considerably better.

The main point to make is that if you are planning that your thin clients run linux, the FreeRDP/Remmina client is much worse than the Microsoft client (on WIndows), because it doesn’t use any hardware acceleration.

Just for context on this, the modern RDP protocol uses an AVC 444 video stream to encode the entire screen - the encoding of this is hardware accelerated if such an encoder is available, so our Windows Session host has a Quadro P2200 assigned so that we can use the NVEnc chip for this part instead of chewing up our CPU - the average desktop can use intel quicksync for this purpose (this is another headache of your thin client proposal - you’ll struggle to avoid software encoding with several win 10 VMs).

Anyway, I hoped that a Raspberry pi 4 (or even 3 for that matter) with it’s robust hardware decode capabilities would be a perfect thin client for this job… but freerdp can’t use it, so as soon as your user tries to watch a youtube video full screen they’re watching a slide show.

Similar hardware can be used if you are willing to use the Microsoft Remote Desktop Client for Android - this does use video acceleration, so on something like a Fire TV 4k stick, or half decent android TV box, the experience is fairly good… but I found some keyboard shortcuts (like alt-tab) weren’t passed through, and if your monitor doesn’t run a standard tv resolution (ie 1920x1080) then it’s another headache getting the android device to run at that resolution.

So ultimately, I’ve bought a few Windows nettops to solve our problem - they are licensed to run Windows 10 pro so I’m going to thin it down and script them to behave as thin clients ( has someone detailing a similar project).

Of course, you might not care that your users can’t watch video/get graphic rich experiences, but it’s something to be aware of going in - your users will get a worse experience from this unless you plan and test carefully.

With all that said, I have to say your motivations for the project seem misplaced.

You protect the data integrity and availability of your files by storing them on a server (potentially with ZFS) and making sure you have regular backups.

If important work is being stored on the desktops (or as a safeguard against desktop data loss/downtime) you can run something like Veeam Agent (which is free and good) on the desktop to take regular backups, if the drive breaks you use the restore media and get the computer back within an hour - if the hardware is standardized you can just keep a spare desktop for this purpose if uptime is that important.

You need backups anyway, using Veeam is a much better solution for the issue you are talking about than coming up with your own mini-VDI infrastructure.

I know where the license confusion originated though.

With windows server terminal services, you needed CALs of some kind (beyond the normal ones required for windows clients) for non-windows device clients, which included some level of terminal services license in the client OS.