RDS CALs: licensing remote work

The old server launches the ERP application through an RDP file. Users connect successfully, yet the licensing manager shows fewer assigned licences than the number of people using the application. Moving to Windows Server 2025 raises two separate questions: will the new server accept connections, and is the actual workload properly licensed?

Count RDS User CALs by the people entitled to access the service, not concurrent sessions. Count RDS Device CALs by the devices that access it. A successful sign-in does not prove sufficient licensing. An accurate order also depends on the CAL type, session-host version, licensing-server version and whether the deployment uses a domain or a workgroup.

This guide covers internal business RDS on Windows Server under commercial licensing. Hosting services, external customers, SPLA and Azure Virtual Desktop involve additional conditions. Contractual examples use the current MCA Product Terms, checked on 14 October 2026. Select the appropriate terms if your agreement uses a different programme.

Separate the three licensing layers first

Windows Server needs licensing for the server software itself. Internal access also requires assessment of the base Windows Server CAL or an appropriate equivalent entitlement. Remote working interfaces add an RDS CAL or the applicable RDS User SL. The Product Terms identify RDS as an additive access right; a base CAL alone does not replace it.

Some enterprise Microsoft 365 suites provide base server access rights. Check the exact row in the CAL equivalency table. Microsoft 365 E3 covering the Windows Server Base CAL does not mean it includes an RDS CAL. Confusing these rights can change the conclusion of the entire inventory.

Office in a session has its own application and activation rules. See the guide to Office shared computer activation. Purchasing RDS CALs does not fix missing Microsoft 365 Apps rights.

RemoteApp and two administrative sessions

Whether a person sees a full desktop or only the ERP window is not the deciding factor. The Product Terms also require additive RDS rights when Windows Server hosts a graphical user interface through other technology. A client name, RDP file or alternative remote protocol is not a reliable reason to omit RDS licensing.

The universal software terms permit access by two users without CALs solely for administrative purposes. These are not two free working seats for accounting or sales staff. Connecting with /admin does not turn ERP use into server administration.

Record the purpose of access in your inventory. An administrator configuring updates and server settings is a different scenario from someone processing invoices on the same server. If the activities overlap, do not treat the administrative exception as blanket coverage for the account.

User, Device and the actual access population

The RDS CAL overview explicitly notes that Per User can be technically overallocated. Licences may therefore be missing even when nobody sees an error. Per Device licence issuance, by contrast, limits the number of covered devices. Concurrent sessions are not the common counting basis for both models.

Hypothetical example, not customer data: a company has 60 employees sharing 20 office workstations in shifts. Three managers within that same group also connect from their own laptops. All access is internal work through RDS, and appropriate licence versions are available.

These counts exclude base Windows Server rights, server licences and applications. The table is not a pricing recommendation: Per Device requires device records, and every additional access device changes the scope. Per User may be easier to manage when people regularly switch between laptops, home PCs and other devices.

For device licensing, examine the endpoints from which people actually connect. The ERP server or a shared sign-in account does not replace endpoint inventory. Map both corporate laptops and personal computers before comparing offers if employees use both.

An upgrade involves three separate versions

The session host determines which RDS CAL version you need. Later RDS CALs can cover earlier hosts; the reverse is not true. The licensing server must also support installation of the relevant CAL pack. Microsoft documents these as two separate relationships in its RDS CAL compatibility guidance.

The table does not establish sufficient quantities, the selected mode or compatibility of the complete RDS topology. When upgrading brokers, gateways and other roles, also check supported RDS configurations. Do not use a single entry labelled “RDS 2025” to describe several different components in the procurement specification.

Workgroups change both the model and diagnosis

A domain deployment can use the appropriate Per User or Per Device mode. In a workgroup, the session-host licensing guide requires Per Device. This is more than unavailable user reporting: the documentation expressly does not permit Per User in that environment.

If the RD Session Host and licensing server run on different machines in a workgroup, another check applies. Following the security update for CVE-2024-38099, the licensing server requires nonanonymous credentials. Microsoft describes a dedicated account on the licensing server and making its credentials available to the service on the session host. This particular step does not apply to the domain scenario or when both roles run on the same machine.

An error following an update therefore need not mean too few CALs were purchased. Check the mode, versions, connectivity and authentication first. Disabling authentication enforcement is not the recommended default; the documentation warns of increased security risk. The cross-environment licensing-server guide explains the differences between domains, trusts and workgroups.

Verify licensing before launching the new server

After installing RD Session Host, a technical grace period of 120 days allows operation without requiring a licensing server. It does not prove the licensing scope is correct. Include working licensing in the migration plan before normal business depends on the new host.

1. Map access. Record individual people, devices, applications, purposes and connection methods. Include access from outside the office.
2. Choose the model. Document User or Device and the justified count. Use Device for workgroups. Separately document base server and application rights.
3. List the three versions. Host, CAL and licensing server. Attach purchase records and any upgrade rights, not just a screenshot of the installed pack.
4. Prepare CAL issuance. Activate the licensing server and install the purchased compatible pack using Microsoft’s instructions. Then configure the licensing server and mode on the host. For deployments without a Connection Broker, use the corresponding policies in Microsoft’s guide. Check the effective settings and whether another policy overrides them.
5. Run RD Licensing Diagnoser. For workgroups, also check service authentication. Network connectivity does not prove correct credentials.
6. Test representative access. Include an ordinary user, a shared workstation and a remote laptop, then compare CAL issuance with the inventory. In User mode, the absence of blocking is not an extra licence.
7. Assign responsibility for changes. New devices, employees, server upgrades and model changes need a named owner of the licensing records.

The result should be two separate confirmations: a supported, functioning technical deployment and licence coverage for the stated use. One successful session test does not provide both.