How Many RDS CALs Do You Need? Sizing Remote Desktop the Right Way

Fix it now

RDS CALs sit on top of everything else: the Windows Server licence for the host, an ordinary Windows Server CAL for each user or device, and then an RDS CAL as well. They are counted by named user or named device, never by simultaneous connection, and the grace period is 120 days rather than an allowance.

1. Count named users if people connect from more than one machine each, and named devices if machines are shared by more people than there are machines. Nothing else decides it.
2. Budget the base CAL alongside the RDS CAL. Microsoft’s licensing guidance states the RDS CAL is required in addition to the base CAL for every user or device accessing the advanced functionality.
3. Choose per-user for remote and hybrid staff. In per-device mode every machine anyone ever connects from consumes a licence, including the one they used once from a hotel.
4. Choose per-device for shift work on shared terminals, and note the mechanics: a temporary RDS CAL is assigned on first sign-in per device and is valid for 90 days, so the pool depletes on a delay.
5. Match the CAL version to the host. Microsoft’s example is explicit: Windows Server 2022 RDS CALs connect to a 2022 session host or earlier, but not to a Windows Server 2025 session host.
6. Install and activate the licence server well before day 120. Microsoft documents a 120-day grace period during which no licence server is required, after which clients need a valid RDS CAL issued by one before they can sign in.

For a handful of people who each need to reach their own desktop PC, this is the wrong article: Microsoft states that Windows Professional, Enterprise and Education editions can act as hosts for incoming Remote Desktop connections, and that route involves no RDS CALs at all.

If the sharing pattern is obvious, buy that type at the right version and stop here. Below is the three-layer structure, the enforcement differences that decide how much attention this needs, and how to size a mixed site.

Why it happens

Three layers stack here and skipping one is the most expensive mistake in remote desktop licensing. Layer one is the host: Windows Server licensed across all its physical cores like any other server, plus the instance rights to run it if the session host is a virtual machine. That layer is unrelated to how many people log on. Layer two is the ordinary Windows Server CAL, which every user or device needs in order to authenticate to Windows at all. Layer three is the RDS CAL, which Microsoft’s own licensing guidance describes as required in addition to the base CAL for every user or device accessing the advanced functionality.

People setting up a first deployment buy the RDS CALs and stop, on the reasonable-sounding assumption that a licence called Remote Desktop Services must cover remote desktop. It covers the additional right to run a session. It does not cover the underlying access, and the base CAL is not optional.

The two shapes work the same way as base CALs – a per-user RDS CAL covers a named person from any device, a per-device RDS CAL covers a device used by any number of people – but the enforcement is very different, and that difference should shape how you run the deployment. Microsoft documents that in the per-user model licensing is not enforced and each user is granted a licence to connect from any number of devices, and that per-user CALs can be over-allocated in breach of the Remote Desktop licensing agreement. Per-device CALs are issued and tracked against the devices themselves.

One thing to be clear about before you plan: there is no concurrent option to buy. The models are per named user and per named device, and the enforcement asymmetry between them is a technical fact rather than a licensing permission. A per-user deployment that lets everybody in is not evidence that you are licensed for everybody.

Full reference

Per user against per device, on Microsoft’s own documented behaviour

Sizing it for how people actually work

Take the classic example. Sixty staff work three shifts of twenty on twenty thin clients. Per-user licensing costs sixty CALs because sixty distinct people sign in. Per-device costs twenty, because the terminals are what is shared. Now invert it: twenty consultants each connect from an office desktop, a laptop and a phone. Per-user costs twenty; per-device costs sixty. The pattern of sharing decides it and nothing else does.

Two details complicate real counts. Personal and home devices are a per-device disaster, because every machine anyone ever connects from consumes a licence – so any deployment with remote or hybrid working should be per-user unless there is a strong reason otherwise. And the per-device pool depletes on a delay: Microsoft documents that a temporary CAL is assigned on first sign-in and is valid for 90 days, so a shortage shows up a season after the devices arrived rather than on the day.

The 120-day clock

Microsoft documents a licensing grace period of 120 days during which no licence server is required, and states that once it ends, clients must have a valid RDS CAL issued by a licence server before they can sign in to a remote session. That is a deadline for building the licensing infrastructure, not an allowance to run on. Install and activate the licence server, install the CALs on it, and confirm the session hosts are pointed at it well before the date – then diary the date anyway, because a deployment that goes quiet on day 121 is a bad afternoon.

The version rule, with Microsoft’s own example

RDS CALs reach backwards, never forwards, and Microsoft’s documentation gives the example directly: with RDS CALs for Windows Server 2022 you can connect to a session host running Windows Server 2022 or earlier, but you cannot use them to connect to a session host running Windows Server 2025. Moving a farm to a newer Windows Server version therefore means RDS CALs at that version, exactly as it does for base CALs – and the base CALs need checking at the same time, since they follow the same rule.

Living with per-user, which is not enforced

Microsoft is explicit that in the per-user model licensing is not enforced and that the CALs can be over-allocated in breach of the Remote Desktop licensing agreement. Practically, that means the farm will not stop you at the boundary and nothing will tell you that you have crossed it. Organisations that grow steadily discover this at audit rather than at deployment.

1. Reconcile after any significant hiring round or new department onboarding, rather than annually.
2. Compare the number of distinct people who sign in against the number of RDS CALs you actually own, and record the date you checked.
3. Check the base Windows Server CAL count at the same time, because it moves with the same population and is the layer people forget.
4. Re-check the version position whenever a session host is upgraded, since CALs never reach forwards.

When there is nothing to buy

• A handful of people each reaching their own desktop PC: Microsoft states that Windows Professional, Enterprise and Education editions can act as hosts for incoming Remote Desktop connections. That is a per-machine route with no RDS CALs involved.
• Administrative access to a server for management: this is not the same thing as an RDS deployment, but the boundary is a licensing question rather than a technical one. Get the position for your own agreement in writing before you rely on it, and do not treat it as a way to run a line-of-business application for two people.
• A deployment you would rather not host at all: compare against Azure Virtual Desktop or Windows 365, where the Windows licensing is carried per user through eligible subscriptions instead of RDS CALs.

What cannot be changed later

The licensing mode on a session host can be changed, but the CALs themselves cannot be converted between types. Switching a deployment from per-device to per-user means owning CALs of the new type, so the sharing pattern is a decision to make before the purchase rather than after it. The only partial relief is on the per-device side, where Microsoft documents that up to 20 percent of RDS CALs can be revoked – useful for devices that have genuinely gone, not a mechanism for changing your mind about the model.

Questions people ask about this