Remote Desktop Services CAL Review: The Licence Everyone Forgets to Buy

Fix it now

RDS CALs are the licence organisations discover at day 120, when users who have been connecting happily for months are refused. They are additional to Windows Server CALs, not a substitute, and they are one of the few Microsoft licences a service genuinely enforces.

1. Buy an RDS CAL for every user or device that connects to a Remote Desktop Session Host, on top of the Windows Server CAL they already need.
2. Order them the day you add the session host role. Microsoft’s licensing grace period is 120 days from that point, and when it ends connections are refused rather than warned.
3. Choose per user or per device by working pattern, with one constraint: a workgroup deployment must use per-device CALs, because per-user CALs are not permitted there.
4. Match the version to the session host. Later RDS CALs work against earlier Windows Server session hosts; earlier CALs never work against later ones.
5. If the session host runs Windows Server on Azure Virtual Desktop, you still need RDS CALs with Software Assurance or RDS User Subscription Licences. Only Windows client session hosts are licensed a different way.
6. Budget shared computer activation for Microsoft 365 Apps if Office will be installed on the session host, because single-user Office licences do not cover it.

Installed RDS CALs live on the licence server. Rebuilding or restoring that server without planning can leave you unable to reinstall CALs you own, and recovering them means going back through Microsoft’s clearing house.

If the CALs are ordered and the licensing mode is set, you are done. If you are still choosing between per user and per device, or between a session host and a hosted desktop, read on.

Why it happens

Every user and device that connects to a Remote Desktop Services or Azure Virtual Desktop session host running Windows Server needs an RDS CAL. The mechanism is a Remote Desktop Licensing server: you install the role, activate it against Microsoft, install your purchased CAL packs onto it, and then tell your session hosts two things, which licensing mode to use and which licence server to use. Getting either of those wrong produces exactly the same symptom as owning no licences at all.

The reason this licence surprises people is the timing. Nothing breaks when the session host role is added. Microsoft’s licensing grace period runs for 120 days, during which no licence server is required at all, and the warning lives somewhere nobody looks. Four months later, in the middle of a working day, users stop being able to connect, and the fix requires purchasing decisions that cannot be made in an afternoon. The lesson is procedural rather than technical: the day you add the role is the day to order CALs.

Per-device and per-user CALs behave completely differently once installed, and it is worth knowing which one you are relying on. A device receives a temporary CAL on first sign-in, valid for 90 days, which is upgraded to a permanent CAL after validation; the permanent one is valid for a randomised 52 to 89 days before it renews, so devices that stop appearing eventually return their licence to the pool. Up to 20 per cent of per-device CALs can be revoked manually for machines that have been retired.

Per-user CALs are the opposite. They are issued from the available pool, or from an overused pool, they cannot be revoked at all, and they cannot be tracked in a workgroup. That last point is a real constraint rather than a footnote: Microsoft states that a workgroup RDS deployment has to use per-device CALs and that per-user CALs are not permitted there. If your session hosts are not domain-joined, the choice has already been made for you.

The version rule is stated plainly and runs one way: you cannot use RDS CALs for earlier versions to access later versions of Windows Server, but you can use later versions of RDS CALs to access earlier versions. Windows Server 2022 RDS CALs reach a 2022 session host or earlier and will not serve a 2025 one. Buy CALs matching the newest session host you run.

There is one thing to unlearn if you have read older advice. Moving to a hosted desktop service does not automatically remove the RDS CAL requirement. Microsoft’s Azure Virtual Desktop licensing page requires RDS CALs with Software Assurance, or RDS User Subscription Licences, for Windows Server session hosts used for internal commercial purposes. It is only the Windows client session hosts that are licensed instead through Microsoft 365 E3, E5, A3, A5, F3 or Business Premium, Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows VDA per user. Choosing Windows Server for your session hosts and assuming the subscription covers access is a compliance gap that nothing will report.

Full reference

Per user against per device, in the detail that matters

Setting the licensing mode and licence server

There are two routes, and which one applies depends on how the deployment was built. In a full Remote Desktop Services deployment with the Connection Broker role, use Server Manager: Remote Desktop Services, then Overview, then Edit Deployment Properties, then RD Licensing. Choose Per User or Per Device, name the licence server and select Add.

Where the deployment has only the Session Host and Licensing roles, use Group Policy instead, under Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Licensing. Two settings do the work: “Set the Remote Desktop licensing mode” and “Use the specified Remote Desktop license servers”, which accepts several server names separated by commas.

A session host with no licensing mode set behaves exactly like one with no CALs. If users are being refused and you are certain the CALs are installed, check these two settings before you check anything else.

Everything you need alongside the RDS CAL

The Office row catches people regularly. Single-user Office licences do not permit installation on a shared session host; you need a plan whose terms allow shared computer activation. Establish that before the server is built, because discovering it afterwards can mean relicensing every user.

Alternatives worth pricing, honestly

• Windows 365 delivers a Cloud PC running a Windows client operating system, so RDS CALs are not the licensing mechanism for it. Price it against a session host including the CALs and the licence server.
• Azure Virtual Desktop is not a single answer. With Windows client session hosts, eligible Microsoft 365 or Windows Enterprise licences cover access. With Windows Server session hosts, you still need RDS CALs with Software Assurance or RDS User Subscription Licences.
• If you only need occasional administrative access to a server, adding the Session Host role to get more simultaneous sessions is the most expensive way to solve a scheduling problem.
• A published application, rather than a full desktop, does not change the licensing. The CAL requirement follows the connection to the session host either way.
• Include the licence server itself in any comparison: it is a role you have to keep, back up and be able to restore.

Keeping the licence server recoverable

Back up the licence server and document its activation details, including the agreement number used to install the CAL packs. It is not a disposable role: rebuilding it without that information means going back through Microsoft’s clearing house to reinstall licences you already own.

1. Record which CAL packs are installed, in what quantity, and against which agreement.
2. Back up the licensing database along with the server, and test restoring it somewhere harmless.
3. If you use per-device CALs, review the issued list periodically and revoke retired machines rather than waiting for someone to be refused a session.
4. Diary a check that the CAL version still matches your newest session host after any server upgrade.

Questions people ask about this