Remote Desktop Licensing Mode Is Not Configured: A Read-First License Server, CAL, and Grace Period Triage

Helpdesk: "Everyone who signs in to RDSH02 gets a pop-up: 'Remote Desktop licensing mode is not configured. Remote Desktop Services will stop working in 6 days.' We bought CALs last year, and LIC01 shows them in the licensing manager. Someone found a registry fix online that resets the 120-day grace period. Can we just run that so the pop-up goes away?"

Don't reset anything yet. "Remote Desktop licensing mode is not configured" means the session host doesn't have a licensing mode and license server it can actually use. Owning CALs isn't the same as having them configured. Microsoft says you get this message when "the licensing mode isn't properly configured in the RDS deployment, or if the RD Session Host can't communicate with the RD license server." Resetting the grace period buys days and changes neither of those. It's one layer in a documented chain: the exact message, days left, and deployment type on the ticket → what the session host actually sees (licensing type, license server list, grace days, and where each value came from) → which configuration wins (domain GPO, local policy, or Server Manager deployment properties) → the session host can reach the license server (name, ports, connectivity status, security group) → the license server is healthy (service running, activated, CALs installed) → the CAL type and version match the mode and the session host → the domain, trust, or workgroup prerequisites are in place → the licensing event logs agree. Win32_TerminalServiceSetting, Get-ItemProperty, gpresult, Get-RDLicenseConfiguration, Test-NetConnection, Get-Service, Get-ADGroupMember, RD Licensing Diagnoser, and Get-WinEvent are the sources for that chain. A grace-period reset makes the pop-up go away. If the real problem was a GPO that sets only the license server, or 2022 CALs in front of a 2025 session host, the same pop-up comes back with a shorter fuse.

If the licensing GPO you set isn't reaching the session host at all, start with Group Policy Not Applying. If the session host is also the source of repeated account lockouts, read Active Directory Account Keeps Getting Locked Out (RDS hosts are a common relay). This post covers "an RD Session Host shows 'Remote Desktop licensing mode is not configured', 'no Remote Desktop License Servers available', or a related licensing message, and you need a read-first path through the session host's effective licensing settings, the policy source, license server reachability, the license server itself, CAL type and version, and the event logs before you reset the grace period, change the mode, edit the registry, or buy more CALs."

TL;DR

• The message is about configuration, not CAL count. Microsoft: it appears when the licensing mode isn't properly configured or the session host can't talk to the license server.
• Group Policy wins. Microsoft: "Settings configured through Group Policy override those configured using the Remote Desktop Services console in Server Manager." A fix made in Server Manager does nothing if a GPO owns the setting.
• The grace period is 120 days, and Microsoft doesn't recommend resetting it. Microsoft: the grace period "can be reset to 120 Days. However, we don't recommended this approach. Instead, you must implement a license server together with a license pack."
• Version matters both ways. CALs must be the same version as the session host or newer, and the license server must be the same version as the CALs or newer.
• Workgroups get Per Device only. Microsoft: "If you use workgroup servers for your RDS deployment, you have to use Per Device CALs."
• The pop-up isn't always a problem. Microsoft: you can get it "even if all the settings are as expected" when you connect with a local account in Per User mode, or with an administrative session.

Where in the chain did it break?

Step 1: Capture the exact message (read-only)

The wording tells you how urgent it is and where to look. Microsoft documents these messages across its RDS licensing articles:

Write these on the ticket before anyone changes anything:

If the grace period is already over and you can't get in, Microsoft's own pages use mstsc.exe /admin to reach a server that "can't contact an RD licensing server" (the mstsc reference: /admin "Connects you to a session for administering the server"). Microsoft's Azure VM article says this "disables licensing for just that connection." It's how you get in to fix the problem. It doesn't fix anything for users.

Step 2: Read what the session host actually sees (read-only)

Microsoft's troubleshooting guidance reads the session host's effective settings with WMI. On the session host, elevated, in Windows PowerShell 5.1:

# Read-only. Microsoft's own check: license servers, licensing type, days left in the grace period
$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.GetSpecifiedLicenseServerList()
$obj.LicensingType
$obj.GetGracePeriodDays()

gwmi is Get-WmiObject, which isn't in PowerShell 7. The same reads with the CIM cmdlets, plus the properties that say where each value came from (our version):

# Read-only. Same reads with CIM, plus the policy-source flags for the mode and the server list
$ts = Get-CimInstance -Namespace 'root/cimv2/TerminalServices' -ClassName Win32_TerminalServiceSetting
$ts | Format-List ServerName, LicensingType, LicensingName, PolicySourceLicensingType, PolicySourceConfiguredLicenseServers
(Invoke-CimMethod -InputObject $ts -MethodName GetSpecifiedLicenseServerList).SpecifiedLSList
(Invoke-CimMethod -InputObject $ts -MethodName GetGracePeriodDays).DaysLeft

