Terminal Server licensing pitfall

Today I got a phone call from one of the automation engineers, who told me that he couldn't connect to one of the terminal servers anymore.

I set out to investigate, and while verything seemed to be in order, the server management page indicated that the terminal services were not licensed for the offending server. It also said that the evaluation period would end after 120 days, after which it would stop working.

This was odd, because I remember installing the CALs... about 4 months ago when we had to rebuild the network... which is about 120 days approximately. Too much of a coincidence, so I checked the system event log and sure enough there was a message that the grace period had expired. This also told me that the same thing was about to happen for our other terminal servers.

On each of the terminal servers I could open the licensing configuration, and get the error message that no licensing servers were found. I could then manually specify a server name and it would find all licenses, but if I closed it and then opened it again I got the same error. I even got this error on the terminal server that was also acting as a license server, which was ultimate stupidity imo.

 I consulted the Windows 2003 Admin companion, which turned up nothing, and the Windows 2003 help files were equally useless.

Then I found this page:

http://www.microsoft.com/technet/community/en-us/terminal/terminal_faq.mspx
and this one:
http://www.msterminalservices.org/articles/Terminal-Server-License-Service-Discovery-Part1.html

Especially the last one is very useful because it has flowcharts detailing how server discovery works for terminal servers. As it turns out, there are quite a few stupid design decisions in there.

First of all, there is no easy way to manually specify licensing servers. Even the licensing configuration snap in doesn't allow this. You have to configure this in the registry of each individual server.

Secondly, terminal servers don't check if they have a license server running locally. Especially in small networks this will be the case. It would be trivial to implement, and makes life easier for end users.

But thirdly and most importantly, the license server setup itself is braindead. You have the option to choose between enterprise mode and domain or workgroup mode. The former should be for large multidomain enterprises, and the latter for small single domains. When the license server was installed, we chose the latter because we are only running a single domain forest.

Unfortunately, in domain mode, the license server record is only broadcast via active directory if the license server itself is a domain controller. If that's not the case, the license server will just sit there without anyone knowing it's there. Even the local terminal service won't know. With the entrprise license server option this is not an issue, because it will always be discovered, even if it is not running on a domain controller.

So once I figured all this out, it took only 5 minutes to manually configure the extra registry keeps to force the terminal service to look at our licensing server. We still get discovery errors in the event log because the discovery process still runs, and still can't find any license servers despite the fact that it uses that server. The 'manage your server' screen also thinks that we are still running without a license.

For this last thing there is a hotfix, but since that is not approved by the software vendor of our process control software, I decided to ignore these messages and simply put an entry in the logbook to explain what happens.

Another day, another example of the lack of usefulnes of the windows documentation. I think it would have been a good idea to document things like discovery process / configuration implications etc in the documentation, but that's just me of course.