License server doesn’t serve license

Did you know that a Windows2003 Licensing server does not manage Terminal Server ‘Per User’ CALs?

It is really stupid, but from a licensing point of view, a terminal server that is configured to use ‘Per User’ licenses only checks if it can find a license server. As soon as it does, the license server does the Jedi mind trick (These are not the licenses you are looking for...) and the terminal server becomes a free for all, limited only by the maximum number of connections configured by the administrator.

At first I thought this could not possibly be true (noone would design anything that stupid, right?) but this and this quickly convinced me otherwise.
What makes it double stupid is that the license server allows me to add ‘per user’ licenses, and then forces me to go through the whole activation obstacle course, only to ignore whatever licenses were added.

The only way to make sure that our licensing is in order, is to run a nightly script to determine how many TS users we have, and then check if we have enough licenses.
This also means that no matter how many per user licenses you install, they will always show ‘N licenses installed, N available, 0 used’

It has to make business sense

I had just downloaded FreeBSD 7.0 and I wondered if I could use it as a VMWare host. A quick visit to taught me it is not supported. However, a lot of stuff can run on BSD in linux compat mode.

Google pointed me to a VMWare forum where someone had started a thread to ask VMWare to add support for FreeBSD. That thread had received about 100+ replies, in 3 years time. Someone complained that 100 posts over 3 years time should be enough to convince VWMare to do this.

Yeah right.

Let’s look at the math: 100 possible customers for FreeBSD. But a lot of VMWare customers don’t need more than the free version of VMWare server. I use it in our poduction envirnoment as well. I have no need for the ‘for pay’ features. So VMWare doesn’t make money from those people.

Then there are a lot of unix sysadmins which posted that they would like to use BSD, but were using linux because they couldn’t. Supporting BSD would add no value for VMWare, since those admins are already using it, but on another platform. Again VMWare doesn’t make money.

But what does it cost to support BSD?

A lot. Each version of the VMWare product would need to get the same amount of QA testing and analysis. This is horribly expensive for shrink wrapped software which is used in business critical environments. And there is also the cost of maintaining the different code versions.

It will cost VMWare a ton of money to support BSD hosts, at the risk of damaging their name if problems arise, all for maybe a couple of licenses that they would probably have sold anyway, but for a different host.

As much as I would like this, ultimately businesses exist to make money, not to be nice. Being nice is only done when it adds measurable value. IBM does not support linux on their servers because they are nice people. They do it because they sell hardware and servers, and if a large number of important customers demands linux, that is what they will get.

Getting rid of the duplicate SPN in Active Directory

Last week I noticed an error in the domain controller event log with Event ID 11:

Event Type:   Error
Event Source: KDC
Event Category:    None
Event ID: 11
Date:         2/29/2008
Time:         1:43:18 PM
User:         N/A
There are multiple accounts with name MSSQLSvc/ComputerName.DomainName.SysName.Company.Local:1433 of type DS_SERVICE_PRINCIPAL_NAME.
For more information, see Help and Support Center at


The name of the computer in the SPN was one of the process control databases I had replaced earlier. Our process control servers each have a specific role, and their computer names are tied to that role. This is a side effect from the process control system software that we use, and I cannot change this.

This means that the old server and the new server will have the same name.

The process software also doesn’t allow me to change domain membership while the software is installed, and if anything goes wrong with installing and configuring the new server, I should be able to bring the old system back online as soon as possible.

So I simply disconnected it, made the new server with the same name a domain member, installed the application, synchronized everything and the system worked fine. I checked the event log of the new server, but couldn’t see anything suspect. However, looking back through the DC system log, I discovered that the problem started at that exact time.

I did a little bit of research, and I found out that the servicePrincipalName attribute basically tells anyone who wants to know that a service with a certain principal name (duh) is running with the credentials of the Active Directory account with which it is registered.

Since a service with a specific ID can only run with 1 account, having duplicates on the network is bad.

Using ldifde, I found out that the service principal name MSSQLSvc/ComputerName.DomainName.SysName.Company.Local:1433 was linked to the user account ‘XyzAdmin’ and the computer account ‘SE-XYZ01’

Using adsiedit.msc, I had to delete one of the SPNs from its containing account. I checked the service on the SE-XYZ01 server, and the SQL server was configured to run as local service. This means that the correct SPN link is to the server account, and not the XyzAdmin account.

Unfortunately I couldn’t check anymore because the old server was already ‘recycled’ but I seemed to remember that the SQL service was configured to run with the XyzAdmin account instead. When I deleted the link, I wrote an entry in the server logbook, writing down exactly what I removed where, and I also saved the deleted info in a text file ‘just in case’.

From the moment I did this the error did not occur anymore, so I deleted the right SPN. Even if it would have been the wrong one, I could have put it back easily with either setspn, or adsiedit.msc.

I think I will make it part of the server replacement procedure to make an ldifde dump before and after, so that I can more easily diagnose possible problems. I also added a line in my daily backup scripts to make a backup of this dump every night for solving problems like this.

Another thing I thought of later was to make a disk image of the old server that needs to be replaced. That way I can uninstall the application, take the computer out of the domain correctly, and install the new server and still know for certain that if anything goes wrong, I can restore the old system to the exact same state from which I started without having to waste any time with the backup and recovery procedures, which can take a long time for certain servers.

As an afterthought I asked my fellow MVPs what the point was of having SPNs in AD in the first place. After all, if a service runs with certain credentials, it will be authenticated when it starts, so what is the added value of registering that information persistent in AD?

This is what MVP Joe Kaplan had to say:

Kerberos uses SPNs extensively.

When a Kerberos client uses its TGT to request a service ticket for a specific
service, the service is actually identified by its SPN.  The KDC will grant
the client a service ticket that is encrypted in part with a shared secret
that the service account as identified by the AD account that matches the
SPN has (basically the account password).

In the case of a duplicate SPN, what can happen is that the KDC will
generate a service ticket that may be created based on the shared secret of
the wrong account.  Then, when the client provides that ticket to the service
during authentication, the service itself cannot decrypt it and the auth
fails.  The server will typically log an “AP Modified” error and the client
will see a “wrong principal” error code.  I forget the exact error code and
description, but hopefully that’s close enough.  🙂

So, duplicate SPNs are very bad, much in the same way that duplicate UPNs
are bad.  Both can cause Kerb auth to break and Windows uses Kerb for auth
everywhere it can.