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 or reporting.
Microsoft has decided to put garbage into its licensing database. This is Microsoft’s stupidest licensing trick ever. Who will pay for it? Customers. Of course.
This trick was dreamed up by Microsoft’s SQL Server licensing team. No product team at Microsoft has caused more confusion and heartburn than the SQL team, constantly changing rules from version to version, adding restrictions that create operational overhead for customers, creating bizarre tiers of core and CAL licensing, creating and dropping product editions on a whim, and setting a new low with SQL Server 2012 and its insanely complicated core conversion rules. Then, SQL 2014 continues this legacy by removing yet more product rights (backups) and making them a “Software Assurance Benefit”. (Because that’s what you, the customer, told them you wanted. Huh?)
Garbage In – Microsoft SQL Server Licensing
As their reward for all that 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 / SQL 2014 core licenses.
How is this happening?
By default, Microsoft grants customers four core licenses for every SQL Server processor license covered with Software Assurance (SA) as of April 1, 2012, when SQL Server 2012 was released. However, if the license is assigned to a processor with more than four cores, the customer can be granted licenses for all the cores actually in use. For example, if a license is assigned to an eight-core processor, the customer is granted eight cores rather than four.
Customers must document the core configuration of all processors running SQL Server in order to get licenses for these additional cores.
If, however, the customer does not renew Software Assurance on all of the cores that Microsoft granted, Microsoft will record only four of those cores in its licensing database.
In other words, unless you pay Microsoft another 75% of the license cost over the next three years (the cost of SA), Microsoft willfully “forgets” you have extra core licenses.
Got that? Because Microsoft has not kept a record of all the licenses it has granted customers, it will see a shortage where there is none. In an audit or a true-up, Microsoft will demand that the customer purchase four additional core licenses to legally license the processor, since its records show the customer has licensed only four of the eight cores. It will be up to the customer to prove Microsoft wrong by producing evidence that they actually earned eight core licenses in the conversion.
The Processor/Core Monster
This isn’t enough for the SQL team, however. They’ve elected to punish customers who don’t purchase SA on SQL further, by making management of SQL cores without Software Assurance almost impossible.
The conversion rules say that those eight cores without SA can never be split up. They must be treated more like a processor license, moved as a block. So a customer may have some cores that can be moved anywhere—those with SA—and some that can’t. 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 cores to one four-core processor and buy four new core licenses for the other processor.
(Ironically, Microsoft treats customers who did not buy Software Assurance on SQL Server better than those who did. Customers who skipped SA on SQL and now buy core licenses have complete flexibility to move individual core licenses around however they like. Once again, customer loyalty to Microsoft 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 Software Assurance that were assigned to each server.
Microsoft’s Microsoft Assessment and Planning (MAP) tool can do a decent job of collecting all this data, but customers should not give the raw MAP data to Microsoft. Companies should store the MAP inventory 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) covered with Software Assurance.
Companies should also 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 SQL Server 2012/2014 core count. While you’re at it, send a copy to your reseller of record. And, 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 garbaged version.
What if you don’t do this?
The ramifications could be severe. Every year, sales teams at Microsoft are expected to grow their territories ON AVERAGE about 22%. That’s serious revenue growth expectations. And, if you didn’t document these SQL Servers and record your ACTUAL cores per processor in production, expect that in 1-2 years, Microsoft WILL audit you, and without this proof, Microsoft will use the inaccurate core count that it has defaulted (4 cores). Without this documentation, a single 2 proc X 10 core SQL Enterprise Server will leave you woefully short on cores (Microsoft defaulted you to 2 X 4 = 8 cores), but their audit showed you running 20! That’s 12 short so pay up! And these aren’t cheap. These 12 cores will cost you $1,800 a piece, making that single server shortfall about $22,000. How many SQL servers do you have again? Ten, you say? More? Well, thank you Mr. Customer from your Microsoft account team — they just figured out how they’re going to make that 22% growth this year from you.