Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license

Hi, it's BlueByte. Users who connected fine yesterday are now bounced at sign-in with The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license. Nothing crashed and no update ran: a Remote Desktop Session Host that has passed its licensing grace period refuses sessions on purpose until a license server can issue a client access license. We'll walk through the message variants, why the host started refusing, how to confirm the cause in a couple of commands, the fix per cause, and how to keep the deployment from walking into the same wall after an upgrade.

The message users see, and the two the diagnoser adds

Clients get one of two sentences — the licensing one above, or Access was denied because of a security error., which points at a different cause covered at the end. The useful detail is on the server. Sign in to the session host as a domain administrator and open the RD Licensing Diagnoser (Server Manager, then Tools, Terminal Services, RD Licensing Diagnoser). It states the problem in plain words, such as The grace period for the Remote Desktop Session Host server has expired, but the RD Session Host server hasn't been configured with any license servers. Connections to the RD Session Host server will be denied unless a license server is configured for the RD Session Host server. or License server <computer name> is not available. This could be caused by network connectivity problems, the Remote Desktop Licensing service is stopped on the license server, or RD Licensing isn't available. Those two sentences separate "no license server configured" from "configured but unreachable", which is the first fork in this diagnosis.

Why the session host started refusing connections

There is a licensing grace period of 120 days during which no license server is required. Once it ends, clients must have a valid RDS CAL issued by a license server before they can sign in to a remote session. That deadline is what turns a working lab deployment into an outage four months later. The distinct causes:

• The grace period expired and no license server is configured at all.
• A license server is configured but not activated, or holds no CALs for this deployment.
• The CALs are too old for the session host. Later CALs serve earlier hosts, never the other way round: Windows Server 2022 CALs work on 2022, 2019 and 2016 hosts, and are refused by a 2025 host.
• The deployment is a workgroup and someone chose Per User. Per User CALs can't be tracked within a workgroup and aren't permitted there; workgroup deployments have to use Per Device.
• The license server is configured and healthy but unreachable — RPC ports blocked, or the Remote Desktop Licensing service stopped.

Ask the session host what it thinks its licensing is

Two commands settle which cause you have. Win32_TerminalServiceSetting lives in the Root\CIMv2\TerminalServices namespace, and its GetGracePeriodDays method documents that a zero value means the grace period is over:

$ts = Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TerminalServiceSetting
$ts | Select-Object ServerName, TerminalServerMode, LicensingType, PolicySourceLicensingType
Invoke-CimMethod -InputObject $ts -MethodName GetGracePeriodDays
Invoke-CimMethod -InputObject $ts -MethodName GetSpecifiedLicenseServerList

ServerName                : RDSH01
TerminalServerMode        : 1
LicensingType             : 4
PolicySourceLicensingType : 0
 
DaysLeft ReturnValue
-------- -----------
       0           0
 
SpecifiedLSList ReturnValue
--------------- -----------
{}                        0

Read it against the documented values. TerminalServerMode 1 means the host runs as an application server, so CALs apply. LicensingType 4 is Not Configured (2 is Per Device, 3 is Per User). PolicySourceLicensingType 0 means the setting came from the server, 1 means Group Policy is deciding — worth knowing before you edit the wrong place. An empty SpecifiedLSList with DaysLeft 0 is the textbook case: grace over, nothing configured.

Point the deployment at an activated license server

If your deployment has an RD Connection Broker, set it there, either in Server Manager under Remote Desktop Services, Overview, Edit Deployment Properties, RD Licensing — or in one line:

