SQL Servers are the most complicated, most expensive, and most critical element of an organization’s software infrastructure and it can be confusing to think about how it works, let alone how to license them. It is easy to get overwhelmed and to simply let your SQL Server sales rep handle it and tell you what you need to purchase and how many. Of course, just because they know their way around their CALs, cores, and sockets does not mean they know what is best for your business. Only you can answer that question.
At MetrixData 360, we strongly believe in educating our clients to improve their understanding of software asset management and software licenses in order to lead to strong, long-term SAM practices after our engagement has concluded. So, today we’re hoping to answer some of your more pressing questions around how to license your SQL servers.
What Are SQL Servers? A Brief Overview
Just to make sure we’re all on the same page, the main job of SQL Servers are to store data and retrieve it upon the request of other software applications, sort of like a company’s personal Google. SQL servers are made of many varied sizes and targeted towards different workloads and different types of workforces. Some exist in the Cloud with thousands of concurrent users and others exist in small to medium size on-prem businesses.
SQL servers are also designed to process different types of data, including primitive types like Char, Varchar, binary, and text, just to name a few. SQL Server licensing can be staggeringly overwhelming due to its sheer size and the number of other applications that interact with it. Before we get into how a SQL Server works, here are some terms that you may need to know:
Physical Server: the actual wires-and-bolts physical hardware system.
Physical Processor: the physical chip that is housed in a socket within the physical server that contains one or more cores.
Physical Core: Something like a mini server inside the server, a physical core is a smaller processing unit within the physical processor of the server, and are found in groups of two.
Retail (although you cannot buy an enterprise license through this means)
Volume licensing programs (including the MPSA, the EA, the EAS, the SCA, OPEN)
A third party through either Independent Software Vendor Royalty (ISVR) or Services Provider License Agreement (SPLA). Web edition purchases can only be made through a SPLA
Free downloads for some editions (sees SQL Server editions section of this document to learn more about free editions of SQL Servers). SQL Servers come with different licensing types and different editions, all of which we will break down. First, let’s look at licensing types, of which there are two: Core Based Licensing, and Server + CAL Licensing.
Core Based Licensing
This license allows for an unlimited number of users and devices to be connected to a server. If you want to install your SQL servers under a Core Based License, make sure you can follow these rules:
You need to license every physical operating system environment (OSE) that is running SQL server software. You will need a core license for every core in the processor.
You need at least four core licenses for each physical processor on the server (core licenses are sold in packs of two).
The SQL Server or any of its components needs to be licensed. What this means is that you can’t separate products of the SQL server over different machines. If the SQL Server Agent is running exclusively on one SQL server and the SQL server reporting services is being run exclusively on another machine, you’ll run into problems if you try to license that all under a single license. You would need two separate licenses for that scenario.
Anything that is installed on the physical machine you need to have a license for. You don’t necessarily need it to be running to require a license for it.
A math problem: Let’s say I have a single physical server. On the physical server, there are two processors, each with six physical cores with a total of twelve cores. In addition to the license for the operating system, I would need 6 core licenses (since they come in packs of two) in order to be properly licensed.
Benefits of Core-Based Licensing
Core-based licensing is typically the only option you have at your disposal when the SQL server in question is being accessed by devices and users outside your company’s network, since Server + CAL licenses would require you to purchase a license for every external person/device, which would not only be expensive, it would also be impossible to keep track of.
Ideal for larger companies, since it is easy to manage. Imagine having an international corporation with tens of thousands of employees, keeping track of who needed what CAL would be exhausting.
It also can prove cheaper for larger organizations, especially if your users far outnumber the cores you have.
Table of Contents
Table of Contents
SQL Servers are the most complicated, most expensive, and most critical element of an organization’s software infrastructure and it can be confusing to think about how it works, let alone how to license them. It is easy to get overwhelmed and to simply let your SQL Server sales rep handle it and tell you what you need to purchase and how many. Of course, just because they know their way around their CALs, cores, and sockets does not mean they know what is best for your business. Only you can answer that question.
At MetrixData 360, we strongly believe in educating our clients to improve their understanding of software asset management and software licenses in order to lead to strong, long-term SAM practices after our engagement has concluded. So, today we’re hoping to answer some of your more pressing questions around how to license your SQL servers.
What Are SQL Servers? A Brief Overview
Just to make sure we’re all on the same page, the main job of SQL Servers are to store data and retrieve it upon the request of other software applications, sort of like a company’s personal Google. SQL servers are made of many varied sizes and targeted towards different workloads and different types of workforces. Some exist in the Cloud with thousands of concurrent users and others exist in small to medium size on-prem businesses.
SQL servers are also designed to process different types of data, including primitive types like Char, Varchar, binary, and text, just to name a few. SQL Server licensing can be staggeringly overwhelming due to its sheer size and the number of other applications that interact with it. Before we get into how a SQL Server works, here are some terms that you may need to know:
Physical Server: the actual wires-and-bolts physical hardware system.
Physical Processor: the physical chip that is housed in a socket within the physical server that contains one or more cores.
Physical Core: Something like a mini server inside the server, a physical core is a smaller processing unit within the physical processor of the server, and are found in groups of two.
Retail (although you cannot buy an enterprise license through this means)
Volume licensing programs (including the MPSA, the EA, the EAS, the SCA, OPEN)
A third party through either Independent Software Vendor Royalty (ISVR) or Services Provider License Agreement (SPLA). Web edition purchases can only be made through a SPLA
Free downloads for some editions (sees SQL Server editions section of this document to learn more about free editions of SQL Servers). SQL Servers come with different licensing types and different editions, all of which we will break down. First, let’s look at licensing types, of which there are two: Core Based Licensing, and Server + CAL Licensing.
Core Based Licensing
This license allows for an unlimited number of users and devices to be connected to a server. If you want to install your SQL servers under a Core Based License, make sure you can follow these rules:
You need to license every physical operating system environment (OSE) that is running SQL server software. You will need a core license for every core in the processor.
You need at least four core licenses for each physical processor on the server (core licenses are sold in packs of two).
The SQL Server or any of its components needs to be licensed. What this means is that you can’t separate products of the SQL server over different machines. If the SQL Server Agent is running exclusively on one SQL server and the SQL server reporting services is being run exclusively on another machine, you’ll run into problems if you try to license that all under a single license. You would need two separate licenses for that scenario.
Anything that is installed on the physical machine you need to have a license for. You don’t necessarily need it to be running to require a license for it.
A math problem: Let’s say I have a single physical server. On the physical server, there are two processors, each with six physical cores with a total of twelve cores. In addition to the license for the operating system, I would need 6 core licenses (since they come in packs of two) in order to be properly licensed.
Benefits of Core-Based Licensing
Core-based licensing is typically the only option you have at your disposal when the SQL server in question is being accessed by devices and users outside your company’s network, since Server + CAL licenses would require you to purchase a license for every external person/device, which would not only be expensive, it would also be impossible to keep track of.
Ideal for larger companies, since it is easy to manage. Imagine having an international corporation with tens of thousands of employees, keeping track of who needed what CAL would be exhausting.
It also can prove cheaper for larger organizations, especially if your users far outnumber the cores you have.
Server + CAL Based Licensing
There are instances where a Server + CAL license arrangement may suit your business’s needs better, although it will involve a lot more mixing and matching. You have to fulfill a certain number of guidelines in order to use a Server + CAL license successfully:
Just like with the core-based licenses, any physical operating system running SQL server software or any of SQL server’s components will need a SQL server license assigned to the physical server hosting OSE.
In addition to the license for the OSE, you will also need to purchase a license for each device and/or user that has access. Think of the OSE license like purchasing the lock on your door, the CALs are the keys, you need both to gain access.
Client Access Licenses (CAL)
Client Access Licenses (CAL), is a license that grants access to specific Microsoft server software, usually in conjunction with other Microsoft server software licenses. Basically, while the server license allows for the installation of the software on an operating system, the CAL allows for people or devices to access the services that the operating system is hosting. There are two different types of CALs, depending primarily on what your company’s needs the server software you intend to use your CAL for.
User CAL: Allows for a single unique physical user to access the Microsoft software from many different devices. This includes work devices, personal devices, Internet kiosk or a personal digital assistant without the need to purchase a CAL for every device. However, you are licensed per physical person, not log-in usernames, so all the John Smiths in your company can breathe easy.
Device CAL: Allows a large number of users to access the server software through a single device.
Be very careful with the version number your CAL has when you purchase it (IE. Windows Server 2010 CAL). The CAL must be of the same version or be a more recent version than the version of the Server software you are pairing it with. For instance, a Windows Server 2010 CAL can be paired with a Windows 2010 or 2008 server but not a 2012 Server.
Each server product will require the associated CAL. For instance, if you have a Windows Server and an Exchange Server, which both access the Active Directory, then you will need a Window Servers CAL and an Exchange CAL. A CAL can also give you access to multiple servers of the same kind throughout your domain.
As you can imagine the pairing of your CALs to your servers can get extremely confusing and complex, especially if you try to mix and match. So, it is always a good idea to consult your Microsoft Rep or your third-party rep, give them a clear picture about what your software environment looks like and then they can tell you about the CALs you need.
Optimize Your SQL Server Software Contract Before and After the Purchase and Save Money
How IT Departments Can Navigate the Complexities of Windows and SQL Server Licensing with Microsoft True Up Support
How Do You License SQL Server?
Optimize Your SQL Server Software Contract Before and After the Purchase and Save Money
How IT Departments Can Navigate the Complexities of Windows and SQL Server Licensing with Microsoft True Up Support
How Do You License SQL Server?
Types of SQL Server Edition
Now that we have our SQL server licensing models laid out, we can move onto the next level of complication: Editions. Microsoft first deploy SQL Server Express to see if it is sufficient for their specific applications and will only move to the fee-based editions when they can confirm that Express will not meet their requirements.
Developer: This edition allows you to build, test, and demonstrate applications in a non-production environment. It is important that the ‘non-production’ element is upheld in this edition, since using the developer edition on anything that is full production can result in heavy fines. A piece of software will be considered in production if individuals, either inside or outside of the organization, use the software for any reason beyond development, including evaluation acceptance testing such as a review of the application before it is put into general use.
A SQL server will also be considered in production if it is connected to another database that is in production or runs as a backup or to provide disaster-recovery to a SQL server in production. As you can probably imagine, mixing production and non-production environments is a recipe for disaster, as this can cause hyper complexity and compliance issues, especially if access controls are not established that prohibits use outside of development and testing. There are a few ways to counteract this problem:
Use naming conventions for SQL Server instances to explicitly state if a Server is in development or in testing.
Install the SQL server on a separate network segment or cloud environment to lower the chance of unauthorized interaction.
Require that installs be developer-specific editions.
The main challenge with these editions is proving which edition you have. For example, if you are in a software audit, unless provided with evidence that proves otherwise, the software auditors will assume that you only have Enterprise editions, which are the most expensive. Proving which editions, you have could mean the difference between owing hundreds of thousands of dollars and owing nothing.
Licensing for Development Environments
While Development and Express environments can be great in saving you money, in testing and demonstrating your software before deployment, it is important that these scenarios are licensed properly and that you understand their limitations. There are two types of SQL Server Development licenses:
Developer-Specific Licenses: Used primarily for debugging, designing, development, testing and demonstrating purposes. This license is for non-production use only and is often purchased when programmers, professional testers, technical writers, database professionals, or IT administrators are involved. Developer specific licenses are assigned on a per-user basis, in which Users can install and access an unlimited number of SQL Server instances and share those instances only with other users who have been assigned the same type of developer-specific user licenses.
That means, for this licensing model, if anyone wishing to access a development environment requires a developer-specific license, even for tasks as hands-off as administrative purposes. The only exception to this is user acceptance testing. Installations can be set up and taken down at any time and can be placed on desktops, dedicated servers, shared servers, and cloud environments. Some potentially less expensive alternatives to this license include the following:
Purchasing new production licenses
Cloud-based services like Windows Azure, which are usually based on a monthly subscription model (if you have an MSDN subscription, it includes Windows Azure credits, discounted rates and the ability to use MSDN software at no additional charge)
Free editions like SQL Server Express and the SQL Server Compact (a free embedded edition of SQL specifically for developers)
</div class=”listbox”>Evaluation Licenses: Used to assess the software for potential business use. Again, only used for non-production environments but it is not often used in development and test environments. Usually comes with an expiration date (60-180 days to evaluate the use of the software) when obtained through volume license contracts.
Licensing Virtualized Environments
It is possible and necessary to license virtualized environments, and you have the ability to cover your VMs under your Enterprise + Software Assurance addition licensing model if you have one. This will cover all the VMs that your software environment will ever see, which comes in handy since VMs are so easily and quickly cloned and installed.
However, it is terribly important to consult with your Microsoft Rep to ask if virtualized environments can be properly covered by your software assurance as you don’t want to run the risk of facing any compliance issues with Microsoft. You will need a license for every virtual core that you have.
Licensing your Virtual Environment all depends on the licensing model you choose, with the per core model proving much more cost-effective for many clients. If you aim to license the Virtual Cores on Virtual Operating System Environments (OSE), then you will need a minimum of four licenses per processor if you have more than four cores on each of your virtual processors, then you’ll need to calculate what you’ll need based on the number of cores. If your OSE is mapped to different pieces of hardware, you’ll need additional licenses for anything the OSE is touching.
Power BI and SQL Server
Power BI is one of the most popular services for large businesses, and it can quickly become the most complicated due to its robust environment and its complicated, although critical, relationship with SQL servers. You can obtain Power BI either through purchasing one of the Power BI plans or through having SQL Server Enterprise Edition + Software Assurance. SQL Server Enterprise Edition + Software Assurance will give you access to the Power BI Server, this will allow for on-prem sharing of Power BI Content through the Power BI report server.
Although you will still need to have a Power BI account for content creation. If your organization already has an Enterprise SQL Server edition and intends to use Power BI strictly for On-prem sharing of content, simply getting Software Assurance will be the more cost-effective option as opposed to buying a Power BI plan.
It is also important to note that Power BI Desktop has access to SQL Server, but not Power BI Service. Although Power BI Service can provide a connection to Azure SQL Database and SQL Data Warehouse, it can’t do the same with SQL Server. With the Desktop, however, you can retrieve SQL Server data from tables and run queries that can retrieve a subset of the data from multiple tables.
Licensing for Disaster Recovery and High Availability
Making sure that your SQL server can properly store information and making sure you can access it at any time is a critical element for SQL servers’ customers and one of the most popular features in their software assurance benefits. Which is why Microsoft, as of November 1st, 2019, has three enhanced benefits to offer to software assurance customers, which can be applied to any SQL Server that is still supported by Microsoft, including failover servers for high availability, disaster recovery, and disaster recovery in Azure. What this means is that you can run passive SQL Server instances on separate operating system environments (OSE) or servers for high-availability on-prem or in Azure to cover any sort of failover event.
If you have a secondary server that is only used as failover support, then you do not need to license that server separately from the SQL server it is supporting, as long as the server remains truly passive and the primary SQL Server is covered by your Software Assurance.
If the passive server is providing data, such as reports, to clients or performing any other ‘work’ including additional backups, then it will be considered active and will require its own license. It is most important that you have a means of proving when your servers are passive, since during a software audit, the software auditors will assume that all your servers are active if given the chance to assume so.
If you are licensed using the Server + CAL model, then any user or device that is indirectly accessing your SQL server data through another hardware device or software application will require their own SQL Server CALs.
However, it will not be easy since a SQL Server upgrade will take months and you should plan accordingly. When you are considering updating from one Server to the next, the first thing you need to do is make a to-do list containing everything you have to do, such as:
Making sure you have all the Window Updates
Do you have .NET Framework installed correctly?
Do you have KB2919355 installed (if you are using Server 2012 with SQL 2014 installation)
Insure that you have enough free space to allow for the upgrade (at least 100GB). After all such preparations are ready you can begin the whole upgrading process
If you have Software Assurance, then you are covered to upgrade your SQL Server edition, if not then you will have to purchase more licenses. Check to make sure what sort of changes have occurred since you last updated SQL Server, since depending on how old your SQL Server is, you may find yourself confronted with new features, new definitions, and new licensing metrics.
Do some research into the new SQL Server model you are planning on upgrading to and familiarize yourself on any differences the new edition has compared to your old model. If you are purchasing brand new licenses, consider which new SQL Server Edition will best suit your company’s needs and budget. Lastly, decide whether, this time around with your new SQL Server, if Software Assurance is something that interests your company.
Want to Learn More?
SQL Server licensing should not be a mystery, it’s important that you have a strong understanding of your software environment, including the backbone of the whole infrastructure. SQL Servers are so thoroughly implemented throughout the software environments of organizations that a simple mistake could easily be scaled up to mean millions of dollars in software auditing fines.
At MetrixData 360, we understand the importance of making sure that your SQL Server licensing is understood and maintained. Our expertise in software licenses has led to clients saving 20%-30% of spending on your software environment. If you’d like to find out how you can put money back into your IT department, you can contact us using the information below.
Book an Appointment with a SQL Server Licensing Expert Today
SQL Servers are the most complicated, most expensive, and most critical element of an organization’s software infrastructure and it can be confusing to think about how it works, let alone how to license them. It is easy to get overwhelmed and to simply let your SQL Server sales rep handle it and tell you what you need to purchase and how many. Of course, just because they know their way around their CALs, cores, and sockets does not mean they know what is best for your business. Only you can answer that question.
At MetrixData 360, we strongly believe in educating our clients to improve their understanding of software asset management and software licenses in order to lead to strong, long-term SAM practices after our engagement has concluded. So, today we’re hoping to answer some of your more pressing questions around how to license your SQL servers.
Just to make sure we’re all on the same page, the main job of SQL Servers are to store data and retrieve it upon the request of other software applications, sort of like a company’s personal Google. SQL servers are made of many varied sizes and targeted towards different workloads and different types of workforces. Some exist in the Cloud with thousands of concurrent users and others exist in small to medium size on-prem businesses.
SQL servers are also designed to process different types of data, including primitive types like Char, Varchar, binary, and text, just to name a few. SQL Server licensing can be staggeringly overwhelming due to its sheer size and the number of other applications that interact with it. Before we get into how a SQL Server works, here are some terms that you may need to know:
Physical Server: the actual wires-and-bolts physical hardware system.
Physical Processor: the physical chip that is housed in a socket within the physical server that contains one or more cores.
Physical Core: Something like a mini server inside the server, a physical core is a smaller processing unit within the physical processor of the server, and are found in groups of two.
Retail (although you cannot buy an enterprise license through this means)
Volume licensing programs (including the MPSA, the EA, the EAS, the SCA, OPEN)
A third party through either Independent Software Vendor Royalty (ISVR) or Services Provider License Agreement (SPLA). Web edition purchases can only be made through a SPLA
Free downloads for some editions (sees SQL Server editions section of this document to learn more about free editions of SQL Servers). SQL Servers come with different licensing types and different editions, all of which we will break down. First, let’s look at licensing types, of which there are two: Core Based Licensing, and Server + CAL Licensing.
Core Based Licensing
This license allows for an unlimited number of users and devices to be connected to a server. If you want to install your SQL servers under a Core Based License, make sure you can follow these rules:
You need to license every physical operating system environment (OSE) that is running SQL server software. You will need a core license for every core in the processor.
You need at least four core licenses for each physical processor on the server (core licenses are sold in packs of two).
The SQL Server or any of its components needs to be licensed. What this means is that you can’t separate products of the SQL server over different machines. If the SQL Server Agent is running exclusively on one SQL server and the SQL server reporting services is being run exclusively on another machine, you’ll run into problems if you try to license that all under a single license. You would need two separate licenses for that scenario.
Anything that is installed on the physical machine you need to have a license for. You don’t necessarily need it to be running to require a license for it.
A math problem: Let’s say I have a single physical server. On the physical server, there are two processors, each with six physical cores with a total of twelve cores. In addition to the license for the operating system, I would need 6 core licenses (since they come in packs of two) in order to be properly licensed.
Benefits of Core-Based Licensing
Core-based licensing is typically the only option you have at your disposal when the SQL server in question is being accessed by devices and users outside your company’s network, since Server + CAL licenses would require you to purchase a license for every external person/device, which would not only be expensive, it would also be impossible to keep track of.
Ideal for larger companies, since it is easy to manage. Imagine having an international corporation with tens of thousands of employees, keeping track of who needed what CAL would be exhausting.
It also can prove cheaper for larger organizations, especially if your users far outnumber the cores you have.
Server + CAL Based Licensing
There are instances where a Server + CAL license arrangement may suit your business’s needs better, although it will involve a lot more mixing and matching. You have to fulfill a certain number of guidelines in order to use a Server + CAL license successfully:
Just like with the core-based licenses, any physical operating system running SQL server software or any of SQL server’s components will need a SQL server license assigned to the physical server hosting OSE.
In addition to the license for the OSE, you will also need to purchase a license for each device and/or user that has access. Think of the OSE license like purchasing the lock on your door, the CALs are the keys, you need both to gain access.
Client Access Licenses (CAL)
Client Access Licenses (CAL), is a license that grants access to specific Microsoft server software, usually in conjunction with other Microsoft server software licenses. Basically, while the server license allows for the installation of the software on an operating system, the CAL allows for people or devices to access the services that the operating system is hosting. There are two different types of CALs, depending primarily on what your company’s needs the server software you intend to use your CAL for.
User CAL: Allows for a single unique physical user to access the Microsoft software from many different devices. This includes work devices, personal devices, Internet kiosk or a personal digital assistant without the need to purchase a CAL for every device. However, you are licensed per physical person, not log-in usernames, so all the John Smiths in your company can breathe easy.
Device CAL: Allows a large number of users to access the server software through a single device.
Be very careful with the version number your CAL has when you purchase it (IE. Windows Server 2010 CAL). The CAL must be of the same version or be a more recent version than the version of the Server software you are pairing it with. For instance, a Windows Server 2010 CAL can be paired with a Windows 2010 or 2008 server but not a 2012 Server.
Each server product will require the associated CAL. For instance, if you have a Windows Server and an Exchange Server, which both access the Active Directory, then you will need a Window Servers CAL and an Exchange CAL. A CAL can also give you access to multiple servers of the same kind throughout your domain.
As you can imagine the pairing of your CALs to your servers can get extremely confusing and complex, especially if you try to mix and match. So, it is always a good idea to consult your Microsoft Rep or your third-party rep, give them a clear picture about what your software environment looks like and then they can tell you about the CALs you need.
Now that we have our SQL server licensing models laid out, we can move onto the next level of complication: Editions. Microsoft first deploy SQL Server Express to see if it is sufficient for their specific applications and will only move to the fee-based editions when they can confirm that Express will not meet their requirements.
Developer: This edition allows you to build, test, and demonstrate applications in a non-production environment. It is important that the ‘non-production’ element is upheld in this edition, since using the developer edition on anything that is full production can result in heavy fines. A piece of software will be considered in production if individuals, either inside or outside of the organization, use the software for any reason beyond development, including evaluation acceptance testing such as a review of the application before it is put into general use.
A SQL server will also be considered in production if it is connected to another database that is in production or runs as a backup or to provide disaster-recovery to a SQL server in production. As you can probably imagine, mixing production and non-production environments is a recipe for disaster, as this can cause hyper complexity and compliance issues, especially if access controls are not established that prohibits use outside of development and testing. There are a few ways to counteract this problem:
Use naming conventions for SQL Server instances to explicitly state if a Server is in development or in testing.
Install the SQL server on a separate network segment or cloud environment to lower the chance of unauthorized interaction.
Require that installs be developer-specific editions.
The main challenge with these editions is proving which edition you have. For example, if you are in a software audit, unless provided with evidence that proves otherwise, the software auditors will assume that you only have Enterprise editions, which are the most expensive. Proving which editions, you have could mean the difference between owing hundreds of thousands of dollars and owing nothing.
Licensing for Development Environments
While Development and Express environments can be great in saving you money, in testing and demonstrating your software before deployment, it is important that these scenarios are licensed properly and that you understand their limitations. There are two types of SQL Server Development licenses:
Developer-Specific Licenses: Used primarily for debugging, designing, development, testing and demonstrating purposes. This license is for non-production use only and is often purchased when programmers, professional testers, technical writers, database professionals, or IT administrators are involved. Developer specific licenses are assigned on a per-user basis, in which Users can install and access an unlimited number of SQL Server instances and share those instances only with other users who have been assigned the same type of developer-specific user licenses.
That means, for this licensing model, if anyone wishing to access a development environment requires a developer-specific license, even for tasks as hands-off as administrative purposes. The only exception to this is user acceptance testing. Installations can be set up and taken down at any time and can be placed on desktops, dedicated servers, shared servers, and cloud environments. Some potentially less expensive alternatives to this license include the following:
Purchasing new production licenses
Cloud-based services like Windows Azure, which are usually based on a monthly subscription model (if you have an MSDN subscription, it includes Windows Azure credits, discounted rates and the ability to use MSDN software at no additional charge)
Free editions like SQL Server Express and the SQL Server Compact (a free embedded edition of SQL specifically for developers)
</div class=”listbox”>Evaluation Licenses: Used to assess the software for potential business use. Again, only used for non-production environments but it is not often used in development and test environments. Usually comes with an expiration date (60-180 days to evaluate the use of the software) when obtained through volume license contracts.
Licensing Virtualized Environments
It is possible and necessary to license virtualized environments, and you have the ability to cover your VMs under your Enterprise + Software Assurance addition licensing model if you have one. This will cover all the VMs that your software environment will ever see, which comes in handy since VMs are so easily and quickly cloned and installed.
However, it is terribly important to consult with your Microsoft Rep to ask if virtualized environments can be properly covered by your software assurance as you don’t want to run the risk of facing any compliance issues with Microsoft. You will need a license for every virtual core that you have.
Licensing your Virtual Environment all depends on the licensing model you choose, with the per core model proving much more cost-effective for many clients. If you aim to license the Virtual Cores on Virtual Operating System Environments (OSE), then you will need a minimum of four licenses per processor if you have more than four cores on each of your virtual processors, then you’ll need to calculate what you’ll need based on the number of cores. If your OSE is mapped to different pieces of hardware, you’ll need additional licenses for anything the OSE is touching.
Power BI and SQL Server
Power BI is one of the most popular services for large businesses, and it can quickly become the most complicated due to its robust environment and its complicated, although critical, relationship with SQL servers. You can obtain Power BI either through purchasing one of the Power BI plans or through having SQL Server Enterprise Edition + Software Assurance. SQL Server Enterprise Edition + Software Assurance will give you access to the Power BI Server, this will allow for on-prem sharing of Power BI Content through the Power BI report server.
Although you will still need to have a Power BI account for content creation. If your organization already has an Enterprise SQL Server edition and intends to use Power BI strictly for On-prem sharing of content, simply getting Software Assurance will be the more cost-effective option as opposed to buying a Power BI plan.
It is also important to note that Power BI Desktop has access to SQL Server, but not Power BI Service. Although Power BI Service can provide a connection to Azure SQL Database and SQL Data Warehouse, it can’t do the same with SQL Server. With the Desktop, however, you can retrieve SQL Server data from tables and run queries that can retrieve a subset of the data from multiple tables.
Licensing for Disaster Recovery and High Availability
Making sure that your SQL server can properly store information and making sure you can access it at any time is a critical element for SQL servers’ customers and one of the most popular features in their software assurance benefits. Which is why Microsoft, as of November 1st, 2019, has three enhanced benefits to offer to software assurance customers, which can be applied to any SQL Server that is still supported by Microsoft, including failover servers for high availability, disaster recovery, and disaster recovery in Azure. What this means is that you can run passive SQL Server instances on separate operating system environments (OSE) or servers for high-availability on-prem or in Azure to cover any sort of failover event.
If you have a secondary server that is only used as failover support, then you do not need to license that server separately from the SQL server it is supporting, as long as the server remains truly passive and the primary SQL Server is covered by your Software Assurance.
If the passive server is providing data, such as reports, to clients or performing any other ‘work’ including additional backups, then it will be considered active and will require its own license. It is most important that you have a means of proving when your servers are passive, since during a software audit, the software auditors will assume that all your servers are active if given the chance to assume so.
If you are licensed using the Server + CAL model, then any user or device that is indirectly accessing your SQL server data through another hardware device or software application will require their own SQL Server CALs.
However, it will not be easy since a SQL Server upgrade will take months and you should plan accordingly. When you are considering updating from one Server to the next, the first thing you need to do is make a to-do list containing everything you have to do, such as:
Making sure you have all the Window Updates
Do you have .NET Framework installed correctly?
Do you have KB2919355 installed (if you are using Server 2012 with SQL 2014 installation)
Insure that you have enough free space to allow for the upgrade (at least 100GB). After all such preparations are ready you can begin the whole upgrading process
If you have Software Assurance, then you are covered to upgrade your SQL Server edition, if not then you will have to purchase more licenses. Check to make sure what sort of changes have occurred since you last updated SQL Server, since depending on how old your SQL Server is, you may find yourself confronted with new features, new definitions, and new licensing metrics.
Do some research into the new SQL Server model you are planning on upgrading to and familiarize yourself on any differences the new edition has compared to your old model. If you are purchasing brand new licenses, consider which new SQL Server Edition will best suit your company’s needs and budget. Lastly, decide whether, this time around with your new SQL Server, if Software Assurance is something that interests your company.
Want to Learn More?
SQL Server licensing should not be a mystery, it’s important that you have a strong understanding of your software environment, including the backbone of the whole infrastructure. SQL Servers are so thoroughly implemented throughout the software environments of organizations that a simple mistake could easily be scaled up to mean millions of dollars in software auditing fines.
At MetrixData 360, we understand the importance of making sure that your SQL Server licensing is understood and maintained. Our expertise in software licenses has led to clients saving 20%-30% of spending on your software environment. If you’d like to find out how you can put money back into your IT department, you can contact us using the information below.
Book an Appointment with a SQL Server Licensing Expert Today
Table of Contents
Cookie Consent
To provide you with the best experience, we use cookies to store and/or access device information.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
