RDS CALs are the part of Windows Server licensing that catches people out most often, and the reason is simple: nothing stops you using the feature before you have bought them. You install Windows Server, enable Remote Desktop Services, connect a dozen users, and everything works. Then, four months later, the connections start being refused and you discover there was a licence you were supposed to buy on day one.
This guide explains what an RDS CAL is, why it sits on top of a licence you have probably already bought, how the user and device models differ, how the version rule works and why it invalidates more licences than anything else in the Microsoft catalogue, how the licensing role is actually installed and activated, and what happens when the grace period runs out. It also covers the awkward parts: what RDS CALs do not cover, why cheap ones on marketplaces are the way they are, and the errors that show up when something in the chain is misconfigured.
If you want the summary first: to let someone connect to a Windows Server and use a desktop or an application session, you need three things. A Windows Server licence for the machine, a Windows Server CAL for the person or device connecting, and an RDS CAL on top of that for the remote session itself. All three are separate purchases. The RDS CAL comes in a user flavour and a device flavour, it must match or exceed the version of the server it is used against, and it has to be installed on an activated licence server that the session hosts know about. Get those parts right and Remote Desktop Services is dependable. Get one wrong and it fails on a schedule.
[image: A Windows Server Remote Desktop Licensing Manager window showing an activated licence server with installed RDS CAL packs and available licence counts]
What an RDS CAL actually is
An RDS CAL is a Remote Desktop Services Client Access Licence. It grants a user or a device the right to run a remote session on a Windows Server, whether that session is a full desktop or a single published application. It is a permission, not a piece of software, and that distinction explains almost every misunderstanding people have about it.
Nothing about an RDS CAL makes a connection work. The Remote Desktop Services role does that. The CAL exists in the licence agreement and, once you have bought some, in a database on a licence server that hands out and tracks entitlements. If you never install the licensing role, Remote Desktop Services still functions for a defined grace period and then stops accepting connections, which is why the problem tends to arrive months after the deployment rather than during it.
The other thing to understand is that an RDS CAL is additive. It does not replace the standard Windows Server CAL, it sits on top of it. A user connecting to a Remote Desktop session needs both: the base CAL for accessing the server at all, and the RDS CAL for the remote session specifically. People who have only bought one of the two are extremely common, and it is almost always the RDS half that is missing because the base CAL usually arrives bundled with the server purchase conversation.
The short answer on RDS CALs
Buy one RDS User CAL for each named person who will connect remotely, if those people connect from more than one machine each. That covers a laptop, a home desktop, a tablet and a phone for the same person under a single licence, and it is the right model for most modern organisations because most people now use several devices.
Buy one RDS Device CAL for each machine that will connect, if you have shared devices used by several people. A shift-based operation with twenty terminals and sixty staff needs twenty Device CALs, not sixty User CALs, and the saving is substantial. Warehouses, factory floors, clinics, call centres and retail counters are the classic cases.
In both cases, buy the CAL version that matches or exceeds your server version, install the Remote Desktop Licensing role somewhere on the network, activate it, install the CAL packs onto it, and point your session hosts at it. Then verify that it is actually issuing licences rather than sitting in grace period, because a licence server that is installed but not correctly referenced is a very common and very quiet failure.
Why you need more than one licence to allow a remote session
This is the structural part, and it is worth getting straight before anything else, because the layers are what confuse people.
Layer one: the server licence
Windows Server itself is licensed per physical core on the machine it runs on, with minimums of eight cores per processor and sixteen cores per server. That licence covers the operating system being installed and running. It does not cover anybody connecting to it. If you are unclear on how the core model works, or on whether you need Standard or Datacenter for the host in question, our guide to Windows Server Standard vs Datacenter covers the whole edition decision, and the edition makes no difference at all to the RDS CAL requirement.
Layer two: the Windows Server CAL
Every user or device that accesses the server needs a Windows Server CAL. This applies whether the access is a mapped drive, a print queue, an authentication against a domain controller or a Remote Desktop session. It is the baseline right of access, and it comes in user and device variants of its own. Our full guide to Windows Server client access licences covers how to choose between those and how many you need.
Layer three: the RDS CAL
On top of the base CAL, anyone using Remote Desktop Services needs an RDS CAL. This is the additional right to run a session on the server rather than simply consume a file or a printer from it. It is a separate product with a separate purchase, a separate licence server and separate installation steps.
People react to this with some irritation, and the irritation is understandable, but the logic is consistent: the base CAL is access, the RDS CAL is session hosting. A file server serving a hundred users needs a hundred base CALs and no RDS CALs at all. A terminal server serving ten users needs ten of each. The layers are not arbitrary, they just are not obvious from the product names.
RDS User CAL or RDS Device CAL
This is the decision that actually costs or saves money, and both models are the correct answer in different situations.
How the User CAL works
An RDS User CAL is assigned to a named person. That person can connect to Remote Desktop Services from as many devices as they like: an office desktop, a laptop at home, a tablet on the train, a phone in an airport. The licence follows the human being.
The licence server tracks user CALs in the Active Directory, which is worth knowing because it affects how the tracking behaves. In a domain environment, per-user CAL issuance is recorded against the user object and can be reported on. In a workgroup, per-user tracking is not properly supported, which is a real constraint on small deployments without a domain and one that surprises people who assumed workgroup and domain would behave the same way.
User CALs suit knowledge workers, remote staff, anyone with a laptop, anyone who occasionally connects from a personal machine, and any organisation where the ratio of devices to people is greater than one. In practice that is most offices now.
How the Device CAL works
An RDS Device CAL is assigned to a machine. Anyone can sit at that machine and connect, and the same licence covers all of them. The licence follows the hardware.
Device CAL issuance is handled differently from user CALs. A device CAL is issued for a randomised period, typically somewhere between fifty-two and eighty-nine days, and it is renewed automatically when the device connects again during that window. That randomisation exists so that a large estate does not have all its licences expire on the same day. If a device is retired, its CAL returns to the pool at the end of its issuance period rather than immediately, though it can be revoked manually within limits.
Device CALs suit shared workstations, shift-based operations, kiosk terminals, thin clients, shop floor stations and any environment where several people use the same physical machine at different times of day. The rule of thumb is straightforward: if your device-to-person ratio is below one, device CALs are cheaper.
Mixing both models
You can use both in the same environment, and plenty of organisations should. A manufacturing business might buy device CALs for twenty shop floor terminals shared by seventy operators, and user CALs for its twelve office staff who each work from a desktop and a laptop. That combination is entirely legitimate and it is usually the cheapest correct answer.
What you cannot do is double-dip: a single session cannot be covered by a device CAL on one day and a user CAL on the next as a way of buying fewer of each. Assign the model per user or per device deliberately, document which is which, and keep the count honest. The licence server will track what it issues, but it will not stop you from being under-licensed, and it is not designed to.
How to choose in five minutes
Count the people who will connect remotely. Count the distinct devices they will connect from. If people outnumber devices, buy device CALs. If devices outnumber people, buy user CALs. If the numbers are close, buy user CALs, because device counts grow quietly as phones and personal laptops enter the picture and user counts are easier to control.
Then check whether you have a domain. If you do not, per-user tracking will not work properly and device CALs become the practical choice regardless of the arithmetic. That single detail decides more small deployments than the cost comparison does.
RDS CAL comparison at a glance
| Consideration | RDS User CAL | RDS Device CAL |
|---|---|---|
| Assigned to | A named person | A physical device |
| Covers unlimited devices per person | Yes | No |
| Covers unlimited people per device | No | Yes |
| Tracked in Active Directory | Yes | No |
| Works properly in a workgroup | No | Yes |
| Issued for a fixed period | No | Yes, roughly 52 to 89 days |
| Can be revoked before expiry | Not applicable | Yes, subject to a limit |
| Requires a base Windows Server CAL as well | Yes | Yes |
| Must match or exceed the server version | Yes | Yes |
| Requires an activated licence server | Yes | Yes |
| Best for shared terminals | No | Yes |
| Best for staff with several devices | Yes | No |
| Counted against the licence pool automatically | Yes | Yes |
The table looks balanced, and in a sense it is, but the workgroup row is the one that quietly removes the choice for a lot of small deployments.
The version rule, and why it invalidates so many licences
This is the single most expensive misunderstanding in Remote Desktop licensing, and it is worth reading twice.
CALs must match or exceed the server version
An RDS CAL is version specific. A Windows Server 2019 RDS CAL works against a Windows Server 2019 session host. It does not work against a Windows Server 2022 session host. The rule is that the CAL version must be equal to or higher than the version of the server providing the session, which means CALs work downward but never upward.
A Windows Server 2022 RDS CAL will happily service a 2019 or a 2016 session host. A 2016 CAL will not service a 2022 one. When you upgrade the session hosts, you buy new CALs, and that cost belongs in the upgrade budget from the beginning rather than arriving as a surprise once the new servers are built.
What this means when you upgrade
The practical consequence is that an operating system upgrade on a Remote Desktop deployment is never just an operating system upgrade. If you move fifty users from a 2019 session host to a 2022 one, you need fifty new RDS CALs of the 2022 vintage, plus the base CALs at the same version level, plus the server licence for the new host.
Licence servers can hold CAL packs of several versions at once, which is helpful during a migration. A licence server with both 2019 and 2022 packs installed will issue the right one to the right session host, so a phased migration does not require a big-bang cutover. Plan for both sets to coexist for a while and retire the old ones once the last old host is gone.
If you are working out which version to move to in the first place, our comparison of Windows Server 2019 against 2022 and 2025 covers what changed between releases, and if you are still on 2019 the support clock matters, which we cover in our guide to Windows Server 2019 end of life. Decide the version before you buy the CALs, not after.
Software Assurance and version rights
RDS CALs bought with Software Assurance carry upgrade rights, so a new version of the CAL arrives with the new version of the product rather than as a separate purchase. For an organisation that upgrades on a regular cycle, that is frequently cheaper over the life of the deployment than buying fresh CALs each time, and it removes the version mismatch problem entirely.
For an organisation that buys a server, runs it for eight years and then replaces the whole thing, Software Assurance is usually not worth it. The decision comes down to how often you actually upgrade, and most people upgrade less often than they plan to.
How RDS CALs are actually deployed
Buying the licences is the easy half. Making the deployment aware of them is where things go wrong, and the steps are not difficult but they are unforgiving about order.
Install the Remote Desktop Licensing role
The licensing role can live on a session host, on a domain controller, or on a separate server, and for anything beyond a single-server deployment it should be somewhere that does not get rebuilt casually. It is a light role with almost no resource requirement, so a small utility server or an infrastructure virtual machine is a sensible home for it.
You add it through Server Manager as the Remote Desktop Licensing role service, or through PowerShell. In a full Remote Desktop Services deployment the deployment wizard will prompt for it as part of the process. The role itself does nothing useful until it is activated, which is the next and most commonly skipped step.
Activate the licence server
An installed licence server is not an activated licence server. Activation registers it with the Microsoft clearinghouse and is what allows CAL packs to be installed onto it. You do it through the Remote Desktop Licensing Manager console, and it can be done automatically over the internet, through a web browser on another machine, or by telephone if the server has no outbound access.
Once activated, the licence server shows a green status in the console. If it shows anything else, nothing downstream will work correctly, and it is the first thing to check when licensing errors appear. An unactivated licence server is the single most common cause of an RDS deployment that worked for four months and then stopped.
Install the CAL packs
With the server activated, you install the CALs you have bought using the licence key pack identifier or agreement number that came with them. The console walks through it, and once complete, the installed count and the available count appear in the licensing manager.
Check those numbers afterwards. It is possible to install a pack against the wrong licensing programme or the wrong version and end up with licences that exist but cannot be issued to the hosts you have. The console will show you exactly what is installed and at what version, and reading it once at install time saves a great deal of confusion later.
Point the session hosts at the licence server
Each session host needs to know which licence server to use and which licensing mode to run in, and this is where most silent failures live. You set both through Group Policy under the Remote Desktop Session Host licensing settings, or per-server through the deployment properties in Server Manager.
Two settings matter. The first specifies the licence server or servers to use. The second specifies the licensing mode, per user or per device, and it must match the CAL type you actually bought. A host configured for per-device mode with a pool of user CALs installed will refuse to issue anything, and the error message it produces does not make the mismatch obvious.
After configuring, verify rather than assume. The Remote Desktop licensing diagnoser on the session host reports whether it can see the licence server, whether the mode matches, and whether licences are available. If it reports a problem, fix it that day, because the grace period is the only thing keeping the deployment alive and it is finite.
The workgroup caveat
Per-user CAL tracking depends on Active Directory. In a workgroup deployment there is no directory to record issuance against, so per-user mode does not function properly and the practical route is per-device licensing. If you are running a small Remote Desktop deployment without a domain, plan on device CALs from the outset rather than discovering the limitation after purchase.
[image: The Remote Desktop Licensing Diagnoser on a Windows Server session host showing licensing mode, discovered licence server and licence availability status]
The grace period, and what happens when it ends
Windows Server gives a Remote Desktop Services deployment a 120-day licensing grace period from the first time a client connects. During that window, sessions work with no licence server, no CALs and no configuration at all. This is intentional and it is meant to let you build a deployment before the licensing infrastructure is finished.
It is also why so many organisations discover the requirement four months in. The deployment works perfectly, everyone forgets it was ever a question, and then on a Monday morning the connections start being refused with a message about no licences being available. Nothing changed on the server. The clock simply ran out.
The grace period cannot be extended, reset by rebuilding the licensing configuration, or renewed by reinstalling the role. It is tied to the session host and it runs once. When it expires, remote sessions are refused until a licence server with valid CALs is reachable and correctly configured. Administrative connections still work, which is what lets you fix the problem, but ordinary users are locked out.
The practical lesson is to treat the grace period as a build window rather than a runway. Install and activate the licence server, install the CALs and verify issuance during the deployment, and confirm with the diagnoser that the host is issuing real licences rather than running on grace. That check takes two minutes and it is the difference between a planned purchase and an emergency one.
How many RDS CALs you actually need
The count is simpler than the base CAL count because the population is narrower: only people or devices that use Remote Desktop sessions need one.
For user CALs, count named individuals who will connect, not concurrent sessions. This is the point people most often get wrong. RDS CALs are not concurrency licences. If forty people can connect and only eight are ever connected at once, you need forty CALs, not eight. There is no concurrent licensing model for RDS in the standard programmes, and assuming there is has produced some very unpleasant audit conversations.
For device CALs, count the physical machines that will connect. A terminal used by three shifts is one device and needs one CAL. A thin client that sits idle most of the week still needs one if it is ever used.
Include everyone who connects, not only employees. Contractors, temporary staff, auditors, external support engineers and anyone else who runs a session counts. Service accounts that establish sessions count too. The population is whoever or whatever actually connects, regardless of their relationship to the organisation.
Build in headroom. Licence servers do not stop issuing when you run out in the way people expect, and over-issuance beyond your purchased count is a compliance breach rather than a technical block. Counting once a year and adjusting is a reasonable rhythm for a stable organisation, and more often if you are growing.
RDS CALs in virtual environments
Virtualisation does not change the CAL requirement, but it does change where people think the requirement sits, so it is worth being explicit.
If a session host is a virtual machine, the users connecting to it need RDS CALs exactly as they would for a physical host. The CAL follows the user or the device, not the hardware, so the virtualisation layer is irrelevant to the count. What virtualisation does affect is the underlying Windows Server licensing, because each virtual machine running Windows Server consumes an operating system environment from the host licence.
That is where the edition question comes back. A host running several session hosts as virtual machines may exceed the two-instance entitlement that Standard grants, and at that point either you stack Standard licences or you move to Datacenter. Our guide to Windows Server Standard vs Datacenter covers where that break-even sits. The RDS CAL count does not change either way.
One further point on licence server placement in virtual environments: put the licensing role somewhere durable. A licence server that lives on a virtual machine which gets rebuilt during a maintenance window takes its CAL database with it, and while the CALs can be reinstalled, doing so under pressure with users locked out is not how anyone wants to spend an afternoon. Back up the licence server, or at least record the licence pack details somewhere you can find them.
RDS CALs, Azure and the cloud alternatives
This is where a lot of current confusion sits, because Microsoft now offers several ways to deliver a remote desktop and they are licensed very differently.
Traditional Remote Desktop Services on Windows Server, whether on your own hardware or on a virtual machine you run in a cloud, uses RDS CALs as described throughout this guide. Running the server in Azure does not change that. If you build a Windows Server session host on an Azure virtual machine, you still need RDS CALs for the users connecting to it, and you still need a licence server.
Azure Virtual Desktop is a different service with a different model. Access rights come from Microsoft 365 or Windows licensing rather than from RDS CALs, which is one of the reasons organisations already paying for Microsoft 365 find it attractive. Windows 365 Cloud PC is different again, sold as a per-user subscription that includes the access right. Neither of those uses the RDS CAL mechanism at all.
The practical guidance is to decide the delivery model before buying anything. If you are running your own Windows Server session hosts, budget RDS CALs. If you are moving to a Microsoft-hosted desktop service, do not buy RDS CALs for it, because they will not be used. Buying the wrong one is an expensive mistake and it happens more often than it should, usually because the purchase was made before the architecture was settled. Microsoft documents the current licensing requirements for Remote Desktop Services on its Remote Desktop Services client access licensing page, which is the reference worth checking when the details matter.
What RDS CALs do not cover
Being clear about the boundaries prevents a specific set of expensive assumptions.
Multiple sessions on Windows client editions
An RDS CAL does not give you the right to run multiple simultaneous remote sessions on Windows 10 or Windows 11. Client editions of Windows accept one incoming remote session at a time, regardless of edition, and no CAL changes that. Multi-session Windows exists only as Windows 11 Enterprise multi-session in Azure Virtual Desktop, which is a different product with a different licence. If you need several people using one machine remotely, you need Windows Server with Remote Desktop Services, not a workstation with a licence bolted on.
Administrative connections
Windows Server allows two administrative remote sessions plus a console session without any RDS CAL at all. That entitlement exists for server management and it is explicitly not for running workloads. Using those two connections to let two staff members do their daily work is a licensing breach, and it is one auditors ask about directly because it is such a common shortcut.
The base Windows Server CAL
Worth restating because it is the most frequent gap: an RDS CAL does not include the base CAL. Both are required. If your purchase covered only the RDS half, you are under-licensed, and the fix is to buy the base CALs at the matching version. Our guide to Windows Server CALs covers what the base licence involves and how to count it.
Other server products
An RDS CAL covers the remote session, not the applications running inside it. SQL Server, Exchange, SharePoint and any other server product accessed from within that session have their own licensing, and in the case of SQL Server the multiplexing rules mean that users accessing a database through an application in a remote session generally still need SQL CALs. Remote sessions do not launder access requirements, and assuming they do is a well-known way to fail an audit.
Where cheap RDS CALs come from
Search for RDS CALs and you will find listings at a small fraction of what they cost through a legitimate channel, often described as fifty user CALs for the price of a takeaway. It is worth understanding the mechanics, because the mechanics explain the risk far better than a warning does.
RDS CALs are sold through volume licensing agreements, through Cloud Solution Providers, and bundled with OEM server purchases. A cheap CAL pack on a marketplace is generally one of a few things. It may be an agreement number lifted from a volume licensing customer and resold to many buyers, which works until Microsoft correlates the activations and the pack stops installing. It may be issued under an academic, charity or partner agreement that does not permit resale, in which case the licence exists but you are not entitled to it. Or it may simply be a key that installs a smaller pack than advertised, discovered only when the console shows a count that does not match the invoice.
The failure mode is worse than with a desktop operating system key. A workstation with a broken licence shows a watermark and keeps working. A Remote Desktop deployment whose CAL pack is revoked stops issuing licences, and once the grace period is gone, users cannot connect at all. The outage is total and it arrives without notice, on a service that an entire team may depend on for their day.
There is also the audit dimension. RDS deployments are visible: they involve a licence server that records issuance, session hosts with configuration in Group Policy, and a user population that is easy to count. Of all the licensing in a typical estate, this is one of the easiest for an auditor to reconstruct, which makes it a poor place to economise creatively. Our page on how licensing works at Kymakers sets out where the licences we stock come from and what we will not sell.
[image: A Remote Desktop Licensing Manager console showing a licence key pack with an installed count and an issued count for RDS per user CALs]
How to check what is installed and what is being used
Before buying more CALs, find out what you already have, because inherited deployments are frequently not what the documentation claims.
Open Remote Desktop Licensing Manager on the licence server. It lists every installed key pack, the version, the licensing programme it came from, the total installed count and the number currently issued. That single view answers most questions about the state of a deployment, including whether the server is activated and whether the packs match the servers you are running.
For usage over time, the licensing manager includes a per-user CAL report that lists which users have been issued licences. It is generated on demand rather than continuously, and it is the closest thing to an audit trail the tooling provides. Run it before an internal review rather than during one.
On the session host, the Remote Desktop licensing diagnoser reports the configured licensing mode, the discovered licence servers, and whether any problems are preventing issuance. If you check one thing on a deployment you have inherited, check this, because it will tell you immediately whether the host is issuing real licences or quietly running on a grace period that is about to expire.
To confirm what the servers themselves are, the usual tools apply: Server Manager, winver, systeminfo and the slmgr script with the dlv switch. Our guide on identifying which Windows version you are running walks through them, and the version matters here because it determines which CAL version you need.
The licensing errors people actually hit
These four cover the large majority of Remote Desktop licensing support calls, and each has a specific cause.
No Remote Desktop licence server is available
The session host cannot find a licence server, or found one that cannot serve it. Check that the licence server name is correctly configured in Group Policy or deployment properties, that the server is reachable on the network, that it is activated, and that it holds CALs of the right version. In a domain, also confirm the licence server is a member of the Terminal Server License Servers group in Active Directory, which is a requirement people frequently miss.
The grace period has expired
Exactly what it says. The 120 days ran out and no valid licensing was in place. There is no way to extend it. Install and activate a licence server, install the correct CAL packs, configure the host to use it, and connections resume. Administrative sessions remain available throughout, which is how you get in to fix it.
The licensing mode is not configured or does not match
The host is set to per-device mode while the licence server holds per-user CALs, or the mode has not been set at all. Set the mode to match the CALs you own. This mismatch produces errors that sound like a missing licence server, which sends people looking in the wrong place for hours.
The licence server is not activated
The role is installed, the packs may even appear to be present, but activation never completed. The licensing manager shows the server status, and an unactivated server cannot issue anything. Activate it through the console, over the internet if the server has outbound access or by the alternative methods if not.
One more diagnostic habit worth adopting: when licensing errors appear on a client, note whether they affect everyone or only some users. A problem affecting everybody usually points at the licence server or the mode. A problem affecting a subset usually points at the CAL count having been exhausted, which is a purchasing problem rather than a configuration one.
Alternatives to buying RDS CALs
Sometimes the right answer is not to buy them, and it is worth knowing what the alternatives look like before committing.
If your users need a full Windows desktop delivered from the cloud, Windows 365 sells that as a per-user subscription with the access right included, and no RDS CAL is involved. It costs more per user per month than an RDS CAL amortised over years, and it removes the server, the licence server and the maintenance entirely. For a small organisation with no server administrator, that trade is often worth it.
Azure Virtual Desktop delivers session-based or personal desktops from Azure, with access rights coming from Microsoft 365 or Windows subscriptions that many organisations already hold. If you are already paying for Microsoft 365 E3 or Business Premium, the access side may effectively be covered, and the cost becomes the Azure compute rather than the licensing.
If the actual requirement is remote access to a handful of individual workstations rather than shared session hosting, third-party remote access tools sidestep the RDS model entirely. They have their own subscription costs and their own security considerations, but for a business where five people need to reach their own office PCs from home, standing up a Remote Desktop Services deployment with a licence server and CALs is disproportionate.
And if the requirement is simply that people can work with files from anywhere, the honest answer is often that a remote desktop is the wrong tool. Cloud file services and web applications solve that problem without a session host in the middle. Remote Desktop Services earns its place when the application genuinely has to run on a server, which is a narrower case than the number of RDS deployments in the world would suggest.
The honest trade-offs
RDS CALs are a real cost on top of a cost, and in a user-heavy deployment they can exceed what the server operating system licence cost. That is uncomfortable and it is worth confronting at budget time rather than discovering during deployment. The counter is that a properly licensed Remote Desktop deployment is cheap per user compared with issuing everyone a capable laptop, and it centralises application management in a way that saves real administrative time.
The version rule is the other genuine friction. Being obliged to repurchase CALs at every server upgrade discourages upgrading, which is precisely the wrong incentive from a security perspective, and it is one of the reasons so many Remote Desktop deployments are running on operating systems well past their prime. Software Assurance addresses it for organisations that upgrade regularly, at a cost that only makes sense if you actually do.
The device model versus user model choice is a genuine trade-off rather than a trick question. Device CALs are cheaper in shared environments and become a liability the moment people start working from home on their own machines. User CALs cost more up front and stop the count creeping every time someone buys a tablet. Choosing the wrong one is not fatal, but changing later means buying again, so the five minutes spent counting properly at the start is well spent.
And there is a trade-off in the grace period itself. It is genuinely helpful, because it lets you build without blocking on procurement. It is also the reason a substantial number of organisations are unknowingly running unlicensed deployments right now, because nothing ever told them the clock was running. A feature that helps administrators and creates compliance exposure in the same breath is a difficult thing to be entirely positive about.
Mistakes people keep making
Assuming RDS CALs are concurrent licences. They are not. You license every named user or every device, not the peak number of simultaneous sessions.
Buying RDS CALs and forgetting the base Windows Server CALs. Both are required for every user or device connecting. This is the single most common gap.
Buying CALs of the wrong version. A 2019 CAL will not service a 2022 host. CALs work downward, never upward.
Installing the licensing role and never activating it. An unactivated licence server issues nothing, and the deployment coasts on grace until it stops.
Setting the licensing mode to a type you did not buy. Per-device mode with per-user CALs installed fails in a way that looks like a missing licence server.
Running per-user CALs in a workgroup. Per-user tracking needs Active Directory. Without a domain, use device CALs.
Treating the two administrative connections as a licensing strategy. They are for server administration and using them for daily work is a breach that auditors ask about specifically.
Putting the licence server on a machine that gets rebuilt. When it goes, the CAL database goes with it, and reinstalling under pressure is miserable.
Expecting RDS CALs to cover Azure Virtual Desktop or Windows 365. They do not. Those services use entirely different licensing.
Buying a marketplace CAL pack because the price looked reasonable. When the pack is revoked, the deployment stops accepting connections, and the outage is total rather than cosmetic.
A practical way to decide and deploy
Work through this in order and the deployment will be correct rather than accidentally correct.
First, confirm you actually need Remote Desktop Services. If the requirement is file access from anywhere, or a handful of people reaching their own desktops, there are lighter answers. RDS is for shared session hosting of applications that must run on a server.
Second, decide the delivery model. Your own Windows Server session hosts means RDS CALs. Azure Virtual Desktop or Windows 365 means a different licence entirely and no RDS CALs at all. Settle this before purchasing anything.
Third, pick the server version, and pick a current one. The CAL version is tied to it, and buying CALs for a version you are about to leave behind is money spent twice.
Fourth, count. Named users who will connect, and distinct devices they will connect from. If people outnumber devices, buy device CALs. If devices outnumber people, buy user CALs. If you have no domain, buy device CALs regardless.
Fifth, buy the base Windows Server CALs at the same version as well. Both layers are required and the base layer is the one that gets forgotten.
Sixth, install the licensing role somewhere durable, activate it, install the CAL packs, and confirm the counts in the licensing manager.
Seventh, configure the session hosts with the licence server name and the correct licensing mode, then run the licensing diagnoser and confirm it reports no problems and that licences are being issued.
Eighth, write down what you bought, which version, which model and how many, and put it somewhere that survives staff changes. The next person to touch this deployment will need it, and there is a reasonable chance the next person is you in three years with no memory of any of it.
Frequently asked questions about RDS CALs
Do I need an RDS CAL and a Windows Server CAL?
Yes, both. The Windows Server CAL grants the right to access the server at all. The RDS CAL grants the additional right to run a Remote Desktop session on it. They are separate products and separate purchases, and having only one of the two is the most common licensing gap in Remote Desktop deployments.
Are RDS CALs concurrent licences?
No. You need one for every named user or every device that connects, not for the maximum number of simultaneous sessions. If sixty people can connect and twelve connect at once, you need sixty user CALs. There is no concurrent model in the standard licensing programmes.
Can I use Windows Server 2019 RDS CALs with a 2022 server?
No. CAL versions work downward, not upward. A 2022 CAL can service a 2019 or 2016 host, but a 2019 CAL cannot service a 2022 one. Upgrading the session hosts means buying CALs at the new version, and that cost belongs in the upgrade budget.
What happens when the 120-day grace period ends?
Remote sessions stop being accepted until a properly configured and activated licence server with valid CALs is available. The grace period cannot be extended or reset. Administrative connections continue to work, which is how you get in to fix it.
Do I need RDS CALs for administrative access?
No. Windows Server permits two administrative remote sessions plus a console session without any RDS CAL. That entitlement is for managing the server, not for running user workloads, and using it as a way to give two people a working desktop is a licensing breach.
Should I choose user CALs or device CALs?
Count both populations. If people outnumber devices, device CALs are cheaper. If devices outnumber people, user CALs are cheaper. If you have no Active Directory domain, choose device CALs, because per-user tracking depends on the directory and does not function properly in a workgroup.
Can I mix user CALs and device CALs?
Yes. Many organisations should, using device CALs for shared terminals and user CALs for staff with several devices. What you cannot do is cover the same person or device under both models alternately to reduce the total count.
Do RDS CALs cover Azure Virtual Desktop?
No. Azure Virtual Desktop derives its access rights from Microsoft 365 or Windows subscriptions rather than from RDS CALs. Windows 365 includes the access right in its per-user subscription. RDS CALs apply to Windows Server session hosts, including ones you run on Azure virtual machines yourself.
Do I need RDS CALs if the session host is a virtual machine?
Yes. The CAL follows the user or the device, not the hardware, so virtualisation makes no difference to the count. What virtualisation does affect is the Windows Server licensing of the host, where the number of virtual machines determines whether Standard or Datacenter is appropriate.
Can I run several remote sessions on Windows 11 with an RDS CAL?
No. Windows client editions accept one incoming remote session at a time and no CAL changes that. Multi-session Windows exists only as Windows 11 Enterprise multi-session within Azure Virtual Desktop. For several simultaneous users you need Windows Server with Remote Desktop Services.
Where should the licence server live?
Anywhere durable on the network. It can share a machine with a session host or a domain controller, or run on its own small server. The role is very light. What matters is that it is not on a machine that gets rebuilt casually, because the CAL database lives there.
Can device CALs be reassigned when a machine is retired?
A device CAL is issued for a randomised period of roughly fifty-two to eighty-nine days and returns to the pool when it expires. You can also revoke a limited proportion of issued device CALs manually through the licensing manager, which covers the case of hardware being replaced ahead of expiry.
Do RDS CALs cover the applications running in the session?
No. SQL Server, Exchange, SharePoint, Office and any other product accessed inside the session have their own licensing. A remote session does not remove the access requirements of the software running in it, and the multiplexing rules mean indirect access generally still counts.
How do I check how many CALs I have?
Open Remote Desktop Licensing Manager on the licence server. It shows each installed key pack, its version, the licensing programme, the total installed and the number issued. The per-user CAL report gives usage detail, and the licensing diagnoser on a session host confirms whether issuance is actually working.
The bottom line on RDS CALs
An RDS CAL is the right for a person or a device to run a Remote Desktop session on a Windows Server, and it sits on top of the base Windows Server CAL rather than replacing it. It comes in user and device flavours, it must match or exceed the version of the server it serves, and it only functions once it has been installed on an activated licence server that the session hosts are configured to use.
The three things that go wrong most often are all avoidable. People buy only one of the two required CAL layers. People buy CALs at the wrong version, usually a version behind. And people build a deployment inside the 120-day grace period, never finish the licensing configuration, and find out four months later when connections start failing. Each of those takes minutes to prevent and days to resolve under pressure.
Count named users and distinct devices, choose the model that fits your ratio, check whether you have a domain before assuming per-user tracking will work, buy at the version you are actually running, and verify with the licensing diagnoser that real licences are being issued rather than the grace period doing the work. That is the whole discipline, and it holds for a five-user deployment as well as a five-hundred-user one.
If you are buying licences for a Remote Desktop deployment and want to be sure of what you are getting, browse our Windows Server licences and read our guide to Windows Server CALs for the base layer, because that is the half people forget. If you are still choosing the edition for the host itself, our comparison of Windows Server Standard vs Datacenter covers how virtual machine count decides it.
Every licence we sell is genuine and sourced legitimately, delivered by email, and backed by support if activation gives you trouble. If you are not sure which CAL type or how many you need, ask us before you buy rather than after the grace period has run out.
