RD License Server no longer handing out device CALs to clients connected to separate RD Session Host Servers

Question

I have been running into a strange issue with our RD licensing server. We currently have 1 RD Licensing server, and 2 RD Host servers, all 3 are running Windows Server 2019. They are all in a workgroup, so device CALs are used. Local group policy's and registry edits have been used to confirm the correct location of the RD licensing server on both RD host servers. Everything had been working correctly up until around September 2024. The RD Licensing server also has RD Session Host role enabled, and any RDP connections to it result in a device CAL being assigned as normal. The strange part is the 2 remote RD Host enabled servers will no longer hand out device CALs to connecting devices from the RD licensing server. Instead the clients receive a "60 minute session" warning when they connect, which I understand to be some sort of a "Soft Enforcement". Running the RD licensing diagnoser from both RD Host servers show the RD Licensing server is available, the number of licenses available, and it does not identify any issues. I have tried following the steps listed here https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/cannot-connect-rds-no-license-server but nothing has helped so far.

Any suggestions would be greatly appreciated. Thanks!

Answer 1

Hello,

Below are several avenues to investigate and potential solutions to resolve the issue. In your scenario the RD Licensing Diagnoser shows that the license server is “available” and that licenses are present, yet only the RD Licensing server itself (which also has the Session Host role) is correctly issuing device CALs. On the remote RD Session Host servers you see that clients “fall back” to the 60‑minute grace period. That usually indicates that for some reason those servers aren’t actually contacting (or receiving a valid response from) the license server—even though group policy and registry settings appear correct. Here are some steps and things to check:

1. Check and Reapply Group Policy Settings

 • Confirm that on each remote RD Session Host you have configured the policies:

  – “Use the specified Remote Desktop license servers” is set with the exact name or IP (since you are in a workgroup environment, using the IP address sometimes works more reliably).

  – “Set the Remote Desktop licensing mode” is configured to “Device” CAL mode.

 • Force a policy refresh (run gpupdate /force) and consider a restart of the RD Session Host service or the server itself to be sure the changes take effect.

2. Validate Registry Settings

 • Although you’ve already checked these, double‑verify that the following registry keys reflect the correct licensing server:

  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

   – Values such as “LicenseServers” (if used) are correct.

 • In a workgroup environment it’s not uncommon for name‐resolution issues to occur. If using the server name, try the IP address (and vice‑versa).

3. Examine Firewall, Network, and RPC Communications

 • Licensing communications are based on RPC (typically using port 135 with dynamic RPC ports). Make sure no recent change (e.g. a Windows update or firewall policy change) has blocked these ports between the RD Session Host servers and the RD Licensing server.

 • Verify that the servers can “see” each other via a simple test (for example, using telnet to port 135 or PowerShell’s Test-NetConnection).

4. Review the Role Configuration on the RD Licensing Server

 • Although it is possible to have both the RD Licensing and RD Session Host roles on the same server, in your topology it may cause ambiguity. (The fact that local RDP connections to the RD Licensing server get a device CAL may indicate local settings work fine.) Consider temporarily removing or disabling the RD Session Host role on the RD Licensing server so that it functions solely as a license server. Then point the remote hosts exclusively to that server.

 • Sometimes role “overlap” can lead to unexpected behavior in a workgroup environment.

5. Check Event Logs and Recent Windows Updates

 • On the remote RD Session Host servers, review the Event Viewer logs (check under Applications and Services Logs → TerminalServices-LocalSessionManager and TerminalServices-RM) for warnings or errors related to licensing.

 • Since you mentioned the issue started around September 2024, check if any Windows updates were applied to the remote hosts that might have affected RDS licensing behavior. There have been instances where a patch inadvertently changed licensing enforcement behavior.

  – If you suspect an update, see if uninstalling it on one test server or applying a newer cumulative update fixes the problem.

6. Consider Re-installing or Re-configuring the RD Licensing Role

 • If nothing else works, try reinstalling the RD Licensing role on the license server. Re-run the licensing configuration wizard via Server Manager to ensure the license server is properly activated and configured.

 • This step can help if the licensing database became corrupt or confused (especially if the server also hosted an RD Session Host).

7. Verify Time Synchronization and System Clocks

 • Although it sounds basic, improper time synchronization between the license server and the RD Session Hosts can sometimes lead to authentication issues with CAL assignment. Verify that the server clocks are in sync.

By working through these troubleshooting steps, you should be able to pinpoint whether the issue is due to policy configuration, network/firewall constraints, service/role conflicts, or an update-related change in behavior.

---

If the Answer is helpful, please click "Accept Answer" and upvote it.