Windows RDS CAL Diagnostics: License Servers, Modes, and Version Compatibility

Remote Desktop Services (RDS) licensing failures are often reported as connection, grace-period, or “no license server available” errors, but those messages can originate at different stages. The RD Session Host applies a licensing mode and identifies a license server; that server must be installed and activated, have compatible RDS client access licenses (CALs), be reachable from the host, and be used in a deployment that matches the organization’s licensing terms. A warning can also be caused by policy precedence, workgroup restrictions, a stopped service, name resolution, firewall rules, or CAL/server version incompatibility. Diagnose each layer before changing registry values or resetting a grace period.

This runbook concerns the technical operation of the RD Licensing role and CAL issuance. It does not determine whether a specific agreement, hosting model, user, device, or workload is legally licensed. Confirm entitlement, CAL type, transfer rights, and current licensing terms with the organization’s licensing administrator or Microsoft licensing channel. Do not infer license rights from an RD Licensing Manager count, a successful test sign-in, or the number of concurrent sessions.

Separate licensing components and symptoms

The RD Session Host hosts session-based desktops or applications. The RD Licensing server installs, tracks, and issues RDS CALs. In a deployment with an RD Connection Broker, deployment-level licensing settings are configured through Server Manager on the broker. A standalone or workgroup RD Session Host without a broker uses Group Policy to specify the license server and licensing mode. A Remote Desktop client or RD Gateway can participate in the connection path, but neither configures the session host’s CAL policy.

Record the affected session host, Windows Server release and build, broker membership, license server name and OS version, CAL pack version and type, licensing mode, domain/workgroup state, user/device identity, exact error, and UTC timestamp. State whether the error affects all hosts or only one collection, one broker, one network segment, one user group, or one device class. A single affected host suggests local policy, DNS, firewall, or service differences; a fleet-wide issue can implicate the shared license server, CAL pool, domain policy, or a recent infrastructure change.

Do not conflate RDS CALs with Windows Server CALs or a Windows client remote-administration session. The license requirements and enforcement behavior differ by product and use case. Administrative sessions may produce licensing messages under conditions that do not indicate that a regular user session is correctly licensed. Establish whether the user is connecting to a configured RD Session Host workload or using a supported administrative connection before treating a balloon as proof of CAL exhaustion.

Check the license server and installed CAL inventory

On the designated license server, open Remote Desktop Licensing Manager and verify that the server is activated, the expected license packs are installed, the counts and type match the approved deployment, and the server is within the correct scope. Confirm the Remote Desktop Licensing role service and licensing tools are installed on the intended server. If CALs were recently added or migrated, confirm the installation completed and that the correct agreement/program, product version, CAL type, and quantity were selected. Do not install a second pack to “fix” a display issue before reconciling the purchase, activation, and license-server record.

The issuing server needs a CAL version compatible with the RD Session Host it serves, and the license server itself must be a compatible Windows Server version for that CAL pack. Compatibility is directional: newer CALs can cover earlier session hosts in the documented matrix, while older CALs cannot license later Windows Server releases. For the documented versions, a Windows Server 2025 CAL can serve 2025 hosts, while a 2022 CAL cannot serve a 2025 host. Verify both matrices, not just whether the server appears in the console. When migrating or consolidating license servers, plan CAL transfer and activation separately from session-host configuration.

The license server may have Active Directory discovery or explicit configuration depending on the deployment. Check whether the server is activated and discoverable in its intended domain or forest scope. For multi-domain, forest, or workgroup designs, review the documented scope and trust requirements; do not assume a server visible in one domain is automatically discoverable or reachable from every RD Session Host. If a server was renamed, moved, restored, or rejoined to a domain, verify its service registration and published identity after the change.

Inspect effective session-host configuration

RD Connection Broker deployments use the deployment properties for licensing mode and license-server list. When a deployment has only the RD Session Host and licensing roles, the corresponding Group Policy settings are under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Local or domain Group Policy can override settings configured in the Server Manager console; therefore inspect resultant policy, not just the value someone remembers setting in the GUI. Verify the license server’s fully qualified name, spelling, DNS resolution, and intended failover list against the actual host configuration.

