Event ID 4105: per-user RDS CALs are issued but not recorded in Active Directory

Fix it now

Event 4105 says the licence server cannot update the licence attributes for a user in Active Directory. Sessions keep working, because per-user CALs are tracked rather than enforced, which is exactly why this gets ignored. What you lose is the ability to prove how many CALs you are consuming.

1. Confirm the licence server is a domain member. Per-user tracking is supported only in domain-joined scenarios because the record is stored on the user object in AD DS.
2. In Active Directory Users and Computers, open the Builtin container and add the licence server’s computer account to the Terminal Server License Servers group.
3. If the licence server is installed on a domain controller, add the Network Service account to that group as well – Microsoft requires both.
4. Restart the licence server so its computer token picks up the new group membership.
5. In Remote Desktop Licensing Manager, right-click the server, choose Review Configuration and publish it in Active Directory Domain Services, then generate a per-user CAL report from the Reports node.

Per-user CALs cannot be tracked in a workgroup, and cannot be revoked. Device CALs are the option if tracking has to work without Active Directory.

If the report shows issued CALs again you can stop here. If not, the next section covers the events that actually accompany this one.

Why it happens

A Per User RDS CAL is not held on a device. It is recorded as an attribute on the user’s account in Active Directory Domain Services, and that is the whole mechanism. The licence server issues the CAL, then writes to the user object. Event 4105 is the second half failing: “The Remote Desktop license server cannot update the license attributes for user <name> in the Active Directory Domain <domain>.”

Nothing breaks when this happens, which is the problem. Per User CALs are tracked and reported, not enforced at connection time, so users keep working while the record of what they consumed is never written. A deployment can run for years issuing more CALs than the organisation owns, with a reporting console that shows a comfortable number because it only counts what it managed to write down.

Microsoft’s requirements for tracking to work are short and specific. It is supported only in domain-joined scenarios, because the information is stored in AD DS. The computer account of the licence server must be a member of the Terminal Server License Servers group in AD DS. And if the licence server is installed on a domain controller, the Network Service account must also be a member of that group. That third condition is the one most often missed, because a licence server on a domain controller looks like the simplest possible deployment.

Two of the events people expect to find alongside 4105 belong somewhere else entirely. Event 4103 is “The certificate cannot be installed on the Remote Desktop license server”, usually a problem connecting to the Microsoft Clearinghouse over HTTPS, and its remedy is to reactivate the server. Event 4104 is “The remote procedure call (RPC) port is not listening”, which is a licence server availability fault. Neither has anything to do with writing attributes to user objects. The events that do are 4107 – the licence server failed to query AD DS for user information – and 74, 76, 8195 and 8196, which record the computer account being added to or removed from the Terminal Server License Servers group.

Full reference

Which event means what

The events that really do accompany 4105

Read 8195 and 8196 first on a server you did not build. They tell you whether the group membership was ever created, which is the difference between something that broke and something that was never set up.

Getting an honest number

1. Fix the group membership and restart the licence server.
2. Let a full working week pass so that users actually connect and CALs are issued and recorded.
3. Open the Reports node in Remote Desktop Licensing Manager and generate a per-user CAL usage report.
4. Compare the tracked user count against the User CALs you hold.
5. Repeat monthly. The number only means something if it is being written continuously.

Why this is a compliance question rather than an outage

Per User CALs can be over-allocated. Microsoft says so plainly in its comparison of the two CAL types: a Per Device pool cannot be over-allocated, and a Per User pool can be, in breach of the agreement. The technical enforcement is deliberately weaker than the licensing obligation, which means the only thing standing between an organisation and an unnoticed shortfall is the report – and a broken 4105 makes that report say what you want to hear.

Per User versus Per Device where tracking matters

If the deployment genuinely cannot support Active Directory tracking – a workgroup licence server, or users in a forest the licence server cannot query – Device CALs are the supported answer rather than a compromise. They are tracked regardless of Active Directory membership, and they are the only type you can reclaim.

Every code this article covers

Confirm the fix worked

1. The licence server’s computer account is a member of the Terminal Server License Servers group in AD DS, and Event 74 records it.
2. Where the licence server is on a domain controller, the Network Service account is a member of the same group.
3. Event 4105 stops appearing after users reconnect.
4. A per-user CAL usage report from the Reports node lists the users who have connected.
5. Events 4143 and 4145 appear as CALs are issued and renewed, which is the positive confirmation that writing to AD DS is working.

Questions people ask about this