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
– 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.
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.
The content of this article is intended to provide a general
guide to the subject matter. Specialist advice should be sought
about your specific circumstances.
To print this article, all you need is to be registered on Mondaq.com.
Click to Login as an existing user or Register so you can print this article.
Register for Access and our Free Biweekly Alert for
This service is completely free. Access 250,000 archived articles from 100+ countries and get a personalised email twice a week covering developments (and yes, our lawyers like to think you’ve read our Disclaimer).