Microsoft's Stupidest Licensing Trick

By Paul DeGroot

One of the most famous computing acronyms is GIGO, which stands for “garbage in, garbage out.” If you enter bad data into your database—some data is missing, entries aren't validated, etc.—queries of that data will not produce accurate results.

Microsoft has decided to put garbage into its licensing database. This is Microsoft's stupidest licensing trick ever.

It was dreamed up by Microsoft's SQL Server licensing team which I nominate as the record holder for jerking customers around on licensing. This team changes rules from version to version, adds restrictions that create major operational overhead for customers, builds bizarre licensing tiers, creates and drops product editions on a whim, and set a new low with SQL Server 2012 and its insanely complicated core conversion rules.

As their reward for all that team's hard work, Microsoft will top it with a change to a critical internal process:

Microsoft has decided to corrupt its licensing database by deliberately failing to record some valid SQL 2012/2014 core licenses.

How is this happening?

By default, Microsoft grants customers four core licenses for every SQL Server Standard or Enterprise processor license covered with Software Assurance (SA) when SQL Server 2012 was released. (SQL Server Datacenter Edition, which existed in only a single SQL Server version, 2008 R2, gets eight cores by default, but we'll use SQL Server Enterprise as our example in this note.)

If the processor license is assigned to a processor with more than that the default number of cores, the conversion rules say the customer is granted licenses not just for the default number, but for all the cores actually in use. For example, if a license is assigned to a 12-core processor, the customer is granted 12 cores rather than four.

Them's the rules. But a breakdown in the process for ensuring that customers are awarded the licenses they have paid for means that the rules aren't applied to customer data in Microsoft's licensing database.

First, Microsoft makes little effort to document how many cores each customer is actually using. It records the default number of cores per processor license in its own records, and if the customer wants credit for any extra cores, the customer must do two things:

1. Run software (such as the Microsoft Assessment and Planning Toolkit, MAP) that can detect all those extra cores and accurately record the customer's SQL Server infrastructure.
2. Renew SA on all the cores.

What happens if the customer does not do both tasks?

Microsoft will enter only the default core entitlement. Since it does not include the customer's actual licensing entitlement, the database is now garbage.

It gets worse. Let's say do task 1. You run the software that counts all the cores your SQL Server is using and you send the data to Microsoft. Now Microsoft has a record of all the extra cores you are entitled to. But let's say you don't take the second (usually very costly) step of renewing SA on ALL of those cores.

Microsoft will ignore the data you supply them. Even though the customer was granted those extra cores, Microsoft will not record them in its database. It will still credit them with only four cores per processor.

This is garbage.

The next time the customer comes up for an audit, Microsoft will look at a server running 12-core processors and say "you owe us a lot of money." The customer had the right to be granted the full 12 cores for each processor, but Microsoft recorded only four.

Now, assuming that the customer actually ran software that counted its cores, it should be able to pull out those records. Those records will show the auditor that the customer did indeed run SQL Server on processors with more than four cores and the customer did have SA on those processors when SQL Server 2012 was released. Therefore, the customer is licensed for those additional cores and does not need to purchase more licenses for them.

Microsoft will insist that its garbaged database is the source of all truth, and a customer that isn't willing to put up a fight will repurchase licenses for cores that it has already licensed.

Corrupting the licensing database isn't mischief enough for the SQL team. They've elected to further punish customers who don't purchase SA on SQL, by making management of SQL cores without SA more difficult.

If a customer is running SQL Server on processors with, for example, eight cores, and they don't continue SA on those additional cores, Microsoft agrees that they have a right to them, but it says those eight cores without SA can never be split up. They must be treated more like a processor license, moved as a block. If you move an eight-core block to a machine with two, four-core processors--eight cores in all—the eight cores can't be split across processors. You'll have to assign the eight core block to one four-core processor and buy four new core licenses for the other processor.

Microsoft calls these "core-equivalent" licenses as in "this block is equivalent to four cores, that one to eight, that one to 12."

I don't believe that this restriction will be a huge problem for most customers. Most will be able to assign these pseudo-processor licenses without a lot of problems.

But let's be clear: this rule has no purpose other than to torture customers who don't have a need for futher immediate SQL Server upgrades. If they pay a ransom (nearly doubling their SQL Server costs over the next three years), Microsoft will let their cores out of core-equivalency jail.

Ironically, Microsoft treats customers who do not buy SA on SQL Server better than those who did. Customers who skipped SA on SQL and now buy core licenses, even without SA, have complete flexibility to move individual core licenses around however they like. So in this case, customer loyalty to Microsoft, as evidenced by previous SA purchases, goes not only unrewarded, but even punished.

If Microsoft wanted to seed serious ill will among its SQL Server customers for the next 3-5 years, it's difficult to imagine more perfect execution than what the company has done with its GIGO policy and core-licenses-that-aren't-really-core-licenses.

In order to protect themselves, customers MUST have a very accurate record of their SQL Server infrastructure at the termination of their agreement. They must record the server names, the processor and core count of each server, and the number and type of processor licenses with SA that were assigned to each server.

Microsoft's MAP tool can do a decent job of collecting all the required data, but customers should not give the raw MAP data to Microsoft. They should store the files in a safe place and print out a report that shows all their SQL production servers (exclude development and fail-over servers, for example) that were covered with SA as of April 1, 2012

They should send it to their Microsoft rep (registered mail with a confirmation receipt would be a good choice) to make sure that Microsoft has, at least theoretically, a record of their correct SQL Server 2012/2014 core count. They should also send a copy to their reseller. And they should distribute it to various people in their organization, such as purchasers, contract managers, SQL DBAs, and the CIO, to make sure that in the event of staff turnover at least one person can put their hands on the REAL core count—not Microsoft's garbage.