How to reset the 120-day RDS grace period on Windows Server 2016 without GUI

Introduction 

Sometimes, guys running home labs do not have licenses for Remote Desktop Services (RDS). Well, that’s not a big deal, you know, because Microsoft provides the 120-day grace period for the platform! However, one day the time runs out and RDS server breaks all the client connections. That day, admins are to choose between reinstalling the server and cheating a bit to reset the 120-day RDS grace period. Well, guys who run testing environments and home labs sometimes choose the second option. At this point, I’d like to say that I neither support nor promote illegal use of Microsoft’s software for commercial purposes with this article! You know, Microsoft themselves provide the script to restore the grace period: https://gallery.technet.microsoft.com/scriptcenter/Reset-Terminal-Server-RDS-44922d91 . Well, I did not try that script myself, but I believe it should work. There are some ways to reset the grace period through GUI. You can google a bit and find many of them! But, in this article, I teach you how to reset the grace period with PowerShell and Command Prompt. As I did not find a ready-to-go solution, everything I write here is something I came up with based on my own experience with a tiny portion of googling, of course 😊. Note that the method I describe here is pretty risky as you will acquire system level privileges. In other words, you may mess things up fairly easy. On the other hand, you can reset the grace period faster than through GUI! Anyway, I warned you about the risk, so do not play around with the registry a lot! And, not blame me if something goes wrong.

Tools 

For this article, I use a physical server with Windows Server 2016 SE v10.0.14393 and RDS enabled. A virtual server works well too, but I use here the physical one. I use Evaluation OS edition for this article. And, as any guy with an Evaluation edition, I do care today about the grace period! As for RDS platform, I believe you already know what that thing is and how to use it. So, I won’t talk about it here. The trick I describe in this article works good for Windows Server 2016, 2012 R2, and even 2008 R2. For resetting the period, you need the PsExec utility. PsExec is Windows Sysinternals package component that provides you with system level privileges. Why do you need that thing? You see, Windows Server does not have the native means to reset the Period. This means that admin’s privileges won’t be enough to reset the grace period. Here, PsExec comes into the play calling a PowerShell instance that has the system level privileges. Download the utility here: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec. Afterward, extract it somewhere. In my case, the utility is kept in C:\PSTools\.

Resetting RDS grace period 

How many time RDS has? 

Open Command Prompt first and navigate to the PsExec folder. Run the following cmdlets to ensure that the utility is in the folder and is ready to start:

Note that there are both 32-bit (PsExec) and 64-bit (PsExec64) PsExec versions in the folder. I use the 32-bit one in this article. As I said above, you don’t need to re-install the OS to reset the grace period. You just need to find in the registry the “timebomb” – the parameter that contains the piece of code for the countdown. Once that countdown variable value hits 0, RDS server stops serving the client connections. If you want to check how many days you still can use RDS, deploy this command:

In my case, this command worked out only for Windows Server 2016. For Windows Server 2012 R2 and Windows Server 2008 R2, I wasn’t able to find the cmdlet allowing you to do the same thing.

Let’s defuse the “timebomb”! 

Start the PowerShell instance through PsExec with the command below. Look, Windows does not have the native tools to acquire the system level privileges. And, you won’t be able to play around with registry having administrator’s privileges. Here, PsExec comes into the play providing you with the system level privileges!

If you start the utility for the first time, you need to accept the license agreement. Once you press Agree, another PowerShell window emerges. I do everything I describe below in that window.

Run the following cmdlet to get the grace period parameter value in the registry:

There’s a small thing that I’d like you to know about the syntax. For all the commands listed below in this article, do not forget to write all the spaces in directory names between the single quotes. For example, look carefully one more time at how I wrote the Terminal Server directory name in the cmdlet above. See, that’s what I’m talking about! Without those single quotes, you’ll face an error. Now, let’s look through the Get-Item output. See, the GracePeriod variable exists. Let’s look at how you get rid of it. As the current PowerShell instance has the system level privileges, you can delete the variable from the registry fairly easy. Use the following command for removing the variable:

Look at the cmdlet above one more time. See that * at the end of the line? I use it as the grace period variable name depends on the OS. That symbol helps to refer to the variable by the right name. Sure, you can deploy the Get-Item command to acquire the real name, but if you are as lazy as me, just use * 😊. The last but not the least, remember about single quotes in the Terminal Server directory name!

Make sure that you reset the grace period 

Congratulations, once the Remove-ItemProperty cmdlet is deployed, the grace period is reset!

Now, that’s time to reboot the server. You can use this cmdlet:

See, there are no variables in the GracePeriod registry branch. Once you reboot the server, the L$RTMTIMEBOMB_* variable is created again. Now, let’s check whether the grace period has been reset. Do that just in the same way you did it at the beginning:

See, there RDS has 120 days left again!

Conclusion 

Today, I described how to reset the RDS grace period. The nice thing is that you do not need GUI to have the job done! Everything I did in this article works fine for not only Windows Server 2016 but also old Windows Server 2012 R2 and Windows Server 2008 R2. The wmic cmdlet works only for Windows Server 2016, but that’s not the thing one should really worry about. Again, the workaround described here should be used only in the test and home-lab environments. Never use it for production environments! I believe that you have them covered with a proper license, don’t you?