SharePoint and Remote Desktop Services are both licensed under SPLA by Subscriber Access License, and both are counted by who can access the service — which is exactly why they generate so many reporting errors. Access-based counting sounds simple until provisioned-but-idle accounts, external collaborators, and shared service accounts blur the line between who has access and who actually uses it. This guide sits under our Microsoft SPLA licensing guide and explains how to report SharePoint and RDS accurately.
The shared characteristic of these two products is that the license follows access, not consumption. Under SAL, granting a user the ability to reach the service is the licensable event, whether or not they log in that month. Estates that provision generously and de-provision lazily therefore drift toward over-reporting on the access count even as they risk under-reporting if external users are missed. Both directions are corrected only by maintaining an accurate access list.
How SAL counting works for these products
A Subscriber Access License is required for each unique user (or device) with access to the licensed product during the reporting month. For Remote Desktop Services, that means each user able to establish an RDS session. For SharePoint, it means each user able to access the SharePoint farm's content. The count is of distinct accessors in the month, reported against the Product Terms in force for that month — the same version-of-record principle that governs the whole program.
| Product | SAL counts | Common over-count | Common under-count |
|---|---|---|---|
| Remote Desktop Services | Users able to start an RDS session | Disabled/idle accounts still entitled | Service accounts and contractors missed |
| SharePoint | Users able to access the farm | Broad security groups granting latent access | External/anonymous-but-authenticated users |
For RDS, the most frequent over-count comes from accounts that retain session rights long after the person has left or moved on. For SharePoint, it comes from broad security-group membership that grants access far beyond the people who use the site. The under-counts are the mirror image: contractors, service accounts, and external collaborators who can reach the service but were never added to the licensing tally.
Why these two products draw audit attention
RDS and SharePoint deployment leaves clear evidence — connection brokers, session logs, Active Directory group membership, and farm access controls — that an auditor can reconcile against your reported SAL counts. Because the evidence is rich and the counting is access-based, discrepancies are easy to surface. That is precisely why these products feature so often in audit findings, and why they are central to our SPLA audit defence guidance.
Access is not usage: the defining SAL mistake is assuming you only license users who logged in. Under SAL, the licensable event is the ability to access, not the act of accessing. An account that could have connected but did not still counts. The cure is operational: a monthly de-provisioning routine that removes access the moment it is no longer needed keeps the SAL count tied to reality rather than to historical accumulation.
The infrastructure underneath
SharePoint and RDS do not stand alone. They run on Windows Server and frequently on SQL Server, each licensed separately under its own per-core rules. A complete SPLA report for an RDS or SharePoint service therefore has three layers: the SAL access count for the application, the Windows Server cores for the hosts, and the SQL Server licensing for the back end. The infrastructure layers are covered in Windows Server SPLA licensing and SQL Server SPLA licensing; missing one of the three layers is itself a common finding.
Reporting SharePoint and RDS each month
The monthly report should state the unique SAL count for each product against the in-force Product Terms, supported by an access list that is reconciled to the underlying directory and farm permissions. The single most valuable control is a recurring de-provisioning and reconciliation cadence: each month, confirm that the people with access are the people who should have it, then report that number. Done consistently, this both trims over-reporting cost and closes the under-reporting gaps that auditors look for. Our advisors build that reconciliation as part of Microsoft audit defense, and the program-wide rules are in the SPLA licensing guide.
Common SharePoint and RDS reporting mistakes
The defining error for both products is conflating access with usage. Providers who report only the users who logged in during the month are under-reporting, because under SAL the licensable event is the ability to access, not the act of accessing. The mirror error is reporting a historical access list that has accumulated departed staff, contractors who finished months ago, and security-group memberships that grant latent access no one uses — which inflates the count and the cost. The cure for both is the same: a maintained, current access list reconciled to the directory each month.
A second error specific to SharePoint is broad security-group grants. A site secured to a wide group can technically grant access to hundreds of people who never open it, all of whom count under SAL. Tightening site permissions to the actual user community is both a security improvement and a licensing saving.
A third error is missing the external accessor. Contractors, partners, and service accounts that can reach RDS or SharePoint but live outside the usual user directory are easy to overlook, and they are exactly what an auditor looks for. The access reconciliation must include every accessor, not only the employees in the primary directory.
The de-provisioning discipline
The single control that fixes most SharePoint and RDS reporting problems is a monthly de-provisioning routine tied to joiners, movers, and leavers. When access is removed the moment it is no longer needed, the SAL count naturally tracks reality, over-reporting cost falls away, and the under-reporting gaps an auditor probes simply do not open. This is an operational habit rather than a licensing exercise, which is why it works: it lives in the same identity and access processes the platform already runs, and it turns the monthly SAL report into a by-product of good account hygiene rather than a separate counting project.