The output parameter names (SpecifiedLSList, DaysLeft) come from Microsoft's method reference pages. How to read it, using the Win32_TerminalServiceSetting class reference:

One trap. The WMI LicensingType numbers and the registry LicensingMode numbers (Step 3) don't use the same scale. In WMI, 3 is Per User and 4 is Not Configured. In the registry, Microsoft documents 2 as Per Device and 4 as Per User. Someone who reads 4 in WMI and "fixes" it in the registry, or the other way round, ends up chasing the wrong value.

Two common readings (ours):

• License server listed, LicensingType 4. Someone enabled "Use the specified Remote Desktop license servers" but not "Set the Remote Desktop licensing mode." That's the most direct match for the exact wording.
• LicensingType 2 or 3, empty server list. The mode is set, but there's nothing to ask for a CAL. Microsoft's Use the specified... policy text says that when the specified servers can't be found, the session host falls back to automatic discovery (license servers published in AD DS, then license servers on domain controllers in the same domain). Don't count on discovery.

Step 3: Find which configuration wins (read-only)

Microsoft documents three places the mode and server list can come from, and their order:

Microsoft's registry values for LicensingMode are 2 (Per Device) and 4 (Per User).

# Read-only. Policy values (domain GPO or local policy). If these exist, policy owns the setting
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -ErrorAction SilentlyContinue |
  Select-Object LicenseServers, LicensingMode

# Read-only. Server Manager / RDMS values (only used when no policy is set)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core' -ErrorAction SilentlyContinue |
  Select-Object LicensingMode
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers',
                       'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers\SpecifiedLicenseServers' -ErrorAction SilentlyContinue |
  Select-Object PSPath, SpecifiedLicenseServers

The last read checks two paths on purpose. Microsoft's troubleshooting guidance puts SpecifiedLicenseServers under ...\LicenseServers, and its warning article puts it under ...\LicenseServers\SpecifiedLicenseServers. Read both and use whichever exists.

Then find which GPO sets it. Microsoft's guidance uses gpresult /H:

# Read-only. Elevated on RDSH02: which GPOs applied to the computer, and what they set
gpresult /scope computer /h C:\Temp\RDSH02-gp.html

Open the report and look under Administrative Templates for Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Three settings matter:

On a broker deployment, read the deployment's own view too:

# Read-only. RemoteDesktop module, on or against the broker: the deployment's licensing mode and server list
Get-RDLicenseConfiguration -ConnectionBroker 'RDCB01.corp.contoso.com'

