Remote Desktop Services is separately licensed from Windows Server — a distinction that surprises many organisations that believe their Windows Server CALs cover Remote Desktop access. They do not. Accessing Windows Server via RDP, RemoteApp, Remote Desktop Session Host, or Virtual Desktop Infrastructure requires both a Windows Server CAL and an RDS CAL. The absence of RDS CALs is one of the most common CAL-related audit findings in enterprise Microsoft licensing reviews, particularly in organisations that deployed RDS incrementally or expanded Remote Desktop access during hybrid work transitions without updating their licence baseline.
This guide covers the RDS licensing structure, the difference between RDS Per Device and Per User CAL modes and when each applies, the specific licensing requirements for RemoteApp and Virtual Desktop Infrastructure, the grace period mechanics that many organisations misuse, and the audit exposure profile for organisations with unlicensed RDS deployments.
For the Windows Server CAL framework that RDS CALs supplement, see Windows Server CAL Licensing: User vs Device CALs. For the complete Windows Server licensing overview, see the Windows Server Licensing Complete Guide.
RDS Licensing Structure
Remote Desktop Services in Windows Server comprises several role services, not all of which require the same licensing treatment. The core licensing requirement arises when users connect to a Remote Desktop Session Host (RDSH) — a Windows Server configured to host multi-user Remote Desktop sessions. Every device or user connecting to an RDSH requires both a Windows Server CAL and an RDS CAL.
The components of a typical enterprise RDS deployment:
- Remote Desktop Session Host (RDSH). The server running the multi-user RDP sessions. Each user or device connecting requires both a Windows Server CAL and an RDS CAL.
- Remote Desktop Broker. Routes connections to appropriate RDSH servers. No additional per-user licence required beyond the RDSH requirement.
- Remote Desktop Gateway. Provides secure external access to RDSH sessions. Does not require additional licences beyond the RDSH requirement for the sessions being tunnelled through it.
- Remote Desktop Web Access. Web portal for RemoteApp and Desktop connections. No additional per-user licence beyond the RDSH requirement.
- Remote Desktop Licensing Server. Issues RDS CALs to connecting clients. Requires at least one licensing server per RDS deployment.
Windows Server CALs do NOT cover Remote Desktop Services access. An organisation with 1,000 Windows Server User CALs but no RDS CALs is unlicensed for Remote Desktop access by all 1,000 users. The Windows Server CAL and RDS CAL are additive requirements — both must be present for RDS access to be compliant.
RDS CAL Modes: Per Device vs Per User
RDS CALs come in two modes — Per Device and Per User — that operate the same way as Windows Server CALs: Per Device authorises a single device to connect to any RDSH by any number of users, while Per User authorises a single named user to connect from any device.
RDS Per Device CAL
An RDS Per Device CAL is assigned to a specific device. Any user who accesses an RDSH from that device is covered. Per Device CALs are the correct choice when multiple users share devices and connect to RDSH — manufacturing terminals, hospital workstations, retail kiosks, and similar shared-device environments. The RDS Licensing Server issues a Per Device temporary token to the connecting device and tracks the assignment.
RDS Per User CAL
An RDS Per User CAL is assigned to a specific named user. That user may connect to any RDSH from any device — desktop, laptop, mobile, or home computer — covered by a single Per User CAL. Per User CALs are appropriate for knowledge workers who access RDSH from multiple personal devices and for remote workers connecting from unmanaged devices. Unlike Per Device CALs, Per User CALs are not technically enforced by the RDS Licensing Server in the same way — the server does not block connections when Per User CAL counts are exceeded. This does not make excess Per User CAL usage compliant; it simply means the compliance gap is not caught at the point of connection and will only be identified during an audit or manual review.
Per Device vs Per User RDS CAL Economics
RDS Per Device and Per User CALs are typically priced equally per unit. As with Windows Server CALs, the economic difference is entirely driven by the ratio of users to devices in your access population.
| Access Scenario | Users | RDS Devices | Per User CAL Count | Per Device CAL Count | Optimal Mode |
|---|---|---|---|---|---|
| Office workers, one device each | 500 | 500 | 500 | 500 | Either |
| Office workers, avg 1.8 devices each | 500 | 900 | 500 | 900 | Per User |
| Call centre, shift workers, shared PCs | 1,200 | 300 | 1,200 | 300 | Per Device (75% saving) |
| Healthcare, nurses sharing terminals | 3,600 | 600 | 3,600 | 600 | Per Device (83% saving) |
| Mixed: 200 office + 600 shift workers | 800 | 560 (360 office + 200 shared) | 800 | 560 | Per Device (30% saving) |
Mixed RDS CAL deployments — Per Device for shift-worker populations, Per User for office workers with multiple personal devices — require separate RDS CAL pools on the licensing server. This is supported in Windows Server RDS Licensing Server configuration and is the recommended approach for organisations with heterogeneous access patterns.
RemoteApp Licensing
RemoteApp delivers individual applications rather than full desktop sessions over RDP. Users see what appears to be a locally installed application window, but the application is running on an RDSH. The licensing requirement is identical to full desktop RDS: every user or device accessing a RemoteApp application requires both a Windows Server CAL and an RDS CAL assigned to the appropriate session host.
The common misunderstanding: RemoteApp looks like an application delivery technology, and organisations sometimes treat it as outside the RDS licensing framework. It is not. RemoteApp uses the Remote Desktop Session Host infrastructure — it runs on RDSH servers, uses the RDS Broker for session routing, and triggers the same CAL requirement as a full desktop session. There is no separate RemoteApp licence and no reduced-cost alternative to standard RDS CALs for RemoteApp delivery.
The practical implication: organisations that deployed RemoteApp as a VDI alternative or an application virtualisation layer during the 2020–2022 work-from-home period, and that counted RDS users only for full desktop sessions, are typically under-licensed for their RemoteApp user population by the extent to which RemoteApp users exceed or duplicate their full desktop RDS user count.
Virtual Desktop Infrastructure Licensing
VDI deployments — where each user gets a dedicated virtual machine running a full Windows OS rather than a shared RDSH session — have a different licensing structure from RDSH-based RDS. Whether Windows Server or Windows client OS is running in the VDI determines the licensing framework:
Windows Server VDI (RDSH)
VDI implemented using Windows Server as the guest OS — each user connecting to a dedicated Windows Server VM — requires the same RDS CAL as multi-user RDSH sessions. The Windows Server VM itself requires a Windows Server licence (covered by the host licence if Datacenter Edition), and each user connecting to it requires a Windows Server CAL and an RDS CAL.
Windows Client VDI (Requires VDA or M365 E3/E5)
VDI implemented using Windows 10 or Windows 11 as the guest OS requires Windows Virtual Desktop Access (VDA) licensing or is covered by Microsoft 365 E3 or E5 licences. This is a different licensing framework from Windows Server RDS CALs and is governed by the Windows desktop licensing terms rather than the Windows Server licensing terms. Organisations running Windows client VDI should ensure they are not conflating RDS CAL coverage (for Windows Server RDSH) with VDA or M365 coverage (for Windows client VDI).
The RDS Grace Period: A Misused Provision
Windows Server includes a 120-day grace period for RDS deployments during which the RDS Licensing Server issues temporary grace period licences rather than requiring installed RDS CALs. This grace period is intended to allow organisations time to procure and install RDS CALs for new deployments. It is not a perpetual operating mode.
The pattern we identify regularly: organisations that deployed RDS — often in response to remote work requirements — entered the grace period, never purchased RDS CALs, and have been operating on expired grace period tokens or with the RDS Licensing Server configured to continue issuing connections despite the expired grace period (a configuration state that Windows Server permits but that does not constitute compliance). When the RDS Licensing Server is configured in a mode that allows connections without valid installed CALs, the deployment is unlicensed regardless of whether connections are technically permitted.
Operating an RDS deployment that has passed the 120-day grace period without installed RDS CALs is a compliance violation. The fact that the RDS Licensing Server continues to issue connections does not constitute a valid licence. Microsoft auditors confirm RDS CAL installation status through direct review of the RDS Licensing Server configuration and CAL issuance records. The retroactive exposure covers the full period of unlicensed operation, calculated at current pricing.
Azure Virtual Desktop and RDS
Azure Virtual Desktop (formerly Windows Virtual Desktop) is Microsoft's cloud-hosted VDI service that delivers Windows 10/11 multi-session desktops and RemoteApp from Azure. AVD has its own licensing model: access is included in Microsoft 365 E3, E5, Business Premium, and a range of other M365 subscriptions. Organisations running AVD as their primary remote desktop solution do not require separate RDS CALs for their AVD sessions — AVD access rights are bundled into qualifying M365 licences.
The licensing complexity arises in hybrid environments where both on-premises RDS (RDSH) and AVD are deployed. Users accessing on-premises RDSH require RDS CALs. Users accessing only AVD require qualifying M365 licences. Users accessing both require both. Licence governance must track which sessions each user accesses to ensure the correct coverage is in place for each access type.
Audit Exposure and Common Findings
RDS licensing findings in formal Microsoft audits typically fall into four categories:
- Missing RDS CALs entirely. The most common pattern: Windows Server CALs are in place but no RDS CALs were ever purchased. All Remote Desktop users are unlicensed for the RDS component. Exposure calculation: full RDS user population × RDS CAL price × number of years of deployment (retroactive period is typically 1–3 years depending on audit scope).
- RDS CAL count below actual user population. RDS CALs were purchased for the initial deployment user count but not updated as RDS access expanded — through additional user groups, hybrid work policy changes, or RemoteApp additions. The shortfall is the delta between CAL count and actual accessing population.
- Per Device CALs used for Per User access pattern. RDS configured in Per Device mode issues device tokens. If users connect from multiple devices (personal laptops, home PCs, mobile), each device receives a token — but Per Device CALs were only counted per the office device inventory. Home devices and personal laptops create additional Per Device CAL requirements that are not captured in the office inventory. Organisations in this scenario should switch to Per User CALs and recalculate the correct count.
- Grace period expiry with no CAL installation. RDS deployed in grace period mode, never remediated. All connections during and after the grace period are unlicensed for RDS CAL purposes.
Remediation and Governance
The remediation sequence for RDS CAL shortfalls:
- Establish the actual RDS access population. Export the RDS Licensing Server connection log and the AD group membership of users with RDS access permissions. The larger of these two counts is the starting point for the CAL requirement calculation.
- Determine the optimal CAL mode. Apply the Per Device vs Per User break-even analysis. If your RDS user population accesses primarily from shared devices, switch to Per Device. If primarily from multiple personal devices, Per User is cheaper. Model both options against your actual access population before selecting a mode for the EA amendment.
- Purchase the remediation quantity. RDS CALs can be added to an EA via amendment during the term. The remediation quantity is the gap between installed CALs and actual access population. Purchase via amendment rather than deferring to renewal — deferring creates ongoing retroactive exposure.
- Install CALs on the RDS Licensing Server. RDS CALs must be installed on the licensing server to be technically active. Simply purchasing CALs without installation does not satisfy the licensing requirement from a compliance standpoint.
- Implement quarterly CAL count reconciliation. Compare RDS Licensing Server installed CAL count against the current RDS-enabled user count (or device count in Per Device mode). Reconcile joiner and leaver activity quarterly. Adjust CAL quantities at the next true-up if discrepancies arise.
For the complete true-up and compliance management framework, including how to manage CAL counts through the annual EA true-up cycle, see the Microsoft True-Up Compliance Guide.
RDS CAL remediation before an audit is almost always cheaper than remediation after one. Proactive purchase at EA pricing, with a documented governance framework as evidence of good faith compliance posture, is substantially less expensive than retroactive catch-up at list pricing covering a multi-year audit period. If you have expanded RDS access in the last 18–36 months and have not updated your RDS CAL count, that gap should be addressed before your next EA renewal.