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 | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact message, days left, OS versions, broker or standalone, domain or workgroup, who sees it | "RDS licensing is broken" with no server, message, or account |
| 2. What the session host sees | Licensing type is Per User or Per Device, at least one license server listed, grace days read | Licensing type 4 (Not Configured), or an empty license server list |
| 3. Which configuration wins | One source owns the setting, and it's the one you've been editing | Fixed in Server Manager, still broken; gpedit.msc looks fine |
| 4. Reachability | Name resolves, RPC/SMB ports open, connectivity status says the server is valid | "License server is not available" in the diagnoser |
| 5. License server | Service running, server activated, CALs installed | Green check missing in RD Licensing Manager, zero available CALs |
| 6. CAL type and version | CAL type matches the mode; versions compatible | "No Remote Desktop client access licenses available for this computer" |
| 7. Domain, trust, workgroup | Same domain, two-way trust, or same workgroup with credentials in place | Works for one domain's users, not another's; workgroup host refused |
| 8. Event logs | Licensing events read on the license server and session host for the same time | No idea which side refused |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Grace period reset, pop-up back next quarter |
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:
| What users or admins see | What it tells you | Start at |
|---|---|---|
Remote Desktop licensing mode is not configured. Remote Desktop Services will stop working in x days. |
Still inside the grace period. Mode not set, or no reachable license server | Steps 2-4 |
... will stop working because this computer is past its licensing grace period. |
Grace period over. Connections will start failing | Steps 2-4 today |
The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license. |
Past grace, and the session host has no license server it can use | Steps 3-5 |
The remote session was disconnected because there are no Remote Desktop client access licenses available for this computer. |
Microsoft lists it as a licensing-configuration cause. A license server answered but had no suitable CAL (our reading: type, version, or count) | Steps 5-6 |
There is a problem with your Remote Desktop license, and your session will be disconnected in 60 minutes. |
Soft enforcement: introduced in Windows Server 2016 (Per Device) and 2019 (Per User), removed in Windows Server 2022 | Steps 4-5 |
Access was denied because of a security error. / diagnoser shows an X.224 protocol error |
Microsoft ties this to the license certificates on the session host | Step 9 (X509 refresh), only after Steps 2-8 |
Write these on the ticket before anyone changes anything:
| Fact | Why it matters |
|---|---|
| The exact message and the days left | "Stop working in 6 days" is a planned change. "Past its licensing grace period" is an outage |
| Session host OS version | Decides which CAL versions it accepts (Step 6) |
| License server name and OS version | Decides which CAL versions it can hold (Step 6) |
| Broker deployment or standalone session host? | With an RD Connection Broker, Microsoft configures licensing in Server Manager. Without one, "you must specify a license server by using group policy" |
| Domain or workgroup? | Workgroups can only use Per Device CALs (Step 7) |
| Which CAL type was bought | The mode has to match it (Step 6) |
| Who sees it | A local account in Per User mode or an admin session can see the pop-up even when everything is right |
| What changed? | New session host build, OS upgrade, license server moved or rebuilt, new GPO, firewall change |
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:
| Property or method | Value | What Microsoft says it means |
|---|---|---|
LicensingType |
2 |
Per Device |
LicensingType |
3 |
Per User |
LicensingType |
4 |
Not Configured (the state behind this ticket) |
LicensingType |
0 / 1
|
Personal RD Session Host server / Remote Desktop for Administration |
PolicySourceLicensingType |
0 / 1
|
The licensing type was set by the server / by Group Policy |
PolicySourceConfiguredLicenseServers |
0 / 1
|
The license server list was set by the server / by Group Policy |
GetSpecifiedLicenseServerList |
empty | "If there are no license servers, this array will be empty" |
GetGracePeriodDays |
0 |
"A zero value indicates that the grace period is over" |
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,
LicensingType4. 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. -
LicensingType2 or 3, empty server list. The mode is set, but there's nothing to ask for a CAL. Microsoft'sUse 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:
| Source | Where it's stored on the session host | Notes from Microsoft |
|---|---|---|
| Domain GPO |
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services: LicenseServers, LicensingMode
|
Applies before the Server Manager setting. gpedit.msc on the session host doesn't show it |
Local policy (gpedit.msc) |
Same key and values | Applies before the Server Manager setting |
| Server Manager / RDMS (deployment properties on the broker) |
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core: LicensingMode; ...\Services\TermService\Parameters\LicenseServers: SpecifiedLicenseServers
|
"Will have no effect when a local policy is configured." The server-list entry "exists only if you used the Remote Desktop Services console" |
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:
| Setting | What Microsoft's policy text says |
|---|---|
| Use the specified Remote Desktop license servers | The order in which the session host tries license servers. If they can't be found, it tries automatic discovery |
| Set the Remote Desktop licensing mode | Per User or Per Device. "If you disable or don't configure this policy setting, the licensing mode isn't specified at the Group Policy level" |
| Hide notifications about RD Licensing problems that affect the RD Session Host server | When enabled, the licensing notifications "won't be displayed." It hides the warning. It doesn't fix anything |
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):
| Value | Microsoft's meaning | Next |
|---|---|---|
11 |
"The license server is valid" (Windows Server 2012 and later) | Reachability is fine. Go to Step 5 |
6 |
"Remote Desktop Services cannot connect to the license server" | Name, firewall, the service on LIC01 (Steps 4-5) |
5 |
"Security group policy is enabled in license server, but Remote Desktop Services is not a part of the group policy" | The license server only serves listed session hosts (below) |
4 |
Can connect, but "there is an incompatibility between the license server and the Remote Desktop Services host server" | Versions (Step 6) |
8 |
Can connect, "but the user account does not have administrator privileges on the license server" | Our reading: affects what you can query from this account, so re-run as an admin of LIC01 before drawing conclusions |
0 / 7
|
Status can't be determined / validity can't be determined | Read the event logs (Step 8) |
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:
| Check | What Microsoft says | What to look for |
|---|---|---|
| Activated | "Check whether the licensing server is activated." Activation uses Automatic connection (outbound TCP 443 to the Microsoft Clearinghouse), Web Browser, or Telephone | A green check mark beside the server name |
| CALs installed | The license server needs a CAL "for each user and device that can connect to RDS"; the columns "should reflect the numbers of total and available licenses" | The CAL type and version you need, with available count above zero |
| Scope | "Review the configuration to verify that the scope is correct" | Domain vs workgroup scope matches reality |
| AD group | "Make sure that the licensing server is added to the 'Terminal Server License Servers' domain group" | Membership confirmed (below) |
# 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):
| Session host | 2016 CAL | 2019 CAL | 2022 CAL | 2025 CAL |
|---|---|---|---|---|
| Windows Server 2016 | Yes | Yes | Yes | Yes |
| Windows Server 2019 | No | Yes | Yes | Yes |
| Windows Server 2022 | No | No | Yes | Yes |
| Windows Server 2025 | No | No | No | Yes |
License server vs CAL (Microsoft's table):
| License server | 2016 CAL | 2019 CAL | 2022 CAL | 2025 CAL |
|---|---|---|---|---|
| Windows Server 2016 | Yes | No | No | No |
| Windows Server 2019 | Yes | Yes | No | No |
| Windows Server 2022 | Yes | Yes | Yes | No |
| Windows Server 2025 | Yes | Yes | Yes | Yes |
Where it usually goes wrong (our reading of the tables):
| Situation | What happens |
|---|---|
| A new 2025 session host joins a farm licensed with 2022 CALs | The new host has nothing it can use, so its grace period counts down while the old hosts look fine |
| 2025 CALs bought for a 2022 license server | They can't be installed there. The license server has to be 2025 |
| Mode is Per User, only Per Device CALs installed (or the reverse) | The license server has CALs, just not the type the session host asks for |
| Per User mode on workgroup servers | Not permitted. Microsoft: workgroups "have to use Per Device CALs" |
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."
| Layout | What Microsoft requires |
|---|---|
| Same domain | Either CAL type. License server's computer account in Terminal Server License Servers (Step 5) |
| Different domains or forests | A two-way trust (forest or external), the required ports open, and for Per User CALs the license server in Terminal Server License Servers in each users' domain. Configure the license server on every session host, for example through Group Policy |
| Same workgroup | Per Device CALs only. Per User tracking and reporting isn't supported |
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)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Resetting the grace period | Microsoft doesn't recommend it: "you must implement a license server together with a license pack." Nothing about the real fault changes | Steps 2-6, then configure the mode and server |
| Enabling "Hide notifications about RD Licensing problems" | Per Microsoft's policy text, it only stops the notifications. You lose the countdown and keep the fault | Leave notifications on until Step 2 shows a valid mode and server |
| Fixing it in Server Manager while a GPO owns the setting | Microsoft: Group Policy settings override the Server Manager console | Step 3: find the owning GPO and change it there |
| Editing local policy on the session host when a domain GPO sets it | The domain GPO wins, and Microsoft notes gpedit.msc on the session host doesn't show the domain values |
Edit the domain GPO found in gpresult
|
Reading 4 the same way in WMI and the registry |
WMI LicensingType 4 is Not Configured; registry LicensingMode 4 is Per User |
Use the table for the source you're reading (Steps 2-3) |
| Per User mode on workgroup servers | Microsoft: Per User CALs aren't permitted in a workgroup | Per Device in workgroups |
| Buying newer CALs without checking the license server version | CALs only install on a license server of the same version or later | Step 6 tables first |
| Deleting the X509 certificate registry values first | Microsoft reserves that for the security-error / X.224 pattern, with a registry backup first | Only when the diagnoser shows that pattern (Step 9) |
| Turning off workgroup authentication enforcement | Microsoft: "isn't recommended and can result in increased security risks" | Microsoft's cmdkey credential procedure |
Treating mstsc /admin as the fix |
It's a way in for admins, not a licensing fix | Use it to reach the server, then work Steps 2-8 |
| Opening every port between the servers | Fixes reachability by widening the attack surface | Open the documented RD Licensing ports between the session host and the license server only |
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
| Finding | Prefer | Avoid |
|---|---|---|
| License server set by GPO, mode not set | Enable "Set the Remote Desktop licensing mode" in the same GPO | Resetting the grace period |
| Broker deployment, no policy values |
Set-RDLicenseConfiguration (or Server Manager) with mode and server |
Adding a local policy that later fights the deployment |
| Server Manager shows the right values, session host doesn't | Find and fix the GPO that wins | Re-saving deployment properties repeatedly |
| Connectivity status 6 | Name resolution, documented ports, service on LIC01 | Opening all ports between servers |
| Connectivity status 5 | Add the session host to the license server's security group | Disabling the security group policy on the license server |
| Licensing service stopped | Start it, then find out why it stopped | Rebuilding the license server |
| CAL version older than the session host | Buy the right version (and a license server that can hold it) | Pointing the new host at old CALs and hoping |
| Per User mode, workgroup servers | Per Device mode and Per Device CALs | Per User in a workgroup |
| Event 4105 on the license server | Add it to Terminal Server License Servers (plus Network Service on a DC) | Ignoring Per User reporting |
| Workgroup host refused after patching | Microsoft's cmdkey credential procedure |
Turning off authentication enforcement |
| Security error / X.224 in the diagnoser | Microsoft's X509 refresh with a registry backup | Deleting other RCM values |
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:
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.
Top comments (0)