In short
Default Windows Server lets exactly 2 administrators connect via RDP simultaneously — no licence needed. For anything beyond that (real multi-user RDP for a team), you must run the Remote Desktop Session Host role, which requires an RDS Client Access Licence (CAL) for each user or device. Two licence flavours exist: per-user (assigned to AD users, can connect from any device) and per-device (assigned to shared machines, good for shift work). Microsoft gives you a 120-day grace period before the licensing rules become enforceable. Source the licences via BYOL (your existing volume licence with License Mobility) or via SPLA through Raff.
TL;DR
- 2 concurrent admin RDP sessions are free; multi-user RDP needs the RDS role + CALs.
- Per-user CAL = assigned in AD, follows the user. Per-device CAL = assigned to a machine, follows the seat.
- 120-day grace period before enforcement starts. After that, sessions get rejected — not just flagged.
- RDS CALs for newer Server versions work on older session hosts. The reverse is never allowed — buying 2025 CALs future-proofs your deployment.
- BYOL needs Software Assurance + License Mobility. Otherwise activate via Raff's SPLA programme — pay-as-you-grow.
What is an RDS CAL?
Every user or device that connects to a Windows Server running the Remote Desktop Session Host role needs a Remote Desktop Services (RDS) Client Access Licence. This is separate from the base Windows Server CAL (which covers general server access like file and print); RDS CALs specifically cover the right to run a Remote Desktop session.
The lifecycle of a connection:
- A user (or device) opens an RDP client and connects to your Windows Server.
- The session host checks whether this is an admin session. Sessions 1 and 2 are admin and don't require a CAL.
- Beyond session 2, or when the RDS Session Host role is installed, the session host asks the Remote Desktop Licensing server for a CAL.
- If one is available, it's issued and the user connects.
- If no CAL is available AND you're past the 120-day grace period, the connection is refused with a licensing error.
The licence server is a separate role you install on a Windows Server. On small deployments it commonly lives on the same VM as the session host. It tracks issued CALs, handles renewals, and surfaces usage reports.
Per-user vs per-device — decision matrix
| Factor | Per-user CAL | Per-device CAL |
|---|---|---|
| Assignment | User in Active Directory | Physical or virtual device |
| Good fit | Each user has their own laptop or workstation | Shift workers sharing a pool of machines |
| Workgroup support | ❌ Operational failure — users get disconnected after 60 minutes because tracking requires AD | ✓ Works in workgroup |
| Enforcement | Honour system — not technically blocked at runtime | Strictly enforced — no CAL means no connection |
| Over-allocation | Possible (in breach of the licence agreement) | Prevented by the licence server |
| Revocation | None | Up to 20% can be revoked |
| Temporary CAL | Not available | 90-day temp CAL on first sign-in |
| Renewal cadence | 60 days (auto-extends on next sign-in) | Random 52-89 days (spreads renewal load) |
| RD Web Access | ✓ Microsoft's recommended model | ⚠️ Every device visiting the portal consumes a licence permanently |
Pick per-user if:
- Each member of your team has their own laptop or desktop and signs in from one AD identity.
- You're running an Active Directory domain.
- You want flexibility to add or remove users without tying licences to hardware.
- Typical scenarios: accounting firm with 8 bookkeepers, dev team of 12 with personal laptops, agency with remote staff.
- You're using RD Web Access. Microsoft specifically recommends per-user here, because per-device CALs get consumed by any device that visits the web portal — which drains licences fast.
Pick per-device if:
- You run shifts (call centre, factory floor, retail) where 2-3 workers share the same PC.
- You don't have an AD domain (workgroup deployment — per-user simply won't work here).
- You need strict enforcement and over-allocation prevention.
- Typical scenarios: 6 shared kiosk PCs serving 15 nurses on rotating shifts, 4 shared workstations for a team of 10 contractors.
Common workgroup mistake: buying per-user CALs for a workgroup deployment. Per-user tracking requires Active Directory. Without it, users get disconnected after 60 minutes every time. The only supported fix is to buy new per-device CALs (there's a Convert-License PowerShell cmdlet that can migrate the pack, but check with your reseller — volume-licence-agreement terms may prevent conversion).
RDS CAL version compatibility
The rule: CALs work for the same or older Windows Server, never newer.
| Session host version | 2025 CAL | 2022 CAL | 2019 CAL | 2016 CAL |
|---|---|---|---|---|
| Windows Server 2025 | ✓ | ❌ | ❌ | ❌ |
| Windows Server 2022 | ✓ | ✓ | ❌ | ❌ |
| Windows Server 2019 | ✓ | ✓ | ✓ | ❌ |
| Windows Server 2016 | ✓ | ✓ | ✓ | ✓ |
Practical takeaway: if you're deploying Server 2025, you need 2025 CALs. If you have spare 2022 CALs from an old project, they won't work with a 2025 session host — Microsoft doesn't allow "downgrade" of CALs to a newer host.
The licence server itself follows the same rule — it must run a Windows Server version equal to or newer than the CALs it issues. A 2022 licence server cannot install 2025 CALs; a 2025 licence server can install any 2025, 2022, 2019, or 2016 CALs.