How to Refresh an RDP Trial License: What You Need to Know

Remote Desktop Protocol (RDP) is a core Windows feature that lets users connect to a remote machine over a network. When organizations deploy Remote Desktop Services (RDS) — formerly Terminal Services — Microsoft requires valid Client Access Licenses (CALs) for each user or device connecting to the server. Without them, the server runs on a grace period. Understanding how that grace period works, and what "refreshing" it actually means, is essential before taking any action.

What Is the RDP Trial License Grace Period?

When you install the Remote Desktop Session Host (RDSH) role on a Windows Server, Microsoft grants a 120-day grace period. During this window, the server allows RDP connections without requiring fully activated RDS CALs. This is intended to give administrators time to purchase and deploy proper licensing — not as a permanent workaround.

Once the 120 days expire, the server stops accepting connections from users who don't have a valid CAL assigned. At that point, only the built-in Administrator account can still connect directly.

Key facts about the grace period:

• It applies per server installation, not per user
• The countdown begins when the RDSH role is first activated
• The timer is stored in the Windows Registry and tied to the server's licensing configuration
• It does not reset automatically with Windows Updates or reboots

Why People Look for Ways to "Refresh" the Trial

Administrators managing lab environments, test servers, or small-scale setups sometimes seek ways to extend or reset the grace period rather than purchasing CALs. This is a common point of confusion: the grace period exists for evaluation and transition purposes only. Microsoft's licensing terms explicitly require CALs for production use of Remote Desktop Services beyond the grace period.

That said, there are legitimate scenarios where understanding the reset mechanism matters:

• Freshly built lab servers where the OS was cloned or improperly provisioned
• Development or testing environments not in production
• Troubleshooting a licensing configuration that didn't deploy correctly

How the Grace Period Timer Is Stored 🔧

The RDS grace period countdown is stored in a specific location in the Windows Registry:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerRCMGracePeriod 

This key holds an encrypted timestamp that Windows uses to calculate remaining trial days. The key is protected by system-level permissions, meaning even administrators cannot modify it directly without taking ownership of the key first.

Some administrators have used the following general approach in test environments:

1. Take ownership of the GracePeriod registry key using regedit or the subinacl tool
2. Grant administrator-level permissions to the key
3. Delete the key entirely
4. Restart the Remote Desktop Licensing service or reboot the server

After deletion, Windows regenerates the key and restarts the 120-day countdown.

Important: This approach works at a technical level in non-production environments, but it does not constitute a legal license reset. It does not grant any new licensing rights under Microsoft's terms.

Variables That Affect Your Situation

Not every setup behaves the same way, and several factors determine what approach is appropriate:

Proper Licensing vs. Trial Extension: The Real Difference

There are two meaningfully different paths here, and they lead to very different outcomes:

Path 1 — Purchasing RDS CALs: You acquire the appropriate number of Per User or Per Device CALs from Microsoft or a licensed reseller, install an RD License Server, activate it, and assign CALs. This is the supported, permanent solution for any production environment. The 120-day grace period becomes irrelevant once licensing is properly configured.

Path 2 — Registry-based reset: In isolated test or lab environments, deleting the GracePeriod registry key restarts the countdown. This is sometimes used by IT professionals maintaining non-production servers. It carries no licensing rights and, depending on your organization's agreements, may conflict with Microsoft's terms of use.

What Differs Between Server Versions 🖥️

Behavior around the grace period has shifted across Windows Server releases:

• Windows Server 2008 R2 and earlier: Grace period reset via registry was more straightforward
• Windows Server 2012 and later: The GracePeriod key uses stronger encryption and tighter permissions, requiring ownership transfer before any changes
• Windows Server 2019/2022: Some administrators report that the registry method behaves inconsistently, and Microsoft has made incremental changes to how licensing state is validated

If you're working on an older server, the process may be simpler. On newer builds, the steps involve more permission management and may require command-line tools like psexec or PowerShell with elevated privileges to take ownership of protected keys.

What Determines the Right Move for Your Setup

Whether you need to understand the registry mechanism for a lab rebuild, troubleshoot a licensing server misconfiguration, or properly deploy CALs for a growing team — the right path forward depends entirely on the specifics of your environment. The server version, your domain setup, the number of concurrent users, and whether this is a production or test machine all push the answer in different directions. The technical mechanism is the same across scenarios; what changes is whether using it fits your situation legally and operationally.