Windows Server 2025 Remote Desktop Services can turn a Windows Server into a centralized platform for session-based desktops, RemoteApp applications and other remote working scenarios. Licensing it correctly requires more than simply licensing the server itself.
For most internal RDS deployments, there are three separate questions: is the Windows Server properly licensed, does each qualifying user or device have the required base Windows Server CAL, and does that same RDS user or device also have the additional Remote Desktop Services CAL required for the RDS functionality being used?
That last license is the Windows Server 2025 RDS CAL.
The next decision is whether to license RDS access Per User or Per Device. A business with 30 employees who connect from laptops, desktops and home devices will usually evaluate User RDS CALs first. A call center with 100 employees rotating through 40 shared workstations has a very different access pattern and may be better suited to Device RDS CALs.
The licensing model is simple once the workforce is mapped correctly. The mistakes usually happen when organizations count the wrong thing, confuse administrative Remote Desktop with production RDS use, or assume a base Windows Server CAL already includes Remote Desktop Services.
An RDS CAL is an additive access license for Windows Server Remote Desktop Services functionality.
It does not license the physical server cores.
It does not replace the Windows Server operating system license.
And for normal internal-user scenarios, it does not replace the base Windows Server CAL.
Microsoft’s current licensing guidance treats the Windows Server CAL as the base access license and the Windows Server Remote Desktop Services CAL as an additional license required when users or devices access RDS functionality or a graphical user interface hosted on Windows Server through that functionality.
A simplified internal-user licensing stack therefore looks like this:
Windows Server licensing + Windows Server CAL + RDS CAL
Each layer answers a different licensing question.
The server license covers the Windows Server software.
The base CAL covers qualifying access to Windows Server.
The RDS CAL adds the right to use the Remote Desktop Services functionality.
If users are connecting to a Windows Server 2025 Remote Desktop Session Host to run a remote desktop or published applications, RDS CALs normally need to be part of the licensing design.
Microsoft’s RDS documentation states that each user or device connecting to an RDS Session Host running Windows Server needs an appropriate RDS CAL. The RD Licensing infrastructure is then used to install, issue and track those licenses.
A common example is a company deploying an RD Session Host so 50 employees can sign in remotely and run an accounting application.
The company cannot stop its licensing calculation at:
Windows Server 2025 is licensed.
It must also evaluate the users or devices accessing Windows Server and then the additional RDS access rights required for the remote sessions.
The same principle applies if the organization is using RDS to provide full session-based Windows desktops rather than only one RemoteApp application.
This is the distinction that causes the most confusion.
A Windows Server CAL licenses qualifying user or device access to Windows Server’s base functionality.
An RDS CAL licenses additional Remote Desktop Services functionality.
For ordinary internal-user RDS deployments, the RDS CAL sits on top of the base CAL rather than replacing it. Microsoft explicitly classifies RDS as additive Windows Server functionality.
For example, suppose an employee authenticates to the company’s Windows domain, accesses file services and also signs in to an RD Session Host to run an application.
The licensing plan generally needs to account for that employee through both layers:
Base Windows Server access
and
RDS access
Purchasing an RDS CAL does not by itself license the physical or virtual Windows Server instance. Likewise, correctly licensing the Windows Server host does not automatically provide RDS access rights to every employee.
The two models license different things.
| RDS licensing model | Assigned to | Usually best for | Key idea |
|---|---|---|---|
| Per User RDS CAL | Individual user | Employees using several devices | One licensed user can connect from multiple devices |
| Per Device RDS CAL | Individual device | Shared workstations and shift environments | Multiple people can use the licensed device |
| Workgroup RDS deployment | Device | Non-domain workgroup environments | Microsoft requires Per Device licensing for workgroup RDS deployments |
Microsoft’s current RDS guidance describes Per Device CALs as assigned to devices and Per User CALs as assigned to users. It also states that workgroup-based RDS deployments must use Per Device CALs because Per User licensing is not permitted in that configuration.
The correct choice is therefore driven by the relationship between people and endpoints, not simply by which CAL appears cheaper.
A Per User RDS CAL follows the licensed user.
That user can access the RDS Session Host from multiple devices rather than requiring a separate RDS CAL for every endpoint.
Microsoft’s RDS documentation explains that a user licensed under the Per User model can connect to an RDS Session Host from any number of devices.
Consider an accountant who uses:
a desktop at headquarters,
a company laptop while traveling,
and an approved home computer.
Licensing that employee Per User can be much simpler than maintaining separate Device RDS CAL coverage for every endpoint.
This is why User RDS CALs are often a natural fit for office professionals, executives, mobile employees, consultants and hybrid workers.
Imagine a professional-services company with 35 employees.
Every employee has a laptop.
Many also use a desktop.
Several occasionally work from another approved device.
The company therefore has roughly 70 possible endpoints but only 35 people who need RDS access.
The comparison is conceptually:
35 User RDS CALs
versus potentially licensing many more individual devices under a Device model.
That access pattern strongly favors evaluating Per User licensing first.
A Device RDS CAL follows the device.
Multiple users can use that licensed device to access an RDS Session Host.
This can make Device CALs significantly more efficient when a large workforce shares a smaller number of computers.
Microsoft specifically gives multi-shift environments as an example where Per Device RDS licensing can make sense.
Consider a warehouse operating around the clock.
One workstation may be used by an employee on the morning shift, another employee in the afternoon and a third overnight.
If the organization licenses by user, it may need to count every individual worker.
If it licenses the shared workstation appropriately by device, the RDS CAL follows the workstation instead.
Assume a distribution center has 120 employees working across three shifts.
All RDS access takes place from 40 fixed warehouse terminals.
A high-level comparison becomes:
120 User RDS CAL assignments
versus:
40 Device RDS CAL assignments
If those employees truly use only the shared terminals, Per Device is the obvious model to evaluate.
If employees also connect from personal laptops or remote devices, those additional access paths must be considered before assuming 40 Device CALs solve the entire requirement.
A call center makes the User-versus-Device choice easy to visualize.
Suppose 90 agents work across two shifts using 45 fixed workstations.
Those machines connect to an RD Session Host that provides the company’s CRM and line-of-business applications.
If every agent had a User RDS CAL, the RDS calculation would be based on 90 people.
If access remains limited to the 45 fixed devices, a Per Device design can be based on the smaller workstation population.
This is the type of environment where Device RDS CALs can reduce both cost and license-management complexity.
But if supervisors use laptops outside the call-center floor, their access must also be covered. The fixed Device CALs on the call-center PCs do not follow those supervisors home.
Remote work reverses that pattern.
Imagine a company with 50 employees using RDS.
Each employee may access the environment from a company laptop, an office desktop and occasionally another authorized endpoint.
Trying to license every possible endpoint can create more Device CAL assignments than actual employees.
A Per User RDS model allows the organization to license the 50 people rather than every device they may use.
That does not mean remote employees technically require User CALs.
It means the economics and administration usually favor User licensing when one person uses many devices.
A shared kiosk is almost the opposite situation.
Suppose a retail organization has 200 employees across multiple shifts, but remote application access occurs through 30 fixed service terminals.
If the employees do not use RDS from other devices, the device population may be a much better licensing unit than the user population.
This is exactly why the User-versus-Device choice should be made after documenting the real environment.
Do not begin with the licensing product.
Begin with:
How many people access RDS, and how many devices do they use?
Calling someone a contractor does not automatically make that person’s RDS access free.
A contractor who signs in to an organization’s Remote Desktop environment may still need appropriate Windows Server and RDS access rights.
The exact treatment can depend on whether the person is considered an internal or external user under the applicable Microsoft licensing terms. Microsoft’s Windows Server licensing guidance distinguishes employees and certain contractors or agents from qualifying external users, so organizations should not classify someone as external merely because the HR system labels the person a contractor. Microsoft
For named contractors who each work from several devices, User RDS CALs may be the practical access model.
For a rotating contractor workforce that uses a small pool of shared company workstations, Device RDS CALs may align better.
The licensing classification and the User-versus-Device choice are related questions, but they are not the same question.
Not every administrator using Remote Desktop automatically creates an RDS CAL requirement.
Windows Server licensing provides an administrative exception allowing up to two users or devices to access server instances solely to administer those instances without ordinary CAL requirements for that administrative access.
This is why an administrator can commonly use Windows Server’s built-in Remote Desktop administrative capability without deploying a full RDS Session Host environment just to manage the server.
The word solely matters.
If those connections are being used so employees can run accounting software, access a hosted desktop, operate a CRM system or perform their normal day-to-day work, that is no longer simply server administration.
Two administrative connections are not a free two-user RDS deployment.
Suppose two IT administrators occasionally sign in remotely to patch Windows Server, review event logs and manage roles.
That is an administrative scenario.
Now suppose those same accounts are used every morning to open Excel-based business processes, accounting applications and shared line-of-business software.
That is no longer merely administration.
Licensing should reflect what the sessions are actually used for, not simply the fact that the connection protocol is Remote Desktop.
The Remote Desktop Session Host role is the part of an RDS deployment that hosts Windows-based applications or complete session desktops for users.
Multiple users can establish separate sessions against the same Session Host infrastructure.
This is very different from an administrator occasionally connecting to a server to configure it.
If the business objective is to provide employees with ongoing remote application or desktop sessions, RDS CAL planning should happen before the environment enters production.
Microsoft’s licensing system uses an RD Licensing server to install, issue and track the appropriate RDS CALs used by Session Hosts.
RDS CALs are not merely invoices that sit in a purchasing folder.
A Remote Desktop Services deployment uses an RD Licensing server.
The licensing server must be activated, the RDS CALs must be installed, and the Session Hosts must be configured to use the appropriate license server and licensing mode.
This operational component is one reason RDS CALs should not be confused with ordinary base Windows Server CALs.
Microsoft’s current documentation also specifies version compatibility between RDS CALs, Session Hosts and license servers.
For Windows Server 2025 RDS CALs, the licensing server needs to run Windows Server 2025. A Windows Server 2022 RD Licensing server cannot directly serve as the license server for 2025 RDS CALs.
That detail is easy to overlook during an RDS infrastructure upgrade.
Yes. Microsoft documents a 120-day RDS licensing grace period during which a new RDS deployment can operate before a license server is required for client session licensing. Once the grace period ends, clients must have valid RDS CALs available through the licensing infrastructure to continue establishing licensed remote sessions.
Treat the grace period as deployment runway, not as a long-term licensing strategy.
Its purpose is to give administrators time to finish configuration and licensing, not to create four months of free production RDS rights.
A well-planned deployment should have its license server, licensing mode and RDS CAL inventory resolved before the business becomes dependent on the environment.
The two RDS CAL models are not identical behind the scenes.
Per Device CALs are assigned to devices and are technically tracked and enforced through the RDS licensing infrastructure.
Per User CALs are assigned to users. Microsoft notes that Per User licensing is not technically enforced in the same way, which means the administrator remains responsible for ensuring the organization owns enough valid User RDS CALs for the people accessing the environment.
This distinction can create a dangerous misconception.
If a Per User deployment continues allowing sessions even when the organization has insufficient CALs, that does not mean additional CALs are unnecessary.
Technical enforcement and licensing compliance are separate questions.
This is an important deployment constraint.
If your RD Session Host environment uses workgroup servers rather than domain-joined servers, Microsoft requires Per Device RDS CALs. Per User RDS CALs are not permitted for that workgroup deployment model.
That means the User-versus-Device choice is not always purely economic.
A small organization might initially prefer User CALs because ten employees use twenty devices.
But if its chosen RDS architecture remains in a workgroup rather than an Active Directory domain, the licensing design has to use Per Device.
Architecture can therefore determine the licensing model before cost comparisons begin.
No, not for a Windows Server 2025 Session Host.
RDS CALs are version-aware.
Microsoft states that an older RDS CAL cannot access a newer Windows Server Session Host. A Windows Server 2022 RDS CAL works with Windows Server 2022 or earlier Session Hosts, but not a Windows Server 2025 Session Host.
The reverse direction is supported.
A Windows Server 2025 RDS CAL can be used with Windows Server 2025 and supported earlier Session Host versions.
That makes RDS CAL compatibility an important item in any Windows Server upgrade project.
An organization that upgrades its RD Session Hosts to 2025 but leaves the licensing environment and CAL inventory at 2022 has not finished the migration.
| Session Host | 2025 RDS CAL | 2022 RDS CAL | 2019 RDS CAL |
|---|---|---|---|
| Windows Server 2025 | Yes | No | No |
| Windows Server 2022 | Yes | Yes | No |
| Windows Server 2019 | Yes | Yes | Yes |
Microsoft’s current compatibility matrix follows that newer-to-older direction: current CALs can cover supported older Session Hosts, while older CALs do not provide access to newer Session Hosts.
This is separate from the base Windows Server CAL question. Both layers need compatible rights.
A small office has one Windows Server 2025 RDS Session Host.
Twenty employees use the server to run a centralized accounting package.
Each employee has one dedicated company PC and never uses another endpoint.
Either User or Device licensing could conceptually fit because the user and device counts are identical.
The decision may therefore come down to workforce changes, future remote-access plans and administration.
If the company expects employees to start connecting from laptops and home devices, User CALs provide more flexibility.
If the twenty fixed PCs are permanent shared company assets while personnel turnover is high, Device CALs may be easier to manage.
The current headcount alone does not reveal the best choice.
A call center has 75 agents using 30 fixed desktops across multiple shifts.
The agents launch a RemoteApp hosted on Windows Server 2025.
The natural first model to evaluate is Per Device.
Instead of assigning RDS access rights to 75 individual workers, the organization can evaluate licensing the 30 endpoints through which access actually occurs.
The same logic should be applied to the underlying base Windows Server CAL layer as appropriate.
If team leaders also connect from laptops, their access paths need separate consideration rather than assuming the 30 call-center Device CALs cover them.
A software company has 25 staff members who use RDS from company laptops.
Some also connect from office desktops.
Others occasionally use approved home systems.
The organization might have 45 or 50 possible endpoints for only 25 people.
This is a strong Per User RDS CAL scenario.
The organization licenses the stable variable, the 25 employees, rather than trying to maintain a device inventory that changes every time an endpoint is replaced or added.
A company operates ten shared kiosks that provide a Windows Server-hosted graphical application.
Several hundred employees may use those kiosks during the year, but RDS access occurs only from those ten endpoints.
Provided the architecture and user classification support that design, Device RDS CALs are the logical model to investigate.
This is one of the clearest examples of why user count alone is not a reliable RDS licensing metric.
Microsoft also offers an RDS External Connector licensing concept for qualifying external-user scenarios. The Product Terms list a Windows Server 2025 Remote Desktop Services External Connector as the additive external-access option for RDS functionality.
That can become relevant for applications exposed to a large external population.
However, do not assume employees, onsite contractors or agents are automatically “external” for licensing purposes. Microsoft applies specific definitions.
For a conventional internal employee deployment, User or Device CALs are normally the starting point.
For a customer portal, partner application or large contractor/external-user environment, confirm the current external-user definition and licensing structure before buying individual CALs or an External Connector.
The most expensive mistake is treating an RDS CAL as though it replaces the Windows Server CAL. For normal internal-user environments, RDS is an additive access layer.
Another common error is licensing only the people sitting in front of the server today without considering whether they use multiple devices. That can make Device CALs look cheaper than they really are.
The reverse mistake happens in factories, call centers and shared-terminal environments, where organizations buy a CAL for every employee even though many people rotate through the same small set of devices.
Another risk is using the two-user administrative exception as a miniature production RDS deployment. That exception is for administration, not ordinary employee application sessions.
Organizations also upgrade Session Hosts to Windows Server 2025 while keeping older RDS CALs. Earlier RDS CAL versions do not cover a 2025 Session Host.
Finally, some deployments rely on Per User licensing in a workgroup. Microsoft requires Per Device RDS CALs for workgroup RDS environments.
Before purchasing RDS CALs, document the environment in this order:
If the user population is smaller than the device population, Per User is usually the first model to compare.
If the device population is much smaller than the user population, Per Device is usually the first model to compare.
If the environment is a workgroup, use Per Device.
Choose Windows Server 2025 RDS User CALs when employees are the stable licensing unit. This commonly includes remote workers, professionals with laptops and desktops, managers who move between locations and employees who regularly use several endpoints.
Choose Windows Server 2025 RDS Device CALs when the devices are the stable licensing unit. Shared terminals, kiosks, factories, hospitals, warehouses, training rooms and multi-shift call centers are typical examples.
Neither model changes the need to license Windows Server itself correctly. Neither should be confused with the ordinary Windows Server CAL. And neither turns the two-user administrative exception into a production Remote Desktop environment.
A reliable RDS licensing plan therefore has three layers:
License the Windows Server environment.
License the users or devices for base Windows Server access.
Add the appropriate Windows Server 2025 RDS CALs for the people or devices using Remote Desktop Services.
Once those layers are separated, choosing between User and Device RDS CALs becomes much less about licensing terminology and much more about a simple operational question:
Does your organization have more people than devices, or more devices than people?
Learn how Windows Server 2025 CAL licensing works, when to choose User or Device CALs, version compatibility, external access, and RDS requirements.
Calculate Windows Server 2025 core licensing for 16-, 24- and 32-core hosts, Standard VM stacking, Datacenter, and real server scenarios.
Learn how Windows Server 2025 Datacenter licensing works, when unlimited virtualization justifies the cost, and when Standard is still the better choice.