[image: A server rack in a small office room with three rack-mounted servers and a network switch, status lights lit, viewed from the front]
A Windows Server CAL is a Client Access Licence, and it is the piece of Microsoft server licensing that catches almost everyone out at least once. Buying the server operating system does not give anyone permission to use it. The server licence covers the machine. The CAL covers the person or the device connecting to that machine. You need both, and if you only bought one you are running a server that is not properly licensed.
That single sentence causes more confusion, more failed audits and more surprise invoices than any other part of Microsoft’s server model. It is not intuitive, it is not how most software is sold, and Microsoft does not stop the server from working if you get it wrong. Nothing breaks. No warning appears. The gap only shows up when someone asks to see your licensing position, and by then it has usually been growing for years.
This guide covers what a Windows Server CAL actually is, the difference between User CALs and Device CALs, where Remote Desktop Services CALs fit in and why they are a separate purchase, the version matching rule that quietly invalidates licences people thought they owned, how many you need, how to install them on Server 2019 and Server 2022, and how to check what is already on the box.
Key takeaways
- A Windows Server CAL is a permission to connect, not software you install. Buying the server licence alone does not cover any users.
- You choose between User CALs, which follow a person across all their devices, and Device CALs, which follow a machine across all its users. You can mix both on one server.
- Remote Desktop Services CALs are an additional purchase on top of standard CALs, not a replacement for them.
- CALs must match or exceed the server version. A Server 2019 CAL does not license a Server 2022 machine.
- Standard CALs are never installed anywhere. Only RDS CALs are actually loaded onto a licence server.
- Nothing stops working if you are under-licensed, which is exactly why so many networks are.
What a Windows Server CAL actually is
A CAL is a legal permission, not a technical one. There is no CAL file for standard access, no key to type in, no service that counts your users and refuses the two hundred and first. You buy the right to have a person or a device connect to your server, you keep the proof of purchase, and that is the whole mechanism.
This trips people up because every other part of a Windows deployment does have a technical enforcement step. You type a key into Windows and it activates. You install Office and it phones home. Standard CALs do none of that. They are closer to a seat licence for a piece of business software, where the vendor trusts you to count honestly and reserves the right to check.
Microsoft splits server licensing this way for a reason that makes sense once you see it. The cost of the server operating system reflects the machine it runs on, measured in physical cores. The cost of access reflects how many people actually benefit from that machine. A small business with one server and eight staff pays very differently from an enterprise with one server and eight hundred staff, even though the server itself is identical. Charging for the operating system alone would mean either overcharging the small business or undercharging the enterprise.
What counts as accessing the server
This is the question that decides how many CALs you need, and the answer is broader than most people expect. Authenticating against Active Directory counts. Opening a file from a shared folder counts. Printing to a printer shared from the server counts. Getting an address from the server’s DHCP service counts. Pulling a Group Policy setting counts.
What does not count is anonymous, unauthenticated access to a public-facing service. If the server hosts a website that the general public reads without logging in, those visitors do not each need a CAL. The moment authentication enters the picture, that exemption disappears.
There is also an administrative allowance. A small number of accounts used purely to administer the server, and nothing else, are covered without CALs. That number is deliberately small and it is not a loophole for staff who also use the server for ordinary work.
The parts of server licensing that CALs are not
Three separate things get confused constantly, so it is worth separating them clearly.
The server licence itself is priced by physical processor cores and covers the operating system running on the hardware. Standard edition and Datacenter edition differ mainly in how many virtual instances you may run, not in what CALs they require. Both need the same CALs.
CALs cover the connecting side. They are bought per user or per device, they belong to your organisation rather than to any particular server, and they are counted across your whole environment rather than per machine.
Then there are additive CALs for specific server roles, of which Remote Desktop Services is the one people meet most often. These sit on top of the standard CAL. They never replace it.
[image: A whiteboard diagram showing a central server box connected by lines to several smaller user and computer icons arranged around it]
User CAL or Device CAL, and how to choose
Both types cost the same and grant the same access. The only difference is what they are attached to, and getting that choice right is the single easiest way to reduce what you spend.
A User CAL is assigned to a named person. That person can connect from their desktop, their laptop, their phone and a machine in a hotel business centre, all on one licence. The licence follows the human being.
A Device CAL is assigned to a specific machine. Anyone at all can use that machine to reach the server, and one licence covers all of them. The licence follows the hardware.
The decision comes down to counting. If you have more devices than people, buy User CALs. If you have more people than devices, buy Device CALs. That sounds obvious written down, and it still gets missed regularly because organisations buy whichever type they bought last time without recounting.
Where each type wins in practice
User CALs suit a modern office. Forty staff with a laptop each, a work phone each and a desktop at their desk is a hundred and twenty devices and forty people. Forty User CALs cover the lot. A hundred and twenty Device CALs would be three times the cost for identical access.
Device CALs suit shift work and shared terminals. A warehouse running three shifts on twelve fixed scanning stations has thirty-six people touching twelve machines. Twelve Device CALs cover everyone. Thirty-six User CALs would be three times the cost. Call centres, hospital ward terminals, factory floor stations, retail tills and library public machines all follow the same shape.
You may mix both types against one server, and in most real organisations mixing is the cheapest answer. Give User CALs to the office staff who carry three devices and Device CALs to the shared terminals. Nothing about the server needs configuring differently. You are simply choosing, for each part of your workforce, whichever count is smaller.
Reassigning a CAL
CALs are not welded to a person or a machine forever. When someone leaves, their User CAL can go to their replacement. When a machine is retired, its Device CAL can move to the replacement machine. What you may not do is rotate a small pool of CALs around a large group to make the numbers work, reassigning a licence to a different person every morning. Permanent reassignment is fine. Time-sharing is not.
Remote Desktop Services CALs, and why they are separate
The highest-volume search around Windows Server CALs is not about ordinary file access at all. It is about Remote Desktop Services, and that is because RDS is where the licensing gets an extra layer and where things actually stop working if you get it wrong.
If a user connects to the server and runs a desktop session or a published application on it, that is Remote Desktop Services. It needs an RDS CAL for that user or device, and it needs a standard Windows Server CAL as well. Two licences per user, not one. This is the point people most often miss when budgeting a terminal server.
Unlike standard CALs, RDS CALs are technically enforced. You install a Remote Desktop Licensing role, you activate a licence server, you load the CAL pack into it, and the licence server hands out licences to connecting sessions. If it runs out, or if it was never set up, connections start failing.
The grace period that catches everyone
Stand up a new Remote Desktop Session Host and it will work perfectly for a fixed grace period with no licence server at all. Users connect, everything is fine, the project is signed off and everyone moves on.
Then the grace period ends and remote connections stop being accepted. Nothing was misconfigured. The countdown simply ran out. This is the most common Remote Desktop failure in small deployments, and the fix is not a repair or a reinstall — it is the licensing that was never finished. If you are building an RDS host, buy and install the CALs during the build, not when the errors start.
Per-user and per-device RDS CALs behave differently in one important respect. Per-device RDS CALs are issued and tracked properly by the licence server, so it can genuinely enforce the count. Per-user RDS CALs are not tracked in the same way, which means the licence server will keep letting people in past the number you own. That is not permission to over-subscribe. It means the responsibility for counting sits with you, and an audit will look at your purchase records rather than at the server.
Other additive CALs
Remote Desktop Services is the additive CAL most people meet, but it is not the only one. Rights Management Services works the same way. Other Microsoft server products, including SQL Server in its server-plus-CAL model and various Exchange and SharePoint arrangements, run their own separate CAL schemes with their own rules. None of them substitute for a Windows Server CAL. If a user touches the underlying Windows Server at all, that user needs the base CAL regardless of what else they are licensed for.
The version rule that invalidates licences quietly
Your CALs must be the same version as your server, or newer. This is the rule that silently breaks licensing positions during upgrades, and it is worth reading twice.
A Windows Server 2019 CAL will license a user connecting to a Server 2019 machine. It will license that user connecting to a Server 2016 or Server 2012 machine too, because newer CALs cover older servers. It will not license that user connecting to a Server 2022 machine. Upgrade the server without upgrading the CALs and every user on the network is instantly under-licensed, while absolutely nothing changes in how the system behaves.
This means CAL cost is not a one-time expense. It is a recurring one, on the same rhythm as your server refreshes. Anyone planning a move to a newer server version should be budgeting for the CALs in the same breath as the server licence, and the number of them is usually the larger figure once the organisation is above a handful of staff.
The rule also runs the other way in a helpful direction. If you have a mixed estate with several server versions, buying CALs matching your newest server covers everything older as well. There is no need to hold a separate pool per version. Buy to the newest and you are covered across the board.
If you are still on an out-of-support version
Servers running versions that have passed their support date raise a licensing question and a security question at the same time, and the security one is more urgent. An unpatched domain controller or file server is a far bigger problem than a paperwork gap. Our write-up on where Windows Server 2019 stands on support covers the dates, and the comparison of Server 2019, 2022 and 2025 is the place to start if you are working out which version to move to. Plan the CAL purchase alongside that decision rather than after it.
How many CALs do you need
Count honestly, then count again in six months. The number moves more than people expect.
Start with every human being who authenticates against anything on the network. That includes part-time staff, contractors, seasonal workers, the accountant who comes in one day a month, and anyone working remotely. It includes people who only ever open a shared spreadsheet, because opening a shared spreadsheet from a server share is server access.
Then count devices that access the server without a person sitting at them. A networked photocopier that authenticates to scan into a shared folder needs covering. A shop-floor terminal that runs unattended and pulls data needs covering. Cameras, sensors and point-of-sale units that authenticate all count.
Then take whichever total is smaller, users or devices, and consider whether splitting the estate gives you a smaller number still. Office staff on User CALs and shared terminals on Device CALs is almost always cheaper than either type alone.
The external users problem
If people outside your organisation need access — customers checking order status, suppliers uploading documents, partners pulling reports — buying a CAL for each of them gets expensive fast and is impossible to count reliably. Microsoft’s answer is the External Connector licence, which covers unlimited external users against one server. It costs considerably more than a single CAL and considerably less than a hundred of them, so the maths depends entirely on your numbers.
The catch is the definition of external. Your own employees are not external users, and neither are contractors working on your behalf, no matter where they sit or who signs their invoice. An External Connector does not cover staff who happen to work from home. That misreading is a genuinely common and genuinely expensive mistake.
Installing CALs on Windows Server
Here is where the two CAL types diverge completely, and where a lot of wasted evenings come from.
Standard Windows Server CALs are not installed. There is no console for them, no wizard, no key. You buy them, you file the proof of purchase somewhere you will find it in three years, and you are done. If you are hunting through Server Manager for the place to enter your CAL, you are looking for something that does not exist. Every guide that appears to describe installing a Windows Server CAL is in fact describing an RDS CAL.
RDS CALs are a different story and do require real work.
Setting up the licence server
The sequence on Server 2019 and Server 2022 is the same, and the order matters more than any individual step.
First, add the Remote Desktop Licensing role through Server Manager’s Add Roles and Features wizard. On a small deployment this usually goes on the session host itself. On anything larger it belongs on a separate machine so that rebuilding a session host does not take the licensing with it.
Second, open the Remote Desktop Licensing Manager, right-click your server and activate it. Activation registers the licence server with Microsoft’s clearing house. The automatic method over the internet is the least painful; a phone and a web method exist for machines with no outbound access.
Third, install the licence packs. Right-click the activated server, choose to install licences, pick the agreement type matching how you bought them, and enter the details. The wizard asks for different information depending on whether you have a retail pack, an Open Licence agreement, a Select agreement or an Enterprise Agreement, so have the paperwork in front of you before you start.
Fourth, and this is the step most often skipped, tell the session host to use the licence server and set the licensing mode. This lives in Group Policy under the Remote Desktop Session Host licensing settings, where you specify the licence server name and choose per-user or per-device. Without this, the host has no idea the licence server exists and will run on the grace period until it expires, which is exactly the failure that looks like a licensing bug months later.
Checking what is already installed
To see your RDS CAL position, open the Remote Desktop Licensing Manager on the licence server. It lists each installed licence pack, the type, the total issued and the number still available. Per-device licences show as individually issued with expiry dates. Per-user licences show as available but not truly tracked, for the reason described earlier.
The Remote Desktop Licensing Diagnoser, available from Server Manager on a session host, is the faster way to answer the question people usually actually have, which is why connections are failing. It reports whether the host can reach a licence server, whether the licensing mode is set, and whether the grace period is running. On Server 2012 through Server 2022 this tool works the same way and is the first place to look when remote sessions start refusing connections.
For standard Windows Server CALs there is nothing to check on the server, because there is nothing installed. Your record is your purchase documentation. If you cannot produce it, you cannot demonstrate compliance, and that is the entire audit exposure in one sentence. Keep the paperwork.
[image: A Windows Server administration console window showing a licensing manager with a list of installed licence packs]
Comparing the licence types
| Licence type | Assigned to | Installed on the server | Technically enforced | Needed for basic file and print access | Needed for remote desktop sessions |
|---|---|---|---|---|---|
| Windows Server User CAL | A named person | No | No | Yes | Yes |
| Windows Server Device CAL | A specific machine | No | No | Yes | Yes |
| RDS User CAL | A named person | Yes | Partly | No | Yes |
| RDS Device CAL | A specific machine | Yes | Yes | No | Yes |
| External Connector | One server | No | No | Yes, for external users only | No |
Read the last two columns together and the structure becomes clear. A remote desktop user needs a row from the top two and a row from the middle two. That is the doubling people forget when they budget.
What this looks like for real organisations
Abstract rules are hard to price. Three shapes cover most situations.
The small office with one server
Twelve staff, one server handling files, printing and Active Directory, everyone at a desk with a laptop and a phone. Twelve User CALs, matching the server version. No RDS, no External Connector. That is the entire licensing position beyond the server licence itself, and it is the simplest case there is.
The shift-based operation
Fifty staff across three shifts sharing eighteen terminals, plus six office staff with their own machines. Eighteen Device CALs for the shared terminals and six User CALs for the office staff comes to twenty-four, against fifty-six if everything went on User CALs. Same access, less than half the count. This is the case for mixing types, and it is why recounting before each purchase is worth the hour it takes.
The remote desktop deployment
Thirty staff connecting to a session host to run a line-of-business application. Thirty Windows Server CALs plus thirty RDS CALs, plus the licence server set up properly and the Group Policy licensing mode configured during the build. The commonest failure here is budgeting for thirty licences instead of sixty, discovering the gap after the purchase order is approved, and then hitting the grace period expiry while the second purchase works its way through.
Virtual machines, and where CALs sit
Virtualisation changes how you license the server and changes nothing about how you license access, which is a distinction worth being precise about because plenty of people get it backwards.
On the server side, the edition decides how many virtual instances you may run on hardware you have licensed. Standard edition allows a small number of virtual instances per fully licensed host. Datacenter allows an effectively unlimited number on the same host. If you are running more than a couple of virtual servers on one box, the arithmetic usually favours Datacenter even though its headline cost is higher, and working that out properly is one of the few places where a spreadsheet genuinely pays for itself.
On the access side, none of that matters. CALs are counted per user or per device across your whole environment, not per server and not per virtual machine. A user who connects to six virtual servers on one host needs one CAL, not six. Spinning up a new virtual machine does not create a new CAL requirement. The only thing that increases your CAL count is a new person or a new device connecting, and the only thing that invalidates existing CALs is running a newer server version than they cover.
The same principle holds for failover and disaster recovery. A passive standby server that only runs when the primary fails does not need its own set of CALs, because the same users are connecting to whichever machine is live. Where this gets more complicated is if the standby is doing real work rather than sitting idle, at which point it is not a standby and normal rules apply.
Cloud-hosted servers
A Windows Server running on cloud infrastructure that you rent by the hour usually has the operating system licence folded into the hourly rate, so you are not buying a server licence separately. Whether CALs are included depends entirely on how you bought it, and the answer differs between providers and between billing models. If you moved a server to the cloud and stopped thinking about CALs because the bill looked like it covered everything, that assumption is worth checking rather than trusting. Some arrangements include access rights; others cover only the operating system and leave the CAL obligation exactly where it was.
Where CALs come from, and what to look for when buying
CALs reach organisations through several routes, and they are not equivalent.
Volume licensing programmes are how larger organisations buy. Agreements of that type give you a licence agreement number, a portal listing your entitlements, and CAL packs that can be installed against that agreement. The record-keeping problem largely solves itself because the portal holds the record, which is a real advantage once an organisation is big enough that people come and go.
Retail and packaged CAL licences suit smaller organisations that do not have and do not want a volume agreement. You buy a specific number, you receive keys and documentation, and you keep that documentation. The licensing rights are the same. The difference is that the record lives with you rather than in a Microsoft portal, which puts more weight on filing it somewhere sensible.
OEM CALs arrive bundled with server hardware from the manufacturer. They are tied to that hardware and do not move to a replacement machine, in the same way that an OEM Windows licence on a laptop does not travel to a new laptop. If you inherited a server with CALs included, check whether they were OEM before assuming they will follow you to the next box.
What a legitimate purchase looks like
Because standard CALs have no technical enforcement, the only thing distinguishing a properly licensed organisation from an improperly licensed one is the paperwork. That makes the quality of your purchase record the entire point, not an afterthought.
A legitimate CAL purchase gives you an invoice naming your organisation, a clear statement of the quantity and type, the server version the CALs cover, and either keys or an agreement reference depending on the route. If what you receive is a bare key in an email with no invoice and no statement of what it entitles you to, you have bought something, but you have not bought something you could show an auditor.
This matters more for CALs than for almost any other Microsoft product, precisely because there is nothing to install and nothing to point at. With a desktop Windows licence you can at least show an activated machine. With a standard CAL there is no machine to show. The document is the licence. We wrote about the wider question of what separates a legitimate key from a risky one, and everything in it applies with extra force here.
Misconceptions worth clearing up
A few beliefs come up often enough to be worth naming directly.
Buying Datacenter edition does not include CALs. The edition affects virtualisation rights only. Datacenter and Standard require the same CALs in the same quantity.
Having more CALs than users is not a problem and is not wasted if your headcount is growing, but it is also not a credit against a version upgrade. Surplus Server 2019 CALs do not become Server 2022 CALs.
A user connecting through a web front end that sits in front of the server is still a user connecting to the server. Putting a layer in between does not remove the CAL requirement. This is sometimes called multiplexing, and Microsoft’s rules address it explicitly for the simple reason that people tried it.
Finally, CALs are not tied to a domain. They are an organisational entitlement. Restructuring your Active Directory, merging domains or renaming things does not affect what you own.
The honest trade-offs
There are parts of this model that are genuinely awkward, and pretending otherwise helps nobody.
The recurring cost is real. Because CALs are tied to server versions, staying current means buying them again at each major upgrade. For an organisation of any size the CAL bill can exceed the server licence bill comfortably. That is a legitimate argument for looking hard at cloud-hosted alternatives, where the access licensing is bundled into a per-user subscription and the version question disappears. It is not automatically cheaper — subscriptions never stop, whereas a CAL you own keeps working — but it is a different shape of cost and for some organisations it is the better one.
The lack of enforcement is a double-edged thing. It means a genuine mistake never takes your business offline, which is a real mercy. It also means you can be significantly under-licensed for years without a single signal, and the discovery usually happens at the worst possible moment. If nobody at your organisation owns the CAL count as an actual responsibility, it will drift.
Counting external and non-human access is harder than it sounds. Service accounts, integrations, scanners, monitoring agents and automated jobs all sit in a grey area that most guides skip. If your environment has a lot of that, the honest answer is that a conversation with a licensing specialist is worth more than another article, including this one.
And the documentation problem is understated everywhere. CALs are proved by paperwork, and paperwork gets lost across staff changes, office moves and email migrations. Whatever you buy, put the evidence somewhere institutional rather than in one person’s inbox.
What we would actually recommend
If you are licensing a server for the first time, start by counting people and devices before you look at anything else, because that number decides everything downstream. Then buy CALs matching the newest server version you run or plan to run in the next couple of years, so an upgrade does not immediately invalidate them. Our Windows Server CAL licences are sold in the standard User and Device forms and delivered as genuine keys with the documentation you will need if anyone ever asks to see it.
If you are still deciding which server version to build on, settle that first and buy the CALs to match rather than the other way round. The Windows Server editions we stock cover the current supported versions, and pairing the server licence and its CALs in a single purchase is the simplest way to avoid the version mismatch that causes most of the trouble described above. If you are unsure what you are currently running before you plan any of this, the checks in our guide on identifying which Windows version you have work on server editions too.
Whichever route you take, buy from somewhere that gives you a real invoice and a real licence record. The document matters as much as the key, because with standard CALs the document is the only thing you have. That is worth keeping in mind wherever you buy, and it is one of the reasons we set Kymakers up the way we did.
Frequently asked questions
What is a Windows Server CAL
It is a Client Access Licence: the permission for one user or one device to connect to a Windows Server. The server licence covers the machine itself and grants nobody the right to use it. The CAL covers the connection. Both are required.
What is a user CAL for Windows Server
A User CAL is assigned to a named person and covers that person connecting from any number of devices. One person with a desktop, a laptop and a phone needs one User CAL, not three.
What is a CAL license in Windows Server 2022
Exactly the same thing as in every other version, with the version number attached. A Server 2022 CAL licenses access to a Server 2022 machine and to any older version. It is a permission, not software, and for standard access there is nothing to install.
Do I need CALs for Windows Server 2022
Yes. Every user or device that authenticates to the server needs one, whatever the version. The only exceptions are anonymous unauthenticated access to public services and a small allowance for accounts used purely for administration.
How many Windows Server CALs do I need
Count every person who authenticates and every unattended device that authenticates, then buy whichever number is smaller as the matching CAL type. Splitting the estate, with User CALs for staff carrying several devices and Device CALs for shared terminals, usually gives a smaller total than either type alone.
How to install a CAL license in Windows Server 2022
Standard Windows Server CALs are never installed. There is no console for them. If you mean RDS CALs, add the Remote Desktop Licensing role, activate the licence server in Remote Desktop Licensing Manager, install the licence pack using your agreement details, then point the session host at the licence server and set the licensing mode in Group Policy.
How to install RDS CALs on Windows Server 2019
The steps are identical to Server 2022. Add the Remote Desktop Licensing role, activate the server in Licensing Manager, run the install licences wizard with your agreement number, then configure the session host to use that licence server and choose per-user or per-device mode. Skipping that last step is the usual cause of failures after the grace period.
How to install user CALs on Windows Server 2019
If these are standard Windows Server User CALs, there is nothing to install anywhere. If they are RDS per-user CALs, install them into the licence server through Remote Desktop Licensing Manager and set the session host licensing mode to per user. Note that per-user RDS CALs are not individually tracked, so the console will not stop you exceeding your count.
How to check CAL licenses in Windows Server 2019
Open Remote Desktop Licensing Manager on the licence server to see installed RDS packs, how many have been issued and how many remain. Use the Licensing Diagnoser on the session host to check whether the host can reach the licence server. Standard Windows Server CALs cannot be checked on the server at all, because they were never installed; your purchase records are the only record.
How to check CAL licenses in Windows Server 2016 and 2012
The same tools, in the same places. Remote Desktop Licensing Manager and the Licensing Diagnoser have worked essentially the same way from Server 2012 through Server 2022, so a procedure written for one version applies to the others.
Are Windows Server CALs a one-time purchase
They do not expire on their own, so a CAL you own keeps working indefinitely against the server version it covers. But they do not carry forward to newer server versions, so in practice you buy again each time you upgrade the server. Treat them as tied to the server refresh cycle rather than as a permanent purchase.
Do I need a CAL for every server
No. CALs are counted per user or per device across your organisation, not per server. One User CAL covers that person connecting to every Windows Server you run at that version or older. Adding a second server does not require a second set.
Do RDS CALs replace Windows Server CALs
No, they are additive. A user running a remote desktop session needs a Windows Server CAL and an RDS CAL. This is the most frequently missed point in the entire model and the one most likely to leave a budget short.
Can I mix User CALs and Device CALs
Yes, freely, on the same server and the same network. No configuration is needed to allow it. For most organisations with a mix of desk staff and shared terminals, mixing is the cheapest correct answer.
Your next step
Open a spreadsheet and write two columns: every person who authenticates to your network, and every device that authenticates without a person at it. Whichever column is shorter tells you which CAL type to buy, and splitting the list between the two types usually gets the total lower still. Do that count before you look at anything else, because every other decision here follows from it.
Once you have the number and you know which server version you are matching, the CALs themselves are a straightforward purchase. Our full range of Microsoft licences covers the server editions and the CALs together, so you can buy the pair in one go and keep the paperwork in one place.
