So the other day I was trying to connect to one of the terminal servers that I manage (for the purpose of this post, we’ll call the server ‘TERMSVR01’) and I got the following error message and was promptly disconnected:
At first glance, this seems as though the server ran out of TS CALS (Terminal Server Client Access Licenses). I was pretty sure that the server was configured to use the “Per User” licensing mode. However, a Windows Server 2003 Terminal Server operating in the “Per User” licensing mode can’t run out of licenses to the extent that it prevents the user from connecting (and instead, giving them the aforementioned error message). To the best of my knowledge, it can only do this when it is operating in “Per Device” mode. So this was the assumption that I ran with — that somehow, this server was never configured for “Per User” -or- it was, but the setting was either changed, reset, or corrupted somehow.
So, even though I wasn’t able to connect to TERMSVR01 via Remote Desktop, I was able to “Manage” it remotely by doing the following:
- Open “Active Directory Users and Computers” on any Domain Controller
- Expand the “Computers” node
- Right-click TERMSVR01 and select ‘Manage’
Now we can do a few things (not many) on the server. One thing I wanted was to have a look at the Event Viewer. There were a few error messages like the following:
Event Source: TermService
Event Category: None
Event ID: 1004
Time: 6:18:23 PM
The terminal server cannot issue a client license. It was unable to issue the license due to a changed (mismatched) client license, insufficient memory, or an internal error. Further details for this problem may have been reported at the client’s computer.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The more of these I saw, the more confident I was that my assumption was correct — the server was operating in “Per Device” mode and it had finally run out of licenses. I had the following options:
- Wait for someone to go onsite and reconfigure the licensing mode (easy, but it would have to wait until tomorrow) or…
- Attempt to reconfigure this setting and restart the service remotely (so that the setting takes takes effect) … all without having “Remote Desktop” access to the server.
Care to guess which option I chose? :-)
Step #1: Override the licensing mode setting using group policy
- Click ‘Start’
- Click ‘Run’
- Type the following command:
- Click ‘OK’
Those four steps open the group policy (remotely) for TERMSVR01. Next we need to actually change the setting:
- In the left-hand panel, expand “Administrative Templates”
- Expand “Windows Components”
- Click on “Terminal Services”
- Locate the following setting in the right-hand panel:
Set the Terminal Server licensing mode
- Double-click the aforementioned setting
- Change the option (directly below the heading) to “Enabled”
- Select “Per User” from the drop-down box (below the heading: “Specify the licensing mode for the terminal server”.)
- Click ‘OK’
- Close the “Group Policy Object Editor” window
Great. The licensing mode has been changed but the setting won’t take effect until the service is restarted. We could open ‘services.msc’ and connect to ‘TERMSVR01’ by using the ‘Connect to another computer …’ option in the ‘Action’ menu. This will allow us to administer almost all running services on TERMSVR01 … almost all. You’ll notice immediately that you cannot start/stop the ‘Terminal Services’ service from this management console, so we need to find another way to do it.
The easiest way I know to accomplish this task is to use the WMIC command from the command prompt.
Step #2: Restart a remote service using WMIC
- Open a command prompt
- Type the following command (then hit enter) to stop the service:
wmic /node:TERMSVR01 service where “caption=’Terminal Services'” call StopService
- Then, type the following command to start the service:
wmic /node:TERMSVR01 service where “caption=’Terminal Services'” call StartService
- Close the command prompt
If everything was successful (and my assumption about the nature of the problem was correct), then I should be able to connect to the server using the Remote Desktop client. I fired up the client and voilà! It worked perfectly.