Set-RDLicenseConfiguration -LicenseServer @("Rdl-1.Contoso.com","Rdl-2.Contoso.com") `
  -Mode PerUser -ConnectionBroker "Rdcb.Contoso.com" -Force

-Mode accepts PerDevice, PerUser and NotConfigured, and Get-RDLicenseConfiguration reads the current setting back.

For a host that only has the RD Session Host and RD Licensing roles, with no broker, the setting lives in policy: open gpedit.msc and go to Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Licensing. Enable Use the specified Remote Desktop license servers and enter the server names, separated by commas if there are several. Then enable Set the Remote Desktop licensing mode and pick Per Device or Per User. Before either step, confirm in RD Licensing Manager that the license server is activated and that its CAL counts are real — a green check beside the server name, with totals and available numbers that match what you bought.

Check the CAL version actually covers your session host

This one bites during upgrades, because nothing in the deployment looks misconfigured. A 2019 license server cannot hold 2022 or 2025 CALs, and a 2022 CAL cannot serve a 2025 session host. Install CALs on a license server running the same version of Windows Server as the CALs or later, and make sure the CAL version is at least the version of the host it has to serve. If you add a Windows Server 2025 session host to a farm licensed with 2022 CALs, that host alone will start refusing sessions while every older host keeps working.

When the configuration is right and the server is still unreachable

Between session host and license server, RD Licensing runs over RPC: TCP 135 for the endpoint mapper, plus the randomly allocated dynamic range TCP 49152–65535 on Windows Server 2008 and later, with TCP 445 and 139 for SMB and NetBIOS session traffic, and TCP/UDP 389 for LDAP when you use per-user CALs in Active Directory. Activation over the internet to the Microsoft Clearing House uses TCP 443.

Test-NetConnection -ComputerName Rdl-1.Contoso.com -Port 135
Get-Service -DisplayName "Remote Desktop Licensing" -ComputerName Rdl-1.Contoso.com

ComputerName     : Rdl-1.Contoso.com
RemoteAddress    : 10.20.4.11
RemotePort       : 135
TcpTestSucceeded : True
 
Status   Name               DisplayName
------   ----               -----------
Running  TermServLicensing  Remote Desktop Licensing

One more setting hides in this class of failure: the Access this computer from the network right, under Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment. If Everyone isn't assigned, assign it to Authenticated Users, Domain Computers, or the session host's computer account.

A worked example: day 121 on a Windows Server 2022 farm

A two-host farm was stood up for a pilot in May and quietly became production. On a Tuesday in September, every new connection fails with the licensing message while existing sessions keep running. The diagnoser reports the expired grace period with no license servers configured. GetGracePeriodDays returns DaysLeft 0, GetSpecifiedLicenseServerList returns an empty array, and LicensingType reads 4. The team already owned 2022 CALs from another project, so they activate the licensing role on the broker, install the CAL pack, confirm the green check in RD Licensing Manager, then run Set-RDLicenseConfiguration with -Mode PerUser and both license servers. Reconnecting users get in immediately. The follow-up matters as much: the farm's planned 2025 session host is put on hold until 2025 CALs are purchased, because the existing 2022 CALs cannot serve it.

Confirm CALs are being issued, and keep it that way

Re-run the diagnoser; it should list no problems. Re-run the WMI block and check LicensingType now reads 2 or 3 instead of 4, and that SpecifiedLSList contains your servers. Then watch RD Licensing Manager over the next few days — issued CAL counts should climb as people sign in. Per device CALs make this visible: the first connection from a device gets a temporary CAL valid for 90 days, and once the license server is activated with CALs available, that becomes a permanent CAL valid for a random 52 to 89 days, renewed when the session host sees it within seven days of expiry. Per user CALs are not enforced and can be over-allocated in breach of the licensing agreement, so track their number in Remote Desktop Licensing Manager rather than trusting that sign-ins keep working.

How this differs from the licensing-mode warning and the security-error variant

If users still connect but see a balloon reading Remote Desktop licensing mode is not configured. Remote Desktop Services will stop working because this computer is past its licensing grace period., you are early: the mode is unset, connections continue for now, and you have time to configure licensing properly rather than at 09:00 on a Monday. The other variant, Access was denied because of a security error., is usually not about CAL availability at all — it tends to be damaged licensing certificates. The documented repair is to back up and then remove the Certificate, X509 Certificate, X509 Certificate ID and X509 Certificate2 values under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM, restart the computer, and reactivate the license server. Export the key first; that instruction is in the support article for a reason.

Next time sessions stop at the licensing message, walk these checks back in order: what the diagnoser says, what GetGracePeriodDays and GetSpecifiedLicenseServerList return, whether the license server is activated with CALs new enough for the host, and only then go looking at the network.