Allow log on through Terminal Services

You must install a TS licensing server within 120 days of using Terminal Services on a Windows 2003 server. (This was increased from 90 days with Windows 2000.) If a Windows 2003 Terminal Server cant find a license server after its been used for 120 days, the Terminal Server will refuse connections to clients without valid TS CALs.

Ok, from this point forward, what can I do to get this up and running? I installed the Licensing Server onto this Terminal Server, and activated it online.  If I purchase CALs for this server, will it start accepting connections without the "Allow log on..." errors I was receiving before?

Yep.

Here's an excellent artical on Terminals Services licensing.

http://www.brianmadden.com/content/article/The-Ultimate-Guide-to-Windows-2003-Terminal-Server-Licensing

Some thought should be put into which type of TS CALs you want to purchase, i.e. User TS CALs or Device TS CALs.

Yeah I'd go with the User CALs for what I need.  Anyhow, I need to get this server functioning by tomorrow morning... know of anyone that could provide those CALs to me immediately upon purchase?  I just called CDW and they said the processing probably wouldn't be done until tomorrow.  Any ideas?  Thanks.

I may have remembered incorrectly, but when it says "...you must be granted Allow log on through Terminal Services right..." it usually isn't an issue of licensing.  It usually suggests that the issue has something to do with the permissions getting denied.

I would suggest checking the permissions in the following areas:
1. permissions on the server itself (admin tools -> terminal server connection -> connections -> rdp-tcp properties)
2. double check permissions on the group policy
3. check to make sure the logon credentials you are using are in the appropriate groups for access
4. check to make sure in Active Directory that the server object is in the appropriate organizational unit that has the group policy applied.

And if it is indeed a licensing issue, you can always delete the temporary terminal license that was issue to the workstation used to connect.  This forces the licensing server to give out a new temporary license.  And if it works, then yeah you do have a licensing issue in which purchasing more CALs should fix.  To delete the temporary TS license, you would have to delete a specific registry key.  Use the following kb article for reference.

http://support.microsoft.com/kb/187614/en-us

The key you need to delete:
HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicense

Ok, this has become very strange.  I was searching for CALs to purchase for the last couple of hours.  And I just attempted to log into the server, and now I'm connecting with no issue at all.  I tried the registry entry that 'oversee-andrew' listed above, and it came back something to the effect of entry not found.  But I tried connecting to the server from machines that I couldn't before, and they're all connecting now.  The only thing I did try was installing CALs from someone that I knew had them, but upon entering them into the Licensing Server, they came back that they were already activated.  Other than that nothing has changed.  I have to say though, I'm glad it's working right now, but I'm very uneasy about it staying this way, since I haven't changed much.  Any idea of what is going on here?  I will still purchase the CALs since I know I need them anyway, but it's entirely possible that I install the CALs and this connection problem reappears.

It's possible it took a while to discover the TS licensing server. I've seen that behavior before even with the Licensing server is on the same machine as TS. If you the TS Licensing console you should see temporary license issued.

When I look at the TS Licensing, it shows "Existing Windows 2000 Server - Terminal Services CAL token (per device)," type is "built-in" and total and available are "unlimited" with 0 issued.  I don't see any temporary licenses issued at all.  I have ordered the licenses but have yet to receive them.  As I stated earlier everything started working fine all of a sudden.  About a half hour ago, I tried to logon as Administrator, and received the same, "...you must be granted Allow log on through Terminal Services right..." If I log on as any other user it logs in fine.  Does any of this make sense?  I should note that this is a 2003 Enterprise Server SP2 w/ terminal services running on VMware Server atop SBS 2003 SP2.  This configuration has been working flawlessly for the past four months, up until yesterday of course.

I agree with freefromspam, if you go to the TS Licensing console and see temporary licenses then chances are CALs will help.  Please note that temporary licenses are also issued when there is a mismatch between licensing modes of the TS licensing server and the TS server itself.  For example, if the TS license server is set to "per user" but the TS server is set to "per device" mode.  Ensure that both licensing server and the TS server are on the same licensing modes.

Not sure if this helps, but you can also override the TS license server discovery process and specify which server.  Hope this document helps:
http://support.microsoft.com/kb/279561/en-us

Thanks for the reply.  I don't see any temporary licenses issued under the Licensing.  I do however see that Terminal Services is configured for Per User mode, yet the Licensing lists Per Device mode.  The Licensing however is as I stated earlier for "Existing Windows 2000 Server...," not for anything with 2003.  Again I don't have the licenses to install yet for 2003 Terminal Server, should receive them today or tomorrow hopefully.  I know once I install those that I can configure them for Per User mode.  Do you think the Licensing is still causing me not to be able to logon as Administrator?

For the Administrator account, I still feel that this could be a permissions issue rather than licensing.  Could you go the Terminal Server Configuration to check?  Just in case you need the path... Start->Programs->Admin Tools->Terminal Server Configuration.  Click on Connections.  Right click on RDP-tcp, and go to properties.  Then go to Permissions tab.  Is the Administrator account you were using is listed here?  Or is there a group that is listed that the Administrator is on?  And of course make sure the checkbox to deny permissions isn't checked.

Just checked, Administrator for the domain is listed in there as is Remote Desktop Users, and another Group I specified to have Remote privileges.  There aren't any Deny boxes checked.

Ok, you got me to start going through the Policies.  When I checked the Local Security Policy, and the setting "Allow log on through Terminal Server," Remote Desktop Users was listed there, but no Administrators; somehow I didn't think that Administrators had to be included there.  Anyhow, I couldn't add the users in there since it was being controlled through Group Policy.  So I ran 'gpresult' at the command prompt to see which policies were being applied.  I edited the first policy and it listed Remote Desktop Users, but no Administrators.  I added the Administrator of the domain into this setting, ran a 'gpupdate /force' at the command prompt, and I'm now able to login as the Administrator.  So thank you for leading me down the right path.  Let me ask you, how does this setting get changed?  I almost feel as if someone was playing with the settings, don't get it.

To my knowledge, group policies "shouldn't" change on their own unless a third party program is altering them.  I believe there is a Group Policy Monitoring Tool that is available.  This could probably help you troubleshoot what is changing the settings.

Scroll down to the section for GPMonitor.exe:
http://technet2.microsoft.com/windowsserver/en/library/e926577a-5619-4912-b5d9-e73d4bdc94911033.mspx?mfr=true

Thanks for the suggestion, I'll look into it. Thanks for all of your help.

I had the same problem just now.

I went to Start->Programs->Admin Tools->Terminal Server Configuration. Then to Connections in left pane, (R) click RDP-tcp, then Properties. Clicked on Permissions tab and from there I added <domain name>\Domain Users (you could use any group you want) and granted them User Access.