The ultimate guide to Microsoft SQL Server licensing

 In Microsoft, Software, Volume Licensing

Microsoft’s grant program for SQL licensing expires on April 1, 2015. If you haven’t taken advantage of the grant’s offer of free per-core licensing, it’s time to determine if you’re eligible and act.

This offer and deadline are just one piece of a larger update to the way organizations license Microsoft SQL Server. While the new rules were enacted with the release of SQL Server 2012, many organizations are still trying to understand what these changes mean for them.

To help you better understand these agreements, we’ve written a primer explaining the main ways SQL is licensed, and the many other factors you have to consider when determining your licensing requirements.

Maze

A shift to per-core licensing

Microsoft adjusted its SQL licensing rules when it released SQL Server 2012, and these updates are reflected in the three main editions of SQL Server — Enterprise, Business Intelligence (BI), and Standard. At the same time, Microsoft did away with the processor license model that reigned for years and paved the way for per-core licensing.

There are still two ways to license SQL Server: the Server/CAL model and core-based licensing. The Server/CAL model is still alive and well, but Microsoft removed Enterprise as an option from this model. They did “replace” that edition with SQL Server BI, but the drawback is that SQL BI is only available in the Server/CAL model.

What this means for customers across the globe is that moving forward, the only way to license SQL Enterprise is to purchase cores. While Enterprise is core only and BI is Server/CAL only, the good news is that Standard is available in both Server/CAL and core based.

How these changes affect virtualization rights

Organizations licensed through the Server/CAL and Standard Core licensing models must license each virtual machine (VM) individually. Organizations that have SQL Standard with core-based licensing are required to license four cores per VM, at the minimum.

With Enterprise, it gets a little tricky. Organizations have the option to license all physical cores to get unlimited VM rights with SQL, but in order to have this right, they must have active Software Assurance (SA), and the right is only good while the SA is active.

If there is no active SA attached to SQL Enterprise, and all physical cores are licensed, then organizations can run SQL in a number of VMs equal to the number of physical cores.

What about License Mobility?

License Mobility is an SA benefit that allows SQL to migrate from host to host as needed, without the typical 90 day rule, and can be applied either of two ways.

Licensing individual VMs with SA allows the use of License Mobility with each of those licenses. The only way to get License Mobility when all physical cores are licensed with SA is to license more than one host. In other words, organizations can either license individual VMs and move them around as needed, or license multiple hosts with Enterprise Core with SA and only have SQL running on those hosts.

There’s always a breakeven point between the number of VMs, hosts, and cores all predicated on which version of SQL needs to be running. But remember that moving SQL through VMs requires Windows Server to be licensed as Windows Server Datacenter.

Datacenter allows for unlimited OSs per licensed host, but doesn’t have mobility rights. Mobility rights are bypassed because organizations can run any number of VMs and it doesn’t matter where the VM sits as long as each host is licensed with Windows Server Datacenter.

What the changes mean for SA renewals, other restrictions

For organizations with locked in pricing on an Enterprise Agreement (EA) for SQL Enterprise Server/CAL, the license can be renewed as SA only, but organizations can’t purchase new licenses after the third-year true up and the renewal is processed. Organizations have the right to install SQL Enterprise 2012 and 2014, but because this edition is end-of-life, Microsoft has placed a 20-core limit hardcoded in the software when you upgrade from Windows Server 2008 R2. This is per physical host, and thus prevents the stacking of licenses to get more core usage. These changes will affect most customers on the physical side, and will create a natural need to migrate to core-based Enterprise.

In the SQL Server Core model, both Standard and Enterprise have a minimum consumption rate of four cores, either per physical processor or per VM. While this will rarely affect users on the physical front, it will impact the virtual world. Organizations with less than four cores assigned to a VM still must assign those four cores to that VM.

For customers renewing SA from the processor model, Microsoft is providing four free cores per license. But what if an organization has more than four cores per processor license? This is where the Microsoft Assessment and Planning (MAP) Toolkit comes into play; by scanning the IT environment, MAP provides the details of each SQL install. By using MAP, organizations reduce the risk of an audit. While there’s no guarantees customers will avoid an audit, having and keeping open dialogue with Microsoft is the best prevention.

Licensing SQL can be difficult to understand, and the process for renewing SA with SQL can be arduous at best, so it’s always better to start the process early and get ahead of the curve. Talk to your SHI Account Executive to get the help you need to demystify SQL licensing.

Related Posts: You may also be interested in...


Showing 9 comments
  • Marek
    Reply

    Hi,

    great short article. However, there is still one question I need an answer. Do I still need Windows Server CALs when I chose SQL CAL or Core license?

    M.

    • Michael Stack
      Reply

      Great question! Windows Server CALs are always required regardless of SQL licensing structure. Windows Server CALs act as the foundation for all other CALs required and are required for access to anything on a Windows Server, including DBs and applications. Without Windows Server CALs as the foundation, fundamentally, you would not be licensed correctly. Hope that helps!

  • Suruj Dutta
    Reply

    Very helpful article, thanks.

    Question: For an org with Server / CAL-based SQL Enterprise, does this mean buying SA and deploying in a virtualised environment is an option for an (effectively) per-VM licensing model?

    Or would a 4-core VM still incur 4x SQL Enterprise Core license costs + SA?

    • Michael Stack
      Reply

      Keep in mind that Server/CAL Enterprise hasn’t been available for 4 years, but if you are licensing per VM, then you would have a 1:1 relationship between licenses owned and VMs. The other thing to note that 2008R2 Enterprise did not have SA as a requirement for mobility within a server farm. SQL Enterprise Server/CAL 2008R2 is still governed by the 2008R2 Product Use Rights and if assigned to the physical hardware, allows for 4 VMs per license on the licensed host. Read the below from the licensing brief:

      Moving Running Instances of SQL Server 2008R2 Enterprise Under Server/CAL Model You may move running instances as needed across the server farm as long as the number of servers on which you are running instances of the software does not exceed the number of licenses assigned to the server farm.

      If you license with the Core model, because of changes made 4 years ago and subsequently when 2014 launched, each VM requires a minimum of 4 cores and SA for mobility rights if licensing individual VMs. Each SKU of Enterprise covers 2 cores.

      • Pankaj Malik
        Reply

        Thanks for sharing great information with us, however can you please tell me when did License Mobility become SA benefit for SQL Server? and was it available with SA for SQL Server 2008/2008 R2 Enterprise and Standard as well?

        • Michael Stack
          Reply

          License Mobility became an SA Benefit with the release of SQL Server 2012 on April 1, 2012. License Mobility was not an SA benefit with SQL 2008R2, but was available for SQL Server Enterprise and DataCenter. Please see the below from the SQL Server 2008R2 licensing guide.

          Moving Running Instances of SQL Server 2008 R2 Enterprise Under Server/CAL Model:
          You may move licensed instances as needed across the server farm as long as the number of servers on which you are running instances of the software does not exceed the number of licenses assigned to the server farm.

          Moving Running Instances Under Per Processor Model:
          • SQL Server 2008 R2 Datacenter: You may run unlimited instances of the software in an unlimited number of OSEs within the server farm, and move those instances as needed, as long as the number of physical processors supporting or used by the OSEs in which the software is running at any one time does not exceed the number of licenses assigned to the server farm.
          • SQL Server 2008 R2 Enterprise: You may run unlimited instances of the software in up to four (4) OSEs per license within the server farm, and move those instances freely, as long as the number of physical processors supporting or used by the OSEs in which the software is running at any one time does not exceed the number of licenses assigned to the server farm.

  • LicConfused
    Reply

    Hi,

    thank you for your post. One question, what about licensing per instance? So, i have a licence for standard edition 2012 and installed it on server named SQLSRV1. What if I add an instance SQLSRV1\TEST and SQLSRV1\DEV. Are new licenses needed? Thanks.

    • Michael Stack
      Reply

      When you look at the Product Terms for SQL, you are allowed to deploy an unlimited number of instances within a licensed operating system. You don’t license each instance; rather, you license each operating system in which you deploy SQL. You simply purchase either a single Server/CAL model server license or the appropriate number of cores to cover either physical or logical cores, depending on whether it’s a physical or virtual OS, per operating system it’s deployed in. Keep in mind there is a 4 core minimum per physical socket and per VM, regardless of whether you have less than 4 cores per socket or less than 4 logical cores assigned to a VM (when using core model).


      I would be mindful however, that dev and test can’t be deployed on a production host. Those instances would be covered with an MSDN license (per developer) and should always be deployed within a segregated dev environment not connected to a production database, DR servers, backup servers, or servers rotated into production. Hope that helps.

  • Joe
    Reply

    Hi,

    Thank you for the great article. From what I gather, if we don’t have SA, then we can’t simply assign an ENT license in the server+CAL model (without SA) just to cover for a VM from Host A to B to C (all in less than 90 days)? Said VM is currently licensed with SQL STD in the server+CAL model (without SA)?

    We can’t consider it as “Okay it moved hosts so it ‘lost’ its existing license, so I’m just gonna assign a new license to it?”

Leave a Comment

four × two =

Pin It on Pinterest

hourglass