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:

and this one:

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.

LINQ To SQL……Server 2005

I am programming a small application for our finance department, for which I wanted to use LINQ for performing the data access, using Visual Studio 2008 Professional.

Unfortunately -and no thanks to MSDN- I found out that currently there is only support for SQL Server 200x, and preferably SQL server 2005, and not every version of SQL Server 2005 at that.

Finance uses MS Access 2003. They already use the database, and it has some exotic connection to MFGPro, involving terminal windows and an FTP connection. So I am not going to move their stuff over to SQL Server 2005 at the moment because the app and the database have to work by the end of the year.

I really think this should have been documented properly. It seems that Microsoft does not want to outright say that they dropped Access from the supported databases list for LINQ. You can’t even find a ‘supported databases’ list on the LINQ home page. According to a forum post by a Microsoft Employee, dropping Access was not a technical problem, but a matter of scheduling and other external factors. Yaaay.

But for now it might as well be named ‘LINQ To SQL Server 2005’. I am curious if they will add support for Access later on. I wouldn’t hold my breath though.

Back to ADO.NET for now, I guess.

Group Policy gotchas


Yesterday I discovered 2 Group Policy gotchas the hard way.Since these things are not written down anywhere, I figured I’d post them on my blog.Note that I am not an enterprise level systems administrator. I am a systems administrator for a single forest single trees single domain network. As such, whatever is a good solution for me might possible not be a good solution at the enterprise level.

Default ‘apply’ permission for authenticated users

Whenever you create a new policy object, it’s ACL will have the ‘Apply’ permission set for all authenticated users.This seems innocuous enough, since you change it anyway when you configure the policy permissions as required. Except that this has a side effect.


Suppose you create a new policy object, configure it (which might take time) and then only change the permissions afterwards. What happens? If someone refreshes its policy settings or applies them before you had the chance to change the security, the policy gets applied without regard for which targets it was really meant.


What is especially insidious in this scenario is that a Domain Controller refreshes its policies every 5 minutes. If the policy contains only user settings this might not be a problem, but in my case the policy contained settings to disable all external mass storage…Goodbye USB, goodbye CDRom…


What’s even nastier is that afterwards there is no visible trace that this has happened. The Resultant Set of Policy clearly shows (afterwards) that the policy is not in effect on the DC, so why-oh-why doesn’t it see its external mass storage anymore…


The moral of the story: whenever you create a new policy object, either make sure that it is not applied to anyone before you configure the policy settings. Or configure the security settings first so that it only gets applied to the correct targets.

Persistent results of previous policies

Another beginner mistake is failing to realize that sometimes the results of a policy application are permanent.For example, if you create a policy to force some values for certain registry keys, those keys will keep their value even if the policy is removed.


This will leave computers in a state that is not logically consistent with their Resultant Set of Policy, because 2 computers with the same set of applicable policies could end up with different configurations.


One way to achieve this is to have 2 policies: One policy to enable a configuration change, and another to reverse or disable the change when it is not needed anymore. In the group policy list, you can then apply the ‘undo’ policy first to all computers, and then apply the ‘do’ policy afterwards to the required computers.


Another way would be to have 2 security groups so that all computers or users are members of just one of them. Apply the ‘do’ policy to the first group and the ‘undo’ policy to the second group. By moving computers from group to group you can then either apply or negate the policies.


The moral of the story: In order to ensure consistency and to make your life easier, you should have some mechanism to revert the results of a policy with persistent results.

Disabling mass storage in a Windows network environment

One of the issues involved in running a pharmaceutical process network is that QA has to give its blessing to the network to allow your company to produce meds. For example, QA has to be convinced that all actions are auditable, that people don’t have more rights than they should…One of the other things is that it should not be possible for users to copy data from the network, or put data on local computers. To achieve this, I needed to disable mass storage (floppy, CD, USB) on all computers that aer accessible by non-administrators. Lucky for me, there are only a handful of computers that are outside of a security controlled environment.I wanted to solve this with Group Policy to make it easy to modify

I also found 2 gotchas that you might want to avoid.

The first thing you need to do is to create a new policy using the administrative template described in this KB article, and then configure the correct settings to disable specific mass storage devices.

This alone is not enough, since it only works for devices that were already on the system when the policy was applied. If a user plugs in a new USB disk, the policy will be overridden and overwritten by the system.

To prevent that, you have to add a registry key to the registry security settings, and then set the permission for ‘SYSTEM’ and ‘domain\users’ to ‘Deny full control’

This will prevent the system and the user from accessing the USB mass storage driver when a new device is plugged in.

And because these changes persist even if the Group Policy is lifted, you need to make a second policy to undo these changes.