Remote Desktop Services is one of the most underlicensed workloads in the Microsoft estate because it requires two CALs where teams remember only one. Every user or device accessing an RDS session host needs a Windows Server CAL for the operating system and a separate RDS CAL for the remote session right. The per device RDS CAL is enforced by the license server, but the per user RDS CAL is not enforced at all, which means user mode deployments accrue gaps silently while everything keeps working. Add the grace period that lets a host run unlicensed for a fixed window, and estates routinely discover at audit that their session population far exceeds their RDS CAL coverage. The buyer side defense reconstructs the session population against the RDS CAL position, work that across the practice supports the 79% average audit exposure reduction.
Remote Desktop Services lets multiple users run sessions on a Windows Server, whether for full desktops or for individual published applications. Accessing that session host requires two distinct CALs per user or device: the Windows Server CAL that covers operating system access, and the RDS CAL that covers the remote session right specifically. The two are separate products with separate counts. Estates that bought RDS CALs but forgot the underlying Windows Server CALs, or the reverse, carry exposure on whichever layer was overlooked.
Every RDS session sits on a two CAL stack. The Windows Server CAL is the same CAL any server access requires. The RDS CAL is an additional, RDS specific license layered on top. Neither covers the other, and the audit counts both independently against the same session population.
The RDS license server tracks and enforces per device RDS CALs, issuing and reclaiming them as devices connect. It does not enforce per user RDS CALs, which are tracked on the honor system. A per user RDS deployment will let any number of users connect regardless of CAL coverage, so the gap grows invisibly until an audit counts the actual session population.
Microsoft and its appointed auditors target RDS because the combination of two required CALs, an unenforced per user metric, and a grace period that masks the requirement produces large, reliable findings. Session hosts are easy to discover and the session population is logged, so the auditor can establish the count with confidence while the customer, having never been forced to track it, usually cannot rebut the number without a reconstruction.
A new RDS deployment runs for a grace period of a fixed number of days before it requires a configured license server and installed CALs. Estates that stood up session hosts inside the grace window and never completed the licensing, because everything kept working, carry exposure for the entire session population once the window closed. The grace period masks the requirement rather than waiving it.
Office or M365 Apps for enterprise running inside an RDS session requires shared computer activation and a qualifying per user subscription, just as it does in any multi session context. RDS estates that deployed a volume Office build to the session hosts without the right activation model add an Office finding on top of the RDS CAL finding, across the same population.
External users connecting to RDS session hosts need coverage too. Where partners or customers access published applications, the choice is per user or per device RDS CALs for each, or in some scenarios an External Connector. Estates that expose RDS to external populations without explicit coverage carry exposure for every external session identity.
RDS CALs come in per user and per device variants, and the metric is chosen the same way as any CAL: by the user to device ratio of the session population, as covered in the user versus device CAL analysis. The version rule applies as well: an RDS CAL must match or exceed the version of the session host it covers, so upgrading the Windows Server underneath an RDS deployment without upgrading the RDS CALs creates a version gap. The per device variant is enforced and reclaimed by the license server, while the per user variant is honor based, which means a per user deployment depends entirely on an accurate internal count that most estates never maintain. The reconstruction rebuilds that count from the session logs.
RDS exposure changes with where the session hosts run. On premises session hosts need RDS CALs through the volume agreement. Session hosts on Azure can use RDS CALs with the appropriate rights, and some Azure delivered desktop scenarios use different entitlement models entirely, which is why the boundary with VDI licensing matters. A session host fronted by Citrix still needs RDS CALs because Citrix replaces the broker, not the session right. Mapping the placement of every session host, and the access route into it, determines which CAL model and which rights apply, and prevents the common error of assuming one model covers an estate that actually spans several.
The defense posture is to rebuild the RDS session population from connection logs and reconcile it against both the Windows Server CAL and the RDS CAL coverage, applying the metric and version rules. Because the per user metric is unenforced, the reconstruction is the only way to establish the true count, and establishing it on the buyer's terms is what prevents the auditor's higher assertion from standing.
The reconstruction documents every session host, its RDS license server mode, and the actual user and device session population drawn from the connection logs rather than from CAL purchase records. The Windows Server CAL coverage and the RDS CAL coverage are reconciled separately against that population, and the version of each is checked against the session host version.
Data sources include the RDS license server, the session host event logs, identity systems, and the license entitlement records. The reconstructed population is the document that answers the RDS portion of any audit defense data request with evidence rather than the auditor's estimate.
With the population reconstructed, the remediation sizes both CAL layers to the actual session count, chooses the metric that minimizes each, and corrects any version gap. Office activation inside the sessions is aligned to qualifying subscriptions. External session populations are covered explicitly.
The renewal is the moment to acquire the right RDS CAL and Windows Server CAL volumes, set the metric deliberately, and decide where Azure delivered models replace traditional RDS CALs. The EA renewal framework structures the RDS position so the reconstructed count holds and both CAL layers stay covered through the term.
The practice runs an RDS reconstruction engagement that rebuilds the session population from the logs and reconciles it against both CAL layers, the metric, and the version rule into a defensible position across the estate.
The engagement produces a documented RDS position covering each session host, its session population, the Windows Server CAL and RDS CAL coverage, the metric, and the version compliance. The position is the basis for any compliance review and the foundation for the RDS commercial structure at the next renewal.
Three questions that recur once the mapping work begins.
Because of the grace period and the unenforced per user metric. A new RDS deployment runs for a fixed number of days before it requires a configured license server, and the per user RDS CAL is never enforced at runtime. So sessions succeed whether or not CALs exist, and the gap accrues silently. The requirement was masked, not waived, and an audit counts the full session population once the window closed.
Yes, both, per accessing user or device. The Windows Server CAL covers operating system access and the RDS CAL covers the remote session right specifically. They are separate products with separate counts, and neither covers the other. The most common RDS finding is an estate that bought one layer and forgot the other, leaving the overlooked layer uncovered across the whole session population.
Yes. Office or M365 Apps for enterprise inside an RDS session requires shared computer activation and a qualifying per user subscription, the same as any multi session context. Deploying a volume Office build to the session hosts without the right activation model adds an Office finding on top of the RDS CAL finding, across the same population, so the activation model has to be verified alongside the CALs.
The worksheet the practice uses to reconstruct the RDS session population against Windows Server CAL and RDS CAL coverage, with the per user enforcement gap and grace period built in.
Two analyst calls. We rebuild the RDS session population across every session host, reconcile it to the Windows Server CAL and RDS CAL coverage, and close the gaps while they are still cheap. Full audit defense practice.