On a session host, the documented Win32_TerminalServiceSetting WMI class exposes the specified license-server list and licensing type. The following read-only query reports the current values and method status; run it in an appropriately privileged Windows PowerShell session on the RD Session Host:

$setting = Get-CimInstance -Namespace 'Root/CIMV2/TerminalServices' `
    -ClassName 'Win32_TerminalServiceSetting'

$setting | Select-Object LicensingType,
    PolicySourceLicensingType,
    PolicySourceConfiguredLicenseServers

$serverList = Invoke-CimMethod -InputObject $setting `
    -MethodName 'GetSpecifiedLicenseServerList'

[pscustomobject]@{
    ReturnValue = $serverList.ReturnValue
    SpecifiedLicenseServers = $serverList.SpecifiedLSList -join ', '
}

For the Win32_TerminalServiceSetting.LicensingType WMI property, Microsoft documents 2 as Per Device and 3 as Per User; 4 means Not Configured for that property. Do not confuse these WMI values with other licensing registry or unattend-setting enumerations. The method’s return value is important: do not interpret an empty output list without checking whether the query succeeded. The policy-source properties help identify whether Group Policy or local/server configuration supplied the value. Compare the result with gpresult /h or Resultant Set of Policy, and inspect the appropriate registry locations only as supporting evidence. Registry edits are not the first diagnostic step and can be overwritten by policy refresh.

If you need to change configuration, use the supported management surface for that deployment and document the mode, server list, scope, owner, and rollback plan. Set the two licensing policies together when a standalone session host is managed through policy. For a broker-managed deployment, update deployment properties instead of independently editing each host. After a policy change, refresh policy in a controlled window and verify the effective result on each host; do not assume that clicking Apply on one console changed every server in a collection.

Choose Per User or Per Device deliberately

Per Device CALs are assigned to devices and are tracked by the license server. Per User CALs are assigned to users, generally in Active Directory, and the license server’s tracking behavior differs. Select the mode according to the deployment’s authorization model and agreement rather than whichever option makes a warning disappear. If the deployment’s servers are in a workgroup, Microsoft documents that Per Device CALs are required; Per User CALs are not permitted for that scenario. Domain-joined deployments can use either mode when the licensing agreement and operational design support it.

The user/device choice affects pool accounting and support investigations. In a shared-device environment with shift workers, per-device assignment can align with the access pattern. For a user population that connects from multiple personal devices, a per-user model may be a better technical fit, subject to agreement terms. Per User CAL enforcement and reporting are not equivalent to a strict per-device limit; do not treat a count shown as available as proof that every actual user is covered. Maintain an authoritative entitlement ledger and reconcile it with license-server reports.

Record exceptions such as workgroup hosts, cross-forest licensing, hosted service-provider environments, and administrative sessions. These cases can have distinct rules and restrictions. RDS Subscriber Access Licenses (SALs) in a service-provider model are not simply another name for customer-owned RDS CALs; follow the applicable provider agreement. Escalate legal or commercial ambiguity to the licensing owner instead of embedding an assumption in a technical runbook.

Verify activation, reachability, and host access

From each affected RD Session Host, resolve the configured license-server FQDN and check the route, firewall policy, and service state. Avoid testing connectivity by opening broad firewall rules or disabling Windows Firewall. Determine which RDS licensing ports and dependencies are required for the deployed Windows versions, then allow them only between the appropriate session-host and license-server addresses. TCP 3389 is the user session transport; it is not a substitute for the licensing server communication path. A successful user RDP handshake therefore does not demonstrate that licensing RPC or licensing services are reachable.

Use Test-NetConnection only as a narrow TCP check where the documented service path uses a known TCP endpoint; it does not prove that all licensing RPC flows, service permissions, or CAL operations succeed. Compare host firewall and network firewall telemetry at the failure time. Check whether the Remote Desktop Licensing service is running and whether its event channels show service startup, activation, or CAL issuance errors. Confirm that server-side access policy permits the RD Session Host to contact the license server. In a workgroup design, the security update and explicit credential configuration requirements may differ from a domain-joined environment; follow Microsoft’s current workgroup guidance rather than granting broad anonymous network access.

