When the Remote Desktop Services (RDS) role is enabled in Windows Server environments, Microsoft automatically provides system administrators with a 120-day grace period (unlicensed usage period) in order to offer a certain level of flexibility during the initial setup phase.
During this period, remote desktop connections will generally continue to function even if no RDS License Server has yet been defined in the environment. This structure is especially useful in initial installation, testing, proof-of-concept (PoC), or temporary deployment scenarios.
However, this temporary convenience is often overlooked. Since the system works without issue in the early days, it is assumed that the licensing infrastructure will be completed later. But when this process is postponed, very serious access problems may arise at the end of the 120-day period.
Especially in production environments, this can result in users being unable to connect to the system, sessions being disconnected, and access to critical applications being interrupted.
What Is the Grace Period and Why Does It Exist?
When the RDS role is installed, Windows Server provides a transition period to prevent the service from being completely blocked even if a license server has not yet been configured.
During this 120-day period:
- RDS sessions can be opened,
- remote desktop connections are accepted,
- the system does not strictly enforce license validation,
- the licensing side of the infrastructure can be completed later.
This approach gives IT teams time, especially during the installation phase. In many organizations, preparing the license server, assigning CALs, determining the licensing mode, and completing Group Policy settings are handled as separate project steps.
However, the critical point here is this: the grace period is a tolerance mechanism, not a permanent unlicensed usage model. Once the period expires, the system exits its normal operating mode and starts actively expecting licensing components.
Why Does the 120-Day Period End?
In fact, the reason this period ends is quite simple: Windows Server does not allow the RDS service to run indefinitely without licensing. The counter starts from the moment of installation, and at the end of this period the system expects the following checks to be satisfied:
- Has a valid Remote Desktop License Server been configured?
- Which licensing mode is the server operating in?
(Per User or Per Device) - Have the relevant RDS CALs been installed?
- Can the RD Session Host access the license server?
- Have the relevant GPO or manual configurations been applied correctly?
If none of these checks have been completed, once the grace period ends the system will no longer evaluate connections under “temporary tolerance.” As a result, the RDS role moves into mandatory license validation mode.
What Happens When the Grace Period Expires?
Once the 120-day period ends, the RDS infrastructure begins to behave more strictly in terms of licensing. At this point, if there is no license server in the environment, if it has not been defined, or if it has been configured incorrectly, the following symptoms may occur:
New RDP connections fail
When users attempt to establish a remote desktop connection, they may be unable to sign in. Even if the connection request is initially accepted, it may be rejected during the license validation stage.
Existing sessions become unstable
In some scenarios, active user sessions may drop, or users may encounter problems during reconnection. This can mean serious disruption, especially for users accessing critical business applications through terminal services.
The RD Session Host may become inaccessible
Even though the server may technically still be running, RDS access can become unusable due to missing license validation on the service side. This creates a misleading situation for system administrators: “the server is up, but users cannot connect.”
Licensing errors appear in the event logs
Error records related to TerminalServices will appear in Event Viewer. Issues such as being unable to reach the license server, missing licensing mode configuration, or CAL validation problems can be monitored here.
In short, the expiration of the grace period does not merely mean “another warning appears”; it can directly turn into an operational problem that affects service continuity.
What Are the Root Causes of the Problem?
The issues experienced after the grace period ends are generally caused by the following:
The license server was never installed
This is the most common scenario. RDS was installed, users connected for weeks or even months, but the license server was never put into operation.
The license server was installed but not defined
In some environments, the RDS License Server is installed, but that server has not been explicitly specified on the RD Session Host side. In this case, the service cannot use the license server.
The wrong licensing mode was selected
There are two main licensing modes in RDS environments: Per User and Per Device. If the licensing model in the infrastructure does not match the configuration on the server, validation issues can occur.
Network or firewall access problems
Even if the license server exists, communication between the RD Session Host and the license server may be blocked due to firewall rules, DNS errors, or network segmentation.
CALs were not installed or licensing was configured incompletely
Even if the license server is up and running, if the relevant CALs have not been installed or activation has not been completed, the environment may appear functional but licensing is still not considered complete.
Temporary Solution: Can the Grace Period Be Reset Through the Registry?
Yes. Especially in lab, test, isolated demo, or short-term validation environments, the grace period information can be reset through the registry. The key generally used for this is located here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
When this entry is attempted to be deleted directly, it will often hit an access restriction. The reason is that the key is kept under a high protection level by default. Therefore, the process consists of several steps:
- First, ownership of the relevant registry key is taken,
- then full permissions are granted to the Administrators group,
- after that, the key is deleted,
- finally, the server is restarted.
When the server starts again, the grace period counter may be recreated, and the environment may temporarily begin accepting connections again.
However, a very important line must be drawn clearly here: this method is not a permanent solution. Technically, it only buys time. Especially in production systems, proceeding with registry manipulation instead of proper licensing is not a correct approach from either an operational or a compliance perspective.
To Perform These Operations with PowerShell
# Check the current license configuration
Get-RDLicenseConfiguration
# Define the license server and licensing mode with PowerShell
Set-RDLicenseConfiguration -LicenseServer "RDS-LIC01.contoso.local" -Mode PerUser
# For device-based licensing
Set-RDLicenseConfiguration -LicenseServer "RDS-LIC01.contoso.local" -Mode PerDevice
# Verify again
Get-RDLicenseConfiguration
# Check whether the licensing role is installed
Get-WindowsFeature RDS-Licensing
# If it is not installed
Install-WindowsFeature RDS-Licensing -IncludeManagementTools
# Check whether the license setting has been applied by GPO/registry
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "LicensingMode"
Get-ChildItem "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers"
# If you defined the license server via GPO
gpupdate /force
Restart-Service TermService -ForceWrite-Host "=== RDS Licensing Check ===" -ForegroundColor Cyan
Write-Host "`n[1] RDS Licensing feature status"
Get-WindowsFeature RDS-Licensing | Select-Object DisplayName, Name, InstallState
Write-Host "`n[2] Deployment license configuration"
try {
Get-RDLicenseConfiguration | Format-List *
}
catch {
Write-Warning "Get-RDLicenseConfiguration did not run. This server may not be part of an RDS deployment."
}
Write-Host "`n[3] Policy registry check"
$tsPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
if (Test-Path $tsPath) {
Get-ItemProperty $tsPath | Format-List *
} else {
Write-Warning "Terminal Services policy registry key was not found."
}
Write-Host "`n[4] LicenseServers subkey"
$licSrvPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers"
if (Test-Path $licSrvPath) {
Get-ChildItem $licSrvPath | Select-Object PSChildName
} else {
Write-Warning "LicenseServers key was not found."
}Why Is This Method Not Suitable for Production?
Resetting the grace period through the registry may resolve the access problem in the short term; however, this approach has serious drawbacks in production environments.
First, this method does not eliminate the licensing requirement; it only postpones it. In other words, the same problem will appear again after a certain period.
Second, this intervention is contrary to corporate standards and licensing management discipline. Especially in audited environments, it is not acceptable to maintain the licensing infrastructure through manual temporary interventions.
Third, it creates operational risk. When the system administrator changes, documentation is missing, or behavior differs after a restart, the issue may become more complex. In other words, while it may provide immediate relief, it creates long-term technical debt.
What Is the Correct Approach for Production Environments?
The correct action to take in a production environment is clear: RDS licensing must be completed fully and through supported methods.
1. An RDS License Server must be installed
The first step is to install the licensing role on a suitable Windows Server. This server may be dedicated, or it may be positioned within the existing infrastructure depending on the design.
2. The license server must be activated
Installing the role alone is not enough. The license server must be activated with Microsoft and brought into an operational state.
3. CALs must be installed
The purchased RDS CAL licenses, according to the organization’s licensing model, must be installed on the server.
4. The correct licensing mode must be selected
Depending on the infrastructure design, one of the following modes must be chosen:
- Per User
- Per Device
The appropriate one must be determined, and the RD Session Host must be configured accordingly.
5. The RD Session Host must be directed to the license server
This can be done centrally through the GUI, PowerShell, or most commonly through Group Policy. In particular, the following settings must be explicitly configured:
- “Set the Remote Desktop licensing mode”
- “Use the specified Remote Desktop license servers”
If these configurations are missing, the environment may not function properly even if the license server is installed.
6. Access and communication checks must be performed
DNS resolution, firewall rules, service accessibility, and event log checks must all be completed. Because just as important as the existence of the license server is the RD Session Host’s ability to reach it.
Why Is Proactive Monitoring Operationally Essential?
At first glance, the RDS grace period may seem like a minor detail. This is because the system usually works without issue for 120 days, creating the perception within teams that “there is no problem for now.” But that is exactly why it is dangerous. The problem approaches silently and is often only noticed when users can no longer connect.
In corporate IT operations, such time-based tolerance mechanisms must always be monitored proactively. In particular, the following checks should be carried out regularly:
- the licensing status of newly installed RDS servers,
- what stage the grace period is currently at,
- whether the license server has been defined,
- CAL installation status,
- licensing warnings in the event logs,
- GPO application status.
Failing to carry out these checks can cause a small installation deficiency to turn into a major service outage.
Script Link: https://github.com/velikadirkozan/RDS-Grace-Period-Reset