User vs Device CALs Explained
Remote Desktop Services licensing usually becomes relevant at a very specific point in a Windows Server project: the business wants more than basic server administration.
Employees need to open a remote desktop session. An accounting team wants to run a business application hosted on a central server. A branch office needs access to a shared Windows environment. Suddenly, a standard Windows Server deployment has become an RDS deployment—and the licensing conversation changes with it.
This is also where many administrators encounter the same question:
If we already have Windows Server CALs, why do we need RDS CALs?
The short answer is that the two licenses cover different access rights.
A Windows Server CAL addresses qualifying access to Windows Server services. An RDS CAL is an additional licensing requirement for users or devices accessing a Remote Desktop Services environment.
That distinction sounds simple on paper. In a real deployment, however, administrators still need to choose between RDS User CALs and RDS Device CALs, configure an RD License Server, select the correct licensing mode, and make sure the RDS CAL version fits the server environment.
This guide walks through those decisions using practical deployment examples rather than licensing jargon.
If Client Access Licensing itself is still unclear, start with our Windows Server CAL Licensing Explained guide. It covers the difference between standard User CALs and Device CALs before Remote Desktop Services enters the picture.
Table of Contents
- What Is Remote Desktop Services?
- What Is an RDS CAL?
- Windows Server CAL vs RDS CAL
- When Are RDS CALs Required?
- RDS User CALs Explained
- RDS Device CALs Explained
- RDS User CAL vs Device CAL
- Real-World RDS Licensing Scenarios
- How the RD License Server Fits In
- Understanding the 120-Day RDS Grace Period
- Common RDS Licensing Mistakes
- RDS CAL Version Compatibility
- Frequently Asked Questions
What Is Remote Desktop Services?
Remote Desktop Services, commonly shortened to RDS, is a Windows Server role that allows organizations to provide remote access to desktops and applications hosted within a server environment.
A typical RDS deployment may allow employees to:
- sign in to a remote Windows session,
- access centrally hosted business applications,
- work with files stored inside the company environment,
- use applications without installing them on every endpoint,
- or connect to business resources from another office or location.
Consider a small accounting company with an application installed on a central Windows Server.
Without a centralized remote environment, the IT team may need to maintain the application across multiple computers. With an appropriately designed RDS deployment, authorized employees can connect to a server-hosted session and work with the application within that environment.
RDS is not limited to accounting software. It is also used for line-of-business applications, administrative tools, remote work environments, and session-based desktops.
The technical architecture can vary significantly from one organization to another. Licensing, however, still needs to reflect how users or devices access the RDS environment.
What Is an RDS CAL?
An RDS Client Access License, or RDS CAL, provides licensing rights for a user or device to access Remote Desktop Services under the applicable Microsoft licensing terms.
There are two primary licensing modes:
- Per User
- Per Device
This choice is configured within the RDS deployment and should match the RDS CAL model selected for the environment.
An RDS CAL should not be confused with the Windows Server license itself.
A simplified way to think about the licensing layers is:
Windows Server license
↓
Licenses the server operating system according to the applicable server licensing model
↓
Windows Server CAL
↓
Addresses qualifying user or device access to Windows Server services
↓
RDS CAL
↓
Addresses qualifying user or device access through Remote Desktop Services
These licensing layers solve different problems.
For a wider view of how server licensing, physical cores, CALs, RDS, and virtualization fit together, our Complete Windows Server Licensing Guide covers the overall model.
Windows Server CAL vs RDS CAL
The easiest mistake to make is assuming that an RDS CAL replaces a standard Windows Server CAL.
It does not.
In a typical RDS deployment, the underlying Windows Server access licensing requirements still need to be considered. RDS CALs add the Remote Desktop Services access layer.
| License | What It Addresses |
|---|---|
| Windows Server License | Running the Windows Server software |
| Windows Server CAL | Qualifying user or device access to Windows Server services |
| RDS CAL | Qualifying user or device access to Remote Desktop Services |
Imagine a company with 20 employees.
Those employees authenticate against Active Directory and access shared files hosted on Windows Server. The organization evaluates Windows Server CAL requirements for that access.
Later, the company deploys an RD Session Host so the same employees can connect to a server-hosted business application.
The RDS deployment introduces another licensing consideration.
The existing Windows Server CALs do not simply become RDS CALs. Remote Desktop Services has its own CAL requirements.
This is why CAL planning should be completed before an RDS environment moves into regular production use.
When Are RDS CALs Required?
The answer depends on what the remote connection is being used for.
There is an important difference between remote server administration and providing Remote Desktop Services sessions to users.
Windows Server allows limited remote connections for administrative purposes. Those administrative connections should not be treated as a substitute for an RDS deployment used by employees to run applications or perform their daily work.
For example:
Administrative Access
Two administrators connect remotely to manage server roles, review configuration, or perform maintenance.
That is an administrative scenario.
User RDS Access
Twenty employees connect to the server every morning and use a hosted accounting or ERP application throughout the working day.
That is a very different use case and should be evaluated as a Remote Desktop Services deployment.
The number of users is not the only factor. The purpose of the connection matters.
If Remote Desktop is becoming a normal way for employees to access their working environment or server-hosted applications, RDS licensing should be part of the deployment plan.
RDS User CALs Explained
An RDS User CAL is assigned to a user.
This model is usually easier to evaluate in organizations where employees connect to the RDS environment from several devices.
A user might connect from:
- an office desktop,
- a company laptop,
- a home workstation,
- or another managed or unmanaged endpoint.
The important part is that the licensed user is the consistent element.
Example: Accounting Team
A company has 14 accountants.
Each accountant has an office computer and a company laptop. Several employees also work remotely during reporting periods.
All 14 employees need to access a centrally hosted accounting application through Remote Desktop Services.
The organization has 14 users but significantly more than 14 devices.
In this scenario, RDS User CALs may align more naturally with the way the team works.
The employees can move between their working devices while the licensing model remains centered on the individual users accessing RDS.
RDS Device CALs Explained
An RDS Device CAL is assigned to a device rather than an individual user.
This model is often considered when several employees share a smaller number of computers.
The same licensed device may be used by different authorized users to access the RDS environment.
Common examples include:
- warehouse terminals,
- manufacturing workstations,
- hospital stations,
- retail computers,
- call center desks,
- shared office PCs.
Example: Manufacturing Company
A manufacturing business operates three shifts.
Sixty employees share 15 workstations located across the production floor.
Each shift uses the same computers to access a server-hosted production application through Remote Desktop Services.
Licensing 60 individual users may not reflect the way the environment is actually used.
Because access takes place from 15 shared workstations, RDS Device CALs may be the more practical model to evaluate.
RDS User CAL vs Device CAL
The decision becomes easier when you compare users and devices rather than looking only at the total number of employees.
| Environment | RDS User CAL | RDS Device CAL |
|---|---|---|
| Employee uses several devices | Better fit | |
| Remote or hybrid workforce | Better fit | |
| Shared warehouse terminals | Better fit | |
| Shift-based workplace | Better fit | |
| Mobile employees | Better fit | |
| Shared training computers | Better fit | |
| Dedicated laptop per employee | Often practical | |
| Many users sharing few PCs | Often practical |
There is no universal answer that works for every organization.
A professional services company may naturally fit a Per User model. A manufacturing facility with shared terminals may have a stronger case for Per Device licensing.
Some organizations also have mixed working environments.
An office department may consist of mobile employees using laptops, while a warehouse on the same site operates shared terminals.
This is why the licensing discussion should begin with an access inventory rather than a product list.
Document:
- Who needs RDS access?
- How many devices are used?
- Are those devices shared?
- Do employees work remotely?
- Will users regularly switch between devices?
Those five questions often reveal which model deserves closer evaluation.
Real-World RDS Licensing Scenarios
The difference between Per User and Per Device licensing is clearer when applied to actual business environments.
Scenario 1: Remote Accounting Practice
An accounting practice has 25 employees.
The accounting application is hosted in a Remote Desktop Services environment. Employees work from the office but may also connect from company laptops when working remotely.
The company has:
- 25 users
- 25 office computers
- 20 company laptops
The device count is much higher than the user count.
Likely model to evaluate: RDS User CALs.
Licensing the individual employees may better reflect how the organization operates.
Scenario 2: Distribution Warehouse
A warehouse employs 75 workers across several shifts.
Workers use 18 shared terminals to access an inventory application hosted through RDS.
The company has:
- 75 users
- 18 RDS access devices
Likely model to evaluate: RDS Device CALs.
The stable number of shared devices makes Per Device licensing a logical option to review.
Scenario 3: Law Firm
A law firm has 40 attorneys and support staff.
Most employees use assigned laptops and occasionally connect from another approved device.
Because the workforce is mobile and employees are not tied to a single workstation, a Per User model may be easier to manage.
Likely model to evaluate: RDS User CALs.
Scenario 4: Training Center
A training organization has 12 computer rooms with a total of 120 workstations.
Hundreds of different students may use those computers throughout the year.
The devices remain relatively stable while users change constantly.
Likely model to evaluate: RDS Device CALs.
These examples are intentionally simplified. Real deployments should always be reviewed against current licensing terms and the organization’s actual access model.
How the RD License Server Fits In
Buying RDS CALs is only one part of the deployment.
Remote Desktop Services uses the Remote Desktop Licensing role service to manage and issue RDS CALs to eligible users or devices.
The RD License Server is responsible for licensing communication within the RDS environment.
At a high level, the process looks like this:
RDS CALs are acquired
↓
Remote Desktop Licensing role is installed
↓
The license server is activated
↓
RDS CALs are installed on the license server
↓
The RDS deployment is configured with a licensing mode
↓
RD Session Hosts use the configured license server
The selected licensing mode should correspond to the intended Per User or Per Device RDS CAL model.
Simply installing the Remote Desktop Session Host role does not complete the licensing configuration.
Administrators should also verify that the RD Session Host can communicate with the appropriate license server and that the licensing mode is configured correctly.
Understanding the 120-Day RDS Grace Period
A newly deployed RD Session Host has a licensing grace period.
Microsoft currently documents a 120-day grace period during which an RD Session Host can accept connections before an RDS license server is required for continued licensed RDS access.
This grace period is intended to provide time to configure the licensing environment.
It should not be treated as a permanent licensing model.
A common mistake is deploying RDS, confirming that users can connect, and assuming the environment is fully configured because Remote Desktop works.
The server may simply be operating within the grace period.
Administrators should use that time to:
- install the Remote Desktop Licensing role where appropriate,
- activate the RD License Server,
- install the relevant RDS CALs,
- configure the licensing mode,
- and confirm that the RD Session Host can locate the license server.
Waiting until the grace period has nearly expired can turn a licensing configuration task into an urgent access problem.
What Comes Next?
At this point, the basic RDS CAL model should be clearer:
- standard Windows Server CALs and RDS CALs are different licensing layers,
- RDS CALs use Per User or Per Device models,
- the licensing choice should reflect actual access patterns,
- and an RD License Server is part of a properly configured RDS licensing environment.
The next part of this guide covers the areas where deployments most often go wrong: version compatibility, incorrect licensing modes, license server configuration, and the assumption that two administrative Remote Desktop sessions can replace a real RDS deployment.
We will also look at practical RDS planning steps, common questions, and how RDS licensing relates to the wider Windows Server licensing model.
Common RDS Licensing Mistakes
RDS licensing problems are often discovered late.
The deployment works during testing. Users can open remote sessions. The application launches correctly. From an administrator’s point of view, everything appears ready for production.
Then a licensing warning appears, the grace period approaches its end, or the RD Session Host cannot find the configured license server.
Most of these problems can be traced back to a few planning mistakes.
Treating Two Administrative Sessions as an RDS Deployment
Windows Server supports limited Remote Desktop access for server administration.
Those connections are intended for administrators managing the server. They are not a replacement for Remote Desktop Services when employees use remote sessions as part of their normal work.
For example, an administrator connecting to install updates is very different from an accounting team opening a hosted financial application every morning.
The technology may look similar to the user—both involve a Remote Desktop connection—but the purpose of the session is different.
If employees are using server-hosted desktops or applications for regular business activity, the environment should be evaluated as an RDS deployment.
Assuming Windows Server CALs Include RDS Access
A standard Windows Server CAL and an RDS CAL cover different licensing requirements.
Having Windows Server User CALs does not automatically provide RDS User CAL rights.
Likewise, purchasing RDS CALs does not remove the need to evaluate the underlying Windows Server access licensing requirements.
If the distinction is still unclear, our Windows Server CAL Licensing Explained guide covers the standard CAL model separately.
Selecting a Licensing Mode Without Reviewing the Workforce
Per User may sound like the obvious choice for an office.
Per Device may appear to be intended only for factories or warehouses.
Real environments are rarely that simple.
A call center may have hundreds of employees working across a fixed number of shared desks. A small consulting firm may have only 15 employees but twice as many devices because everyone uses a laptop and an office workstation.
Count both users and devices before selecting the licensing mode.
More importantly, document how those users actually connect.
Installing CALs but Not Configuring the Deployment
An administrator can install RDS CALs on an activated license server and still have a licensing problem.
The RD Session Host must be able to use the appropriate license server, and the deployment must use the intended licensing mode.
If those settings are missing or incorrect, simply having CALs installed does not mean the RDS environment is fully configured.
Waiting Until the Grace Period Is Almost Over
The 120-day grace period gives administrators time to configure RDS licensing.
It is not a 120-day licensing strategy.
A better approach is to complete licensing configuration while the deployment is still being tested. That leaves time to identify communication, configuration, or licensing mode problems before users depend on the environment every day.
Matching RDS CALs to Your Windows Server Environment
The choice between User and Device CALs is only one part of RDS planning.
Version compatibility also matters.
An RDS CAL must be compatible with the version of Windows Server running the RD Session Host. As a general version rule, a newer RDS CAL version can support compatible earlier Windows Server session hosts, while an older RDS CAL version cannot be used to license access to a newer RD Session Host.
For example, a Windows Server 2025 RD Session Host requires compatible Windows Server 2025 RDS CALs. A 2019 RDS CAL should not be selected for a new Windows Server 2025 Session Host simply because the licensing model—User or Device—matches the deployment.
The RD License Server version must also be considered when installing newer RDS CAL packs.
This is one reason version planning should happen before purchasing or configuring the RDS licensing environment.
Windows Server 2019 RDS Environments
Organizations maintaining an established Windows Server 2019 Remote Desktop Services environment may be planning access around existing applications or infrastructure that has not yet moved to a newer server release.
For these environments, Windows Server 2019 Remote Desktop Services CALs can be reviewed when planning User or Device access based on the deployment requirements.
The age of the server environment alone is not a reason to change the CAL model. A 2019 deployment with mobile employees may still align with User CALs, while a shared workstation environment may fit Device CALs more naturally.
Windows Server 2022 RDS Environments
Windows Server 2022 remains part of many current business infrastructures.
Organizations running RD Session Hosts on this server generation can evaluate Windows Server 2022 Remote Desktop Services CALs alongside the selected Per User or Per Device licensing mode.
Before making changes to an existing RDS deployment, document the Session Host version, RD License Server version, installed CAL packs, and current licensing mode.
That simple inventory can prevent version assumptions from becoming configuration problems later.
Windows Server 2025 RDS Environments
New deployments built around Windows Server 2025 should include RDS licensing in the initial architecture plan rather than treating it as a post-installation task.
If the RD Session Host runs Windows Server 2025, organizations should evaluate compatible Windows Server 2025 Remote Desktop Services CALs and confirm that the licensing infrastructure can support the required CAL version.
This is particularly important when an organization upgrades Session Hosts but leaves the RD License Server on an older Windows Server version.
The operating system upgrade and the RDS licensing infrastructure should be reviewed together.
RDS CAL Version Compatibility: A Practical Example
Consider a business currently running Windows Server 2019.
The company has an established RDS deployment and plans to replace its Session Hosts with Windows Server 2025.
The administrator may initially focus on:
- application compatibility,
- user profiles,
- storage,
- Group Policy,
- and migration timing.
RDS licensing can easily become an afterthought.
However, the existing 2019 RDS CAL environment should not simply be assumed to cover the new Windows Server 2025 Session Hosts.
The administrator should review:
- The Windows Server version of the new RD Session Hosts.
- The version of the existing RD License Server.
- The RDS CAL version currently installed.
- Whether User or Device licensing is configured.
- The number of users or devices requiring RDS access after migration.
This review belongs in the migration plan before production cutover.
It is much easier to correct an RDS licensing design during testing than after employees have been moved to the new Session Hosts.
Per User Licensing in an RDS Environment
Per User licensing is often selected for organizations with a mobile workforce.
However, administrators should understand how the licensing model is managed.
With Per User licensing, organizations are responsible for maintaining enough RDS User CALs for the users accessing the RDS environment under the applicable licensing terms.
This makes internal documentation important.
A useful RDS user inventory might include:
| User | Department | RDS Access Required | Access Pattern |
|---|---|---|---|
| Employee A | Accounting | Yes | Office and laptop |
| Employee B | Management | Yes | Laptop and remote |
| Employee C | Warehouse | No | Local application |
| Employee D | Support | Yes | Office workstation |
The table does not need to be complicated.
Its purpose is to prevent RDS access from becoming an undocumented permission that is added whenever someone asks for Remote Desktop access.
When a new employee joins, the RDS requirement should be reviewed.
When an employee leaves, access records should be updated.
When a department adopts a server-hosted application, the licensing impact should be considered before access is enabled for the entire team.
Per Device Licensing in an RDS Environment
Per Device licensing is often easier to visualize because the license is associated with the connecting device.
This can work well in stable, shared-device environments.
Consider a warehouse with 25 terminals.
The workforce may change throughout the year. Seasonal employees may join. Different shifts may use the same terminal. Individual users may come and go.
The devices, however, remain largely the same.
In that environment, maintaining a device inventory may be more practical than tracking every employee who uses RDS.
Administrators should still monitor changes.
If the company adds a new warehouse area and deploys ten additional terminals, the RDS licensing plan should be reviewed before those devices become part of the production environment.
Per Device licensing is not “set and forget.” It simply changes the unit being managed from the user to the device.
A Note About Workgroup RDS Deployments
Not every Windows Server environment uses an Active Directory domain.
Small deployments and isolated environments may operate in a workgroup.
This matters for RDS licensing configuration.
For workgroup RD Session Host deployments, Microsoft documents Per Device licensing as the applicable mode; Per User RDS licensing is not supported in the same way for workgroup deployments.
This is an important technical detail because an administrator may choose User CALs based on the workforce and only later discover that the RDS architecture does not support the intended configuration.
Before selecting the CAL model, confirm whether the RD Session Host is domain-joined or operating in a workgroup.
The licensing decision and the server architecture should not be planned independently.
How to Plan an RDS Deployment Before Buying CALs
A short planning session can prevent most licensing confusion.
Start with the RD Session Hosts.
Write down the Windows Server version used by each Session Host.
Next, document the RD License Server. Confirm its Windows Server version and whether it is already activated.
Then review the users and devices.
For users, ask:
- Who needs an RDS session?
- Do they use multiple devices?
- Do they work remotely?
- Are they permanent employees or part of a changing workforce?
For devices, ask:
- How many endpoints connect to RDS?
- Are the devices shared?
- Do multiple shifts use the same workstations?
- Will new terminals be added soon?
Finally, document the deployment type.
Is the environment domain-joined or workgroup-based?
Once these details are visible on one page, the licensing model is usually much easier to evaluate.
If the wider Windows Server licensing structure is still being planned, the Complete Windows Server Licensing Guide explains how CALs, server editions, core licensing, and virtualization rights fit together.
RDS Licensing and Standard vs Datacenter
RDS licensing is sometimes incorrectly tied to the Standard versus Datacenter decision.
The two decisions address different parts of the deployment.
Standard and Datacenter primarily affect server edition capabilities and virtualization rights.
RDS CALs address Remote Desktop Services access.
Choosing Datacenter does not automatically include unlimited RDS users.
Likewise, choosing Standard does not prevent an organization from deploying Remote Desktop Services when the environment is properly designed and licensed.
If you are still selecting the server edition, our Windows Server 2025 Standard vs Datacenter comparison explains the infrastructure and virtualization differences between the two editions.
Make the edition decision based on the server environment.
Make the RDS CAL decision based on how users or devices access Remote Desktop Services.
Keeping those two questions separate makes the planning process much clearer.
Best Practices for RDS Licensing Management
RDS licensing becomes difficult when nobody owns the documentation.
The technical configuration may belong to the server administrator, while license purchasing belongs to finance or procurement. HR knows when employees join or leave, and department managers decide who needs access to server-hosted applications.
Without a process connecting those teams, licensing records quickly become outdated.
A practical RDS licensing process should include:
- a documented Per User or Per Device licensing mode,
- an inventory of RDS users or devices,
- the Windows Server version of each RD Session Host,
- the RD License Server version,
- records of installed RDS CAL packs,
- periodic review of the RD Licensing Diagnoser,
- and a licensing review when the environment is upgraded.
For larger environments, assign responsibility for RDS licensing records to a specific IT role or team.
Someone should know the answer when asked:
How many users or devices currently require RDS access, and which CAL version supports the Session Hosts?
If that answer requires searching through old emails and purchase records, the documentation process needs improvement.
Frequently Asked Questions About RDS CAL Licensing
Do I need an RDS CAL for every remote user?
Users or devices accessing an RD Session Host generally require an appropriate RDS CAL under the applicable licensing terms. The number required depends on whether the deployment uses Per User or Per Device licensing.
Is a Windows Server CAL enough for Remote Desktop Services?
No. Windows Server CALs and RDS CALs address different access rights. An RDS deployment generally requires the underlying Windows Server access licensing to be considered along with the additional RDS CAL requirement.
Can I use Windows Server 2019 RDS CALs on Windows Server 2025?
An older RDS CAL version cannot be used to license access to a newer RD Session Host version. A Windows Server 2025 Session Host requires compatible Windows Server 2025 RDS CALs.
Can Windows Server 2025 RDS CALs be used with an older Session Host?
Newer RDS CAL versions can generally support compatible earlier Windows Server Session Host versions. The RD License Server must also support the installed RDS CAL version.
What is the 120-day RDS grace period?
A newly deployed RD Session Host has a 120-day licensing grace period during which a license server is not required for client connections. The grace period provides time to configure RDS licensing and should not be treated as a permanent deployment model.
What happens after the RDS grace period ends?
After the grace period, clients need a valid RDS CAL issued by an available RD License Server before they can log on to the RD Session Host.
Should I choose RDS User CALs or Device CALs?
User CALs are often more practical when one person connects from several devices. Device CALs may fit environments where many people share a smaller number of workstations.
Can I use RDS User CALs in a workgroup environment?
Microsoft documents Per Device licensing for workgroup RDS deployments. Per User licensing is not permitted for workgroup servers in the same way it is for domain-joined RDS deployments.
Does Windows Server Datacenter include RDS CALs?
The Datacenter edition and RDS CAL licensing address different parts of Windows Server licensing. Choosing Datacenter does not remove the need to evaluate RDS CAL requirements.
Do the two administrative Remote Desktop connections require RDS CALs?
Windows Server provides limited Remote Desktop connections for administrative purposes. Those sessions are intended for server administration and should not be used as a replacement for an RDS deployment providing normal employee access to desktops or applications.
Final Thoughts
RDS licensing is much easier to manage when it is planned around the actual deployment instead of added after Remote Desktop is already in use.
Start with the Session Hosts.
Confirm their Windows Server versions.
Review the RD License Server.
Then count users and devices and look at how people actually work.
A mobile employee who moves between a laptop, office workstation, and home device presents a different licensing scenario from three shifts of warehouse workers sharing the same terminals.
That difference is the reason Microsoft provides both Per User and Per Device RDS licensing models.
Version compatibility matters just as much. A server upgrade can change the RDS CAL requirements even when the number of users remains exactly the same.
For organizations maintaining earlier server environments, Windows Server 2019 RDS CALs and Windows Server 2022 RDS CALs can be evaluated against the relevant deployment version and access model.
Businesses planning new Windows Server 2025 Remote Desktop Services environments can review Windows Server 2025 RDS CAL options while documenting the Session Host version, licensing mode, and number of users or devices requiring access.
For the broader licensing structure, return to our Windows Server Licensing Guide.
The next guide in this series covers Windows Server Core Licensing—including physical cores, the 16-core minimum, core packs, and practical licensing examples for 16-, 24-, and 32-core servers.