If Get-RDLicenseConfiguration shows the right mode and server but Step 2 shows 4 on the session host, and Step 3 finds a policy value, the policy is winning (our reading of Microsoft's precedence notes). Fix the GPO, not the deployment.

Step 4: Can the session host reach the license server? (read-only)

Microsoft's port reference for the Remote Desktop Licensing service (TermServLicensing): RPC on TCP 135, randomly allocated high TCP ports 49152-65535, NetBIOS on UDP 137 and 138 and TCP 139, and SMB on TCP 445. It "offers its services by using RPC over named pipes" and "has the same firewall requirements as the File and Printer Sharing feature."

# Read-only. From RDSH02: does the name resolve, and are the fixed TCP ports open?
Resolve-DnsName -Name 'LIC01.corp.contoso.com'
Test-NetConnection -ComputerName 'LIC01.corp.contoso.com' -Port 135
Test-NetConnection -ComputerName 'LIC01.corp.contoso.com' -Port 445

TcpTestSucceeded : True on both is a good sign. Test-NetConnection only tests one TCP port at a time, so it can't prove the dynamic RPC range or the UDP ports are open (our note). Then ask Remote Desktop Services itself:

# Read-only. Remote Desktop Services' own verdict on that license server
$ts = Get-CimInstance -Namespace 'root/cimv2/TerminalServices' -ClassName Win32_TerminalServiceSetting
(Invoke-CimMethod -InputObject $ts -MethodName GetTStoLSConnectivityStatus -Arguments @{ ServerName = 'LIC01.corp.contoso.com' }).TStoLSConnectivityStatus

Microsoft's values for GetTStoLSConnectivityStatus (selected):

The license server security group. Microsoft's "License server security group" policy, when applied to a license server, makes it answer only session hosts whose computer accounts are in a local group on the license server. Microsoft's current policy reference calls that group RDS Endpoint Servers. Older Microsoft articles call it Terminal Server Computers. Our reading is that the name depends on the Windows version, so check both on LIC01 before you add anything.

Access this computer from the network. Microsoft's "no license servers available" article also says to check this user right under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment: "Assign this right to Authenticated Users, Domain Computers, or Session Host computer account if Everyone isn't assigned." We read that as applying to the license server, because the session host is the one connecting. Hardening baselines that trim this right are a common culprit in our experience.

Step 5: Read the license server (read-only, on LIC01)

Microsoft's "60 minutes" article: "If the Remote Desktop Licensing service isn't running, the RD Licensing server can't retrieve the client license."

# Read-only. On LIC01: is the Remote Desktop Licensing service running?
Get-Service -Name TermServLicensing | Format-Table Status, StartType, Name, DisplayName -AutoSize

Then open RD Licensing Manager (Server Manager > Tools > Remote Desktop Services > Remote Desktop Licensing Manager) and check what Microsoft lists:

# Read-only. RSAT AD module: is the license server's computer account in the group Per User tracking needs?
Get-ADGroupMember -Identity 'Terminal Server License Servers' | Format-Table Name, objectClass -AutoSize

Why that group matters, from Microsoft's event 4105 article: the license server writes Per User CAL information to user objects in AD DS. If its computer account isn't a member of Terminal Server License Servers in the users' domain, it logs event ID 4105 ("cannot update the license attributes for user ... Win32 error code: 0x80070005"). If the license server is a domain controller, the Network Service account must be a member too, and the licensing service must be restarted afterwards. Microsoft's 4105 article refers to it as BUILTIN\Terminal Server License Servers.

Two Microsoft facts about the CAL types that change how you read the counts:

• Per User: "licensing isn't enforced," Per User CALs "can't be tracked within a workgroup," and they "can be over-allocated, in breach of the Remote Desktop licensing agreement." A Per User deployment can look healthy while being out of compliance. Use RD Licensing Manager reports to track it.
• Per Device: a temporary CAL is issued on a device's first connection and lasts 90 days if no CALs are available. Per Device CALs "can't be over-allocated," and you "can revoke up to 20%" of them.

The session host has its own tool for all of this. Microsoft: open Server Manager and select Tools > Terminal Services > RD Licensing Diagnoser. The top pane lists problems, and the information section gives "possible causes and the steps to follow to remediate it." Microsoft's examples include "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" and "License server 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."

Step 6: CAL type and version (read-only)

Microsoft: "You can't use RDS CALs for earlier versions to access later versions of Windows Server, but you can use later versions of RDS CALs to access earlier versions." And CALs install only on "a license server running the same version of Windows Server as the RDS CALs or later."

Session host vs CAL (Microsoft's table):

License server vs CAL (Microsoft's table):

Where it usually goes wrong (our reading of the tables):

Microsoft's guidance also notes that pointing a Windows Server 2019 session host at a Windows Server 2016 license server "is not supported."

Step 7: Domain, trust, and workgroup prerequisites (read-only)

Microsoft's cross-domain article: for CAL issuance to work, the session host and the license server must be in "the same work group," "the same domain," or "trusted (Two-way trust) Active Directory Domains or Forest."

Workgroups after CVE-2024-38099. Microsoft: "After you apply the security update for CVE-2024-38099, RD licensing servers enforce that RD Session Host servers present nonanonymous credentials when requesting or querying licenses." A workgroup session host that worked for years can stop getting CALs after patching. Microsoft's fix is a dedicated local user on the license server and a stored credential for it on each session host, added as NETWORK SERVICE with cmdkey. It also documents a registry value that turns enforcement off, and warns that this "isn't recommended and can result in increased security risks" and that "future versions of Windows might stop honoring this setting."

Step 8: Read the event logs (read-only)

Microsoft's guidance: on the license server, open Event Viewer and go to Application and Services Logs > Windows > TerminalServices-Licensing > Operational. The Per User group warning (4105) goes to the System log with source Microsoft-Windows-TerminalServices-Licensing.

# Read-only. Find the exact Remote Desktop and licensing log names on this server
Get-WinEvent -ListLog '*TerminalServices*' | Format-Table LogName, RecordCount, IsEnabled -AutoSize

# Read-only. On LIC01: last 7 days of licensing events, and the System-log licensing warnings such as 4105
$since = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-TerminalServices-Licensing/Operational'; StartTime = $since } -ErrorAction SilentlyContinue |
  Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-TerminalServices-Licensing'; StartTime = $since } -ErrorAction SilentlyContinue |
  Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

# Read-only. On RDSH02: licensing-related messages from the Remote Desktop providers in the System log
Get-WinEvent -FilterHashtable @{ LogName = 'System'; StartTime = $since } -ErrorAction SilentlyContinue |
  Where-Object { $_.ProviderName -like '*TerminalServices*' -and $_.Message -match 'licens' } |
  Format-Table TimeCreated, ProviderName, Id, Message -Wrap

The .../Operational log name is how we expect that Event Viewer path to appear to Get-WinEvent (our reading; use whatever -ListLog returned). On the session host we filter by message text instead of event IDs, because we haven't found a Microsoft Learn page that lists the session host's licensing event IDs. Read the license server and the session host for the same minute: one side refusing and the other side never asking are different fixes.

Common false starts (read these before you change anything)

Step 9: Change one layer, then watch (only after the read)

Back up first: export the GPO (or note its current settings) before you edit it, and export any registry key before you touch it. Pick the one change Steps 1-8 point at. Run anything that supports -WhatIf with -WhatIf first, then without.

Broker deployment, no licensing GPO (Step 3 found no policy values):

Set-RDLicenseConfiguration doesn't list -WhatIf on its reference page. Its -Force switch "forces the command to run without asking for user confirmation," so leave -Force off and read the prompt (our reading). To get a dry run anyway, wrap it:

# Change helper (ours). Prints the change under -WhatIf; runs Set-RDLicenseConfiguration only without -WhatIf
function Set-RDLicensingChecked {
  [CmdletBinding(SupportsShouldProcess, ConfirmImpact = 'High')]
  param(
    [Parameter(Mandatory)] [ValidateSet('PerUser', 'PerDevice')] [string] $Mode,
    [Parameter(Mandatory)] [string[]] $LicenseServer,
    [Parameter(Mandatory)] [string] $ConnectionBroker
  )
  if ($PSCmdlet.ShouldProcess($ConnectionBroker, "Set-RDLicenseConfiguration -Mode $Mode -LicenseServer $($LicenseServer -join ',')")) {
    Set-RDLicenseConfiguration -Mode $Mode -LicenseServer $LicenseServer -ConnectionBroker $ConnectionBroker
  }
}

Set-RDLicensingChecked -Mode PerUser -LicenseServer 'LIC01.corp.contoso.com' -ConnectionBroker 'RDCB01.corp.contoso.com' -WhatIf

The parameters and the PerUser / PerDevice values are from Microsoft's Set-RDLicenseConfiguration page (its accepted values also include NotConfigured, which you don't want here). The Server Manager equivalent is Remote Desktop Services > Overview > Tasks > Edit Deployment Properties > RD Licensing.

GPO-managed or standalone session host (no broker):

Edit the GPO that gpresult named in Step 3. If there's no broker and no GPO yet, Microsoft's procedure uses a domain GPO that targets the session hosts or the Local Group Policy Editor. Under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing, enable both:

• Use the specified Remote Desktop license servers: the license server name ("If you have more than one license server, use commas to separate their names").
• Set the Remote Desktop licensing mode: Per Device or Per User, matching the CALs you installed.

# Change (on RDSH02, after the GPO edit). Pull computer policy now instead of waiting for the refresh
gpupdate /target:computer /force

Then re-run Step 2. If WMI still shows the old values after policy has applied, we restart the session host in a maintenance window (our practice; it logs off users).

License server fixes (on LIC01 or with RSAT):

# Change (on LIC01). Remote Desktop Licensing service stopped
Start-Service -Name TermServLicensing -WhatIf

# Change (RSAT AD, delegated rights). License server missing from the group Per User tracking needs
Add-ADGroupMember -Identity 'Terminal Server License Servers' -Members 'LIC01$' -WhatIf

# If LIC01 is a domain controller: Microsoft also adds Network Service to the group, then restarts the service
Restart-Service -Name TermServLicensing -WhatIf

Start-Service, Restart-Service, and Add-ADGroupMember all support -WhatIf and -Confirm. Not activated, or no CALs of the right type and version: use RD Licensing Manager's Activate Server and Install Licenses wizards. Microsoft's install wizard asks for "the license code or an agreement number," depending on your license program. That's the licensing owner's job, not a helpdesk change.

Reachability fixes: open the documented RD Licensing ports between the session host and the license server, restore Access this computer from the network if a baseline removed it, or add the session host's computer account to the license server's security group (Step 4). Change one, then re-run GetTStoLSConnectivityStatus until it returns 11.

License certificate refresh (only for the security-error / X.224 pattern):

Microsoft's procedure, on each session host: back up HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM, delete the values Certificate, X509 Certificate, X509 Certificate ID, and X509 Certificate2, restart the computer, and reactivate the RD Licensing server. The PowerShell form below is ours:

# Change (on each affected session host). 1) Back up the key, as Microsoft's article does
reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM" C:\Temp\exported-Certificate.reg

# 2) Remove the four values. -WhatIf lists exactly what would go
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM' -Name 'Certificate', 'X509 Certificate', 'X509 Certificate ID', 'X509 Certificate2' -WhatIf

Then restart in a window and follow Microsoft's reactivation step. Keep the .reg export until users connect cleanly.

Workgroup credentials after CVE-2024-38099: follow Microsoft's procedure (dedicated user on the license server, cmdkey /add run as NETWORK SERVICE on each session host). Don't use the enforcement-off registry value as the fix.

Read-only confirm afterwards:

$ts = Get-CimInstance -Namespace 'root/cimv2/TerminalServices' -ClassName Win32_TerminalServiceSetting
$ts | Format-List LicensingType, PolicySourceLicensingType, PolicySourceConfiguredLicenseServers
(Invoke-CimMethod -InputObject $ts -MethodName GetSpecifiedLicenseServerList).SpecifiedLSList
(Invoke-CimMethod -InputObject $ts -MethodName GetTStoLSConnectivityStatus -Arguments @{ ServerName = 'LIC01.corp.contoso.com' }).TStoLSConnectivityStatus

Watch one full cycle: RD Licensing Diagnoser shows no problems, LicensingType is 2 or 3, connectivity status is 11, a test domain user (not an admin session or a local account) signs in without the pop-up, and RD Licensing Manager shows CALs being issued for Per Device, or reportable for Per User.

When a change is justified

FAQ

What does "Remote Desktop licensing mode is not configured" mean?
The RD Session Host doesn't have a licensing mode (Per User or Per Device) it can use, or it can't reach the license server it was given. Microsoft lists both causes. Read the session host's effective settings with Win32_TerminalServiceSetting (a LicensingType of 4 means Not Configured), find which source sets them with gpresult, and check that the license server answers before you change anything.

How do I set the licensing mode without an RD Connection Broker?
Use Group Policy. Microsoft's procedure: under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing, enable both "Use the specified Remote Desktop license servers" (your license server's name) and "Set the Remote Desktop licensing mode" (Per User or Per Device, matching your CALs). Do it in a domain GPO that targets the session hosts or in local policy.

Can I reset the 120-day RDS grace period?
Microsoft says the grace period can be reset, but it doesn't recommend it: "you must implement a license server together with a license pack." A reset changes nothing about the missing mode, the unreachable server, or the wrong CALs, so the same message comes back.

Why does the warning still appear after I set the mode in Server Manager?
Usually because Group Policy sets the licensing values and overrides the Server Manager console, or the session host still can't reach the license server. Microsoft also notes the pop-up can appear even when everything is right if you connect with a local account in Per User mode or with an administrative session. Test with a normal domain user.

How do I get in when it says there are no Remote Desktop License Servers available?
Connect with mstsc /admin. Microsoft's Azure VM article says it "disables licensing for just that connection," and its session host licensing page uses mstsc.exe /admin to reach servers that can't contact a license server. Then configure the license server and mode. If the server never needs more than two simultaneous connections, Microsoft's Azure article suggests removing the Remote Desktop Session Host role instead.

Related posts

• Group Policy Not Applying (when the licensing GPO from Step 3 never reaches the session host)
• Active Directory Account Keeps Getting Locked Out (RDS hosts with disconnected sessions and stale credentials are a classic lockout source)
• Trust Relationship Between This Workstation and the Primary Domain Failed (if the session host itself has lost its secure channel, licensing is the least of its problems)

Free checklist

RDS licensing tickets often come up when a farm is being rebuilt or moved toward cloud desktops. When that move puts Entra sign-in and Conditional Access in front of your users, the policy itself becomes the next thing that can lock everyone out. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=rds-licensing-mode-not-configured

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=rds-licensing-mode-not-configured

Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: Win32_TerminalServiceSetting reads and its Get methods, Get-ItemProperty, gpresult, Get-RDLicenseConfiguration, Resolve-DnsName, Test-NetConnection, Get-Service, Get-ADGroupMember, RD Licensing Diagnoser, RD Licensing Manager (viewing), and Get-WinEvent. Changing the licensing mode or license servers, editing GPOs, starting or restarting services, changing group membership, activating the license server or installing CALs, opening firewall ports, storing credentials, and removing registry values are deliberate changes. Back up first, change one layer at a time, test with a normal domain user, and check current Microsoft Learn and your license terms for version-specific behavior.