I've found myself in the same scenario as you. Deploying Remote Desktop on a standalone Server 2012 box is quite hard, because the guys at Microsoft don't let you run this on a domain-less network and if you do, you can't manage all the settings.

So, you can install a workgroup-based-box and get the Remote Desktop roles working on it. We need also to install Remote Desktop Licensing features on the same machine. But, once at this point, even if you have proper RDS CALs installed on the server, when the user logs in, receives the message that the trial period is on.

I've finally managed to get it working, at least something like the good-old Terminal Services we used to know. That's working for me on two production machines of small clients who need RDS but can't afford having two servers on their network.

Here we go:

1. Install the Remote Desktop Licensing and the Remote Desktop Session Host role services using the following steps:

   • Open Server Manager
   • Click on Manage and select Add Roles and Features
   • Select Role-based or Feature-based installation
   • Under Remote Desktop Services, choose Remote Desktop Licensing and Remote Desktop Session Host role services.
   • Proceed with installation

2. Add the License Server to Terminal Server License Servers group and restart the Remote Desktop service (you can use licmgr.exe)

3. Add the licenses to the license server.

4. Configure the Remote Desktop Session Host role with to use the local Remote Desktop Licensing server. Follow these steps:

   • Open PowerShell as administrator
   • Type the following command on the PS prompt and press Enter:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting

Run the following command to set the licensing mode (Note: Value = 2 for Per device, Value = 4 for Per User, we use per-user)

$obj.ChangeMode(4)

Run the following command to replace the machine name with License Server (mylicenseserver is the name of your server):

$obj.SetSpecifiedLicenseServerList("mylicenseserver")

Run the following command to verify the settings that are configured using above mentioned steps:

$obj.GetSpecifiedLicenseServerList()

You should see the server name in the output.

Once done this, reboot the system and log in with any user (if using a workgroup, you know your users must be part of the Remote Desktop Users) and the trial period message will dissapear.

Source of all this mess: http://support.microsoft.com/kb/2833839

Managing with Powershell

There are a few things you can manage with Powershell. To see the commands try:

import-module RemoteDesktop get-command -module RemoteDesktop

There is a list of commands you can execute via Powershell to manage your box. However, I've tried a few but some of them require you to have some extra features installed, that can't be deployed on the scenario we are talking about.

The ugly way

If none of the above works for you, there is a way to reset the grace period to the initial 120 days. Of course, I don't recommend doing this, as the user will keep noticing the message. Of course, you'll need to purchase proper licenses.

To reset the counter, just delete this registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Grace Period

Of course, you'll need extra-privileges to do that, executing regedit as administrator will not work. Try this:

• Get PSEXEC
• Start a cmd as administrator
• run psexec -s -i regedit.exe
• delete the desired key
• reboot

Hope some of this works for you. If you do some advances with Powershell and RDS, let us know.

Turns out it was an extra privilege that was on the new box that needed to be disabled and then Task Scheduler runs fine. "SeDelegateSessionUserImpersonatePrivilege" was the culprit.

What caused me to believe it was the task scheduler is that the task scheduler has changed how it saves the user in the Xml and it used to save it as “DOMAIN\USER” but now it saves it as a SID (security id) and doesn’t display the domain portion in the ‘RUN AS’ section of the task scheduler.

When I ran whoami /all I saw that one privilege was on the new box but not the old box.

That privilege was: SeDelegateSessionUserImpersonatePrivilege = disabled

Removing this privilege fixes the issue.

So on Windows Server 2016 std build 14393 enabling or removing the privilege SeDelegateSessionUserImpersonatePrivilege fixes this issue of Tasks not running as the stored user in Task Scheduler.

EDIT: Windows Server 2016 Task Scheduler runs correctly tasks that were set up right the first time with no edits and that had the checkbox ‘Run with highest privileges’ unchecked and starting in the future. So if you need to modify a scheduled tasks you should probably create a brand new task then delete the old one rather than edit an existing task.