RD Licensing Diagnoser is a focused tool available from Server Manager > Tools > Terminal Services. Run it on the affected RD Session Host with an account that can query the license server. Read the detected condition, the server selected, the licensing mode, CAL availability, and version warnings as separate findings. A Diagnoser access error can mean the diagnostic account lacks permission to query licensing state; it does not by itself prove that end users lack CALs. Do not add a diagnostic account to Domain Admins to make the query succeed. Grant only the documented administrative access on the licensing server or have an authorized administrator collect the evidence.

Correlate event records and grace-period state

Use the RD Licensing event channels on both session hosts and license servers to establish what happened when a connection failed. In Event Viewer, inspect Applications and Services Logs > Microsoft > Windows > TerminalServices-Licensing, including the Operational channel when enabled. Correlate events with Security and System logs, the broker, domain controllers, DNS, firewall records, and the user’s connection time. Preserve event ID, provider, message, activity data, server name, user/device, and UTC timestamps; a generic “license unavailable” screenshot loses the evidence needed to identify the failing hop.

The built-in RDS licensing grace period is 120 days for a newly created RD Session Host, after which a valid CAL must be issued for client connections. This timer is not a purchased license, a renewal mechanism, or a production workaround. Do not reset the grace period to extend service or delete licensing registry data without an approved Microsoft support procedure and a verified backup. A warning during the grace period can be a prompt to complete deployment rather than evidence that every connection is already blocked. A host past the grace period with missing or unreachable licensing configuration can deny connections.

Microsoft documents a read-only WMI method to query remaining grace-period days. If your troubleshooting requires it, call GetGracePeriodDays and record the output with the host’s build and time. Do not run undocumented registry deletion or modification procedures from forum posts; those can affect licensing state and complicate support. Focus on making the license server, mode, CAL type, and policy effective before the grace period ends.

Validate version compatibility before migration

Use the current Microsoft CAL compatibility tables for both the RD Session Host version and the RD License Server version. The session-host table answers whether a particular CAL pack can cover the host release. The license-server table answers whether the license server OS can install and issue that pack. A current license server may accept older CAL packs while an older server may reject newer ones; the two directions are not interchangeable. Record the exact Windows Server release for all three components rather than relying on “supported Windows Server” as a generic statement.

Before an in-place upgrade or license-server migration, inventory installed CAL packs, activation state, server scope, host configuration, domain memberships, DNS names, and contractual entitlements. Confirm how CALs will be migrated or reinstalled using the supported license-program process, and retain access to the prior server until the new service is validated. Do not copy license database files or registry keys between servers as a substitute for the documented migration process. After cutover, run Diagnoser on representative hosts from each collection and verify that the intended licensing server is selected.

A bounded RDS licensing incident workflow

Identify the affected hosts, users/devices, exact error text, connection type, deployment roles, and UTC time range.
Run RD Licensing Diagnoser on one affected host; save its findings and distinguish query-permission errors from actual CAL or connectivity findings.
Verify the license server role, activation, installed CAL packs, server scope, service state, and CAL counts in Licensing Manager.
Query Win32_TerminalServiceSetting, check method return values, inspect effective policy, and confirm the correct server list and licensing type.
Validate CAL type and both version-compatibility relationships: CAL to session host, and CAL to license server.
Test name resolution, route, firewall dependencies, licensing service, group/workgroup prerequisites, and any change in network or identity state.
Correlate licensing events, host System/Security logs, broker state, and network telemetry. Make one scoped change and repeat the same test with a representative user/device.
Reconcile technical state with the authoritative licensing entitlement record; document any business or contract issue for the licensing owner.

Keep the remediation narrow. If policy points to the wrong server, fix the authoritative GPO or broker deployment configuration rather than every local registry value. If the CAL pack is incompatible, plan a valid CAL/server upgrade instead of repeatedly restarting TermService. If the network path is blocked, add only the required licensing rule between approved hosts. If Diagnoser cannot query because of access rights, obtain evidence through an authorized administrator rather than broadening privileges.

RDS CAL diagnostics become reliable when the session-host policy, license-server service, activated CAL inventory, protocol path, and deployment scope are treated as separate pieces of evidence. Preserve the error and configuration state before changing it, use supported licensing tools and policy, and involve the organization’s licensing owner whenever technical counters cannot establish entitlement.

Related:

Sources: