Survive the “SQL-mageddon”

BrandPost By James Nagurney
Apr 02, 20155 mins

Renew Your Sequel Server EA with Confidence

This month I want to highlight a coming event that some in the industry are calling “SQL-mageddon”. (This specialist tried to suggest “SQL-nado”, but—alas—it did not catch on.) A lot of SQL Server EAs are going to be for renewal soon, and that means you’ll want to take stock of your SQL licensing and compliance. What does this really mean for your organization? Read on for the full story. In February 2012, Microsoft announced that major changes to their SQL Server licensing model would be coming in April 1, 2012. SQL would be changing from a ‘per processor’ model to a ‘per core’ model, and in most cases this would mean a significant price increase. Seeing the coming storm, Microsoft customers scrambled to buy SQL licensing for their larger processors before April 1. Needless to say, March 2012 was a good month for SQL Server EA and EAP sales.

Now as you probably know, EAs are three year agreements, so what does that mean for us today? Over the next 3–4 months we are going to have a CRUSH of customers renewing those EAs from March 2012. Keep in mind that migrating from ‘per processor’ to ‘per core’ model can be very tedious and time consuming, so make sure you do not wait until the last moment. If you are one of these customers, or if you are simply not comfortable with your SQL compliance, here are a few rules you must know:

  • The default number of cores that you will be granted per processor is four. However if your licensed SQL processor has more than 4 cores, you may renew the total number of cores on that processor. (This is considered an SA only grant to cover the additional cores, Microsoft will not require you to purchase the License portion to cover these cores, just the SA according to the Processor type and CORE Factor.)
  • If you choose not to renew your SQL SA, and want to claim the additional cores (above and beyond four), you must run an asset intelligence tool, like the MAP Toolkit, and prove to Microsoft that your processors do in fact have more than four cores. Again, if you choose not to do this, your license grant will be FOUR cores for ONE processor license.
  • For a SQL Standard physical instance, you must license all cores on the box. For a SQL Server virtual instance, you must license all vCPUs that the VM is pulling from.
  • For a SQL Enterprise physical instance, like Standard, you must license all the cores on the box. For a SQL Enterprise virtual instance, you may license at the physical or virtual layer. If you choose to license the physical cores, you may spin up an unlimited number of SQL Standard or Enterprise VM’s on that box. If you license at the virtual level, you must license all vCPU’s on the SQL Server instance.
  • For both physical and virtual instances, you must assign a minimum number of four cores per processor or VM. This applies to both Standard and Enterprise.
  • For SQL VMs in a cluster, Software Assurance is required for license mobility. For instance, if you are actively vMotioning SQL servers between hosts, you will need SA to stay complaint.
  • If you chose to “resurrect” old licenses with Software Assurance only costs you may very well see a cost increase as these unit would be converted to subscription licenses (or repurchase as new). In this circumstance, you will definitely want to engage your software advisor soon in order to sort it all out properly.

These are high level guidelines, and there will always be circumstances where we need to do a deeper dive regarding core factors. Hopefully, at the very least, this gives you some things to watch out for when reviewing your current licensing. Of course, every SQL reconciliation is different from the next, but here are some basic steps that we recommend:

  • Run an asset intelligence tool.
  • Identify all Test/Dev servers. These can typically be excluded provided that all developers touching that server have the appropriate developer licensing like MSDN.
  • Identify all passive failover servers. These can typically be excluded as well. (Until version 2014 came out there was no need to license a second passive server for failover purposes. As of 2014, this right is tied to Software Assurance. Long story short, if you are running version 2014, have active SA, or had active SA when 2014 was released, you need SA on the active node in order to run an unlicensed passive failover server. If you have older servers with legacy 2005, 2008, 2008 R2, or 2012 licensing and no SA, you do not need SA in order to take advantage of this right.)
  • Identify SQL Standard instances supporting SCCM. These can also be excluded as SCCM now includes the rights to run SQL.
  • In an Excel spreadsheet, assign existing processor licenses to remaining production servers. (Easier said than done.)
  • Convert processor licenses to core licenses according to the rules outlined above.
  • Reconcile gaps, if necessary.
  • Renew as needed.

If you are not a SQL expert, and even if you are, this can be a tedious process. Unfortunately, due to the number of variables involved and the complexity of the licensing rules, the methodology above is the only way to ensure compliance. Make sure you are relying on your Microsoft specialists for guidance. If you are in need of a full-blown Software Asset Management (SAM) engagement, we can do that, too.