Microsoft does not make licensing SQL Server easy, either under SPLA or under volume licensing agreements. Here are the three most significant problems that our clients face when trying to license that product:

  • Four-Core Minimum – Microsoft allows SQL Server to be licensed based either on physical core counts (for physical servers or virtualization hosts) or on vCPU counts. In most high-availability, multi-tenant virtualization environments, licensing based on vCPUs often makes more sense, since licensing physical infrastructure for full virtualization rights can be very costly. However, many businesses overlook the fact that Microsoft requires every VM licensed for SQL Server to be assigned a minimum of four core licenses, regardless of the number of vCPUs actually allocated to that server. Overlooking that requirement can lead to significant shortfalls in a company’s monthly SPLA reports, leading to equally significant exposure (at a contractual 25% markup) in the event of an audit.
  • Must Count All Core Services – SQL Server consists of a number of different product components, including what Microsoft considers to be “core” SQL Server services, including the following: SQL Server Database Engine (DB), SQL Server R Services for Windows, Master Data Services (MDS), Analysis Services (AS), Integration Services (IS), Reporting Services (RS), and Data Quality Services (DQS). Microsoft requires an installation of a core service to be licensed in the same way as a full SQL Server product installation. Therefore, if a single SQL Server implementation has core services deployed on two separate servers or VMs, each of those servers or VMs needs to be licensed for the same SQL Server edition.
  • Segregate Internal-Use Servers – SPLA allows licensees to license SQL Server (and other Microsoft products) for internal use with monthly SPLA reports, subject to a 50% internal-use maximum per product. However, SPLA does not require that outcome, and we often recommend that our clients license their internal-use deployments under a volume license agreement. That model allows for cleaner reporting and clearer boundaries when defining the scope of a Microsoft audit. It is important to keep in mind, though, that in order to allow for that licensing model (1) customers’ end-users must have no way to access the data in the internal-use SQL Servers, either directly or indirectly (and by indirectly, we mean that the customers are not able to interact with any application in a way that results in data being retrieved from that SQL Server), AND (2) the physical server or physical virtualization host where an internal-use SQL Server is deployed generally must not also be running other SQL Server deployments licensed under SPLA.

Note that all of the above guidance pertains to SQL Server licensed per core. It remains possible to license SQL Server Standard per user, and user-based licensing entails the different challenge of ensuring that the number of customer end users authorized to directly or indirectly access SQL Server (regardless of actual usage) aligns with the number of SQL Server Subscriber Access Licenses reported under SPLA.