Event ID 1149 and 4778: counting live RDS sessions against the CALs you own

Fix it now

The logs are the only honest record of who and what actually uses your Session Hosts. Count distinct named users, and separately distinct client devices, across a full month, then compare with what the licence server holds. Peak concurrent sessions is not the number, because RDS CALs are not concurrent-use licences.

$log = 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'
Get-WinEvent -FilterHashtable @{LogName=$log; StartTime=(Get-Date).AddDays(-30)} | Select-Object TimeCreated, Id, Message | Export-Csv C:\temp\rds-sessions.csv -NoTypeInformation
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4634,4778,4779; StartTime=(Get-Date).AddDays(-30)} | Select-Object TimeCreated, Id, Message | Export-Csv C:\temp\rds-security.csv -NoTypeInformation

1. Deduplicate the merged data twice: once on account name for a user count, once on client name or address for a device count. Do it across the whole window, not per day.
2. Open Remote Desktop Licensing Manager on the licence server and read the installed CAL count and version, then run the per-user CAL usage report.
3. Compare the two numbers for whichever mode your hosts are set to. The mode is set at Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Licensing.
4. Buy the shortfall in the correct mode and version before the next audit, not after users start being refused.

Per-user CALs can be over-allocated: the licence server will keep issuing them past the number you own, in breach of the licensing agreement. Nothing in the software stops you being non-compliant, which is exactly why this count has to come from the logs.

If the logs and the licence server agree and you are within what you own, you are done. If they do not agree, the next section explains what each log actually counts and where the arithmetic goes wrong.

Why it happens

Remote Desktop Services CALs are not concurrent-use licences. They are assigned per user or per device, and the assignment is what you are counting, not simultaneous sessions. If forty people connect over a month and never more than ten at once, you need forty user CALs, not ten. That single misunderstanding is the most expensive one in RDS licensing, and it is the reason an audit built from a session monitor always comes out too low.

The two models behave differently, and Microsoft publishes the difference. A per-device CAL is physically assigned to each device and tracked by the licence server, which works even outside Active Directory; you may revoke up to twenty per cent of them; temporary CALs are issued on a device’s first sign-in and last ninety days; and they cannot be over-allocated. A per-user CAL is assigned to a user in Active Directory, cannot be tracked in a workgroup at all, cannot be revoked, and can be over-allocated in breach of the agreement. That last point is why a per-user estate can be badly short without a single error appearing anywhere.

Three logs carry the data and each answers a different question. The Local Session Manager operational log gives the cleanest session boundaries, because logon, disconnect, reconnect and logoff are recorded against the same session identifier. The Security log fills in the shape with logons, logoffs, reconnections and disconnections, and Remote Desktop sessions show there as logon type 10. The Remote Connection Manager operational log carries the source address, which is what a device count needs and what the other two do not give you.

There is one more constraint that catches people at upgrade time. An RDS CAL reaches a session host of its own version or older, never a newer one. Microsoft’s own example: 2022 CALs connect to a 2022 host or earlier, and cannot be used against a 2025 host. So the audit has two outputs, not one: how many, and of what version.

Full reference

Which log answers which question

Microsoft does not publish meanings for the Remote Desktop connection and session event numbers, so do not build an audit on a number you looked up. The security audit events are published and are safe to count on: a successful logon, a logoff, a session reconnected to a window station and a session disconnected from one. Everything else, take from the entry’s own text.

What the two models actually commit you to

Read the last row twice. A per-user deployment that is fifty CALs short behaves exactly like one that is fully licensed. Nothing warns you, nothing refuses a connection, and the first sign is an audit. A per-device deployment that runs out stops issuing, which is unpleasant on the day and honest for the year.

Version, not just quantity

A CAL reaches a session host of its own version or older, and never a newer one. Microsoft’s published example is that 2022 CALs connect to a 2022 host or earlier but not to a 2025 host. So the audit has to record the Windows Server version of every Session Host as well as the head count. A collection being upgraded is the moment this bites: the hosts move, the CALs do not, and the licence server starts refusing on a Monday morning.

Setting and reading the mode

• The licensing mode and the licence server list are set at Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Licensing.
• Two policies matter there: Use the specified Remote Desktop license servers, and Set the Remote Desktop licensing mode.
• Set both from one Group Policy object scoped to the collection, not per host. A rebuilt host that inherits neither will behave differently from its neighbours and skew the next audit.
• In a workgroup deployment there is no choice to make: per-device is the only permitted mode.

Running the audit so it is worth running

1. Raise the maximum size of the operational logs on every host now, before you need the history. A week of data captures the regulars and misses precisely the people who make your count wrong.
2. Collect for at least a month, longer if you have seasonal or quarterly users.
3. Collect from every host with the role, including standalone servers nobody lists on the architecture diagram.
4. Merge, then deduplicate twice: once on account, once on client.
5. Record the Windows Server version of each host alongside the counts.
6. Reconcile with the licence server, and where the two disagree, work out which question each was answering before you trust either.

The administrative connection allowance

Windows Server includes an allowance of remote sessions for administering the server itself, separate from Remote Desktop Services. The number and the conditions attached to it come from your Windows Server licensing terms rather than from anything the software reports, so read those terms rather than a figure quoted in a forum. What is clear either way is the boundary: using those sessions to run applications or do ordinary work is not administration, and it is not covered by that allowance.

Every code this article covers

Confirm the fix worked

1. The deduplicated user and device counts were built from every Session Host with the role, not a sample.
2. The installed CAL count on the licence server meets or exceeds the count for the mode your hosts are actually set to.
3. The CAL version on the licence server is at least as new as the Windows Server version of every host.
4. The per-user CAL usage report reconciles with the log-derived figure, or you know why it cannot.
5. A calendar reminder exists to repeat the audit before the next Windows Server upgrade.

Questions people ask about this