Now it’s time to get into the fun part; the licensing scenarios that can literally drive you NUTS because if interpreted wrong, it can cost you and your company money. Based on experience, here’s a list of the top confusing scenarios….simplified.
Customer Owned Licenses
Let’s say you have a customer that would like to bring their license into your datacenter. You first ask them if the licenses are legit and if they have software assurance for those licenses. Why ask if they have software assurance (SA). If they have SA on certain software applications, they could be eligible for license mobility (shared hardware, dedicated VM). If they do not have software assurance, now you have to consider dedicating (see dedicated v shared in this post) a server and VM for that customer and that customer only. Without software assurance, they do not qualify for license mobility. So keep this in mind – no software assurance = 100% dedicated hosting.
Now let’s say the end customer owns 100 Exchange licenses (CAL) without SA and they would like you to host Exchange for them using these licenses. No problem, you just dedicate a server for those users. But what happens if they hire 50 more employees that need Exchange? Do you simply add those additional 50 users via SPLA or do they have to buy those additional 50 licenses from their volume licensing agreement? If you picked the latter, you would be correct.
You cannot mix server/CALs on a product-by-product basis. This means the end customer CAL’s for a particular product cannot be used to access servers deployed with that product and which are licensed by the service provider under SPLA. It is ok for a service provider to rely on end customer owned licenses for one particular product (like SQL) but acquire licenses for a different product (like Windows) via their SPLA as long as they dedicate the server. It also means that if an end customer has Servers/CALs for a particular product(s) and chooses to move to a hosted model with a service provider, they will need to acquire any additional licenses for that product(s) under their volume licensing agreement (i.e. if they increase the number of seats or need more servers for deployment or load balancing). It’s not ok for the service provider to acquire SAL’s under SPLA when the number of seats goes up for the end customer or when additional servers is required. This is because the licensing construct of internal use doesn’t match that of SPLA ,and therefore needs to be separate.
Dedicated v Shared
So what does “dedicated” and what is “shared mean?” In short, it means one customer per server/VM for dedicated, and multiple customers using the same server/VM for shared. But what about the other components of a hosted offering? You have a SAN, does that need to be dedicated? No, according to this document it doesn’t (download it here)
“Any hardware running an instance of Microsoft software (OS or application) must be dedicated to a single customer. For example, a SAN device that is not running any Microsoft software may be shared by more than one customer; whereas, a server or SAN device that runs Microsoft software may only be used by one customer.”
So ask yourself “is this running Microsoft software on this device?”
SQL virtualization boils down to five options
1) License per virtual machine (if nothing is running physical)
2) License the physical cores on the host and report SQL Enterprise. (allows you to run unlimited VMs)
3) License both physical and virtual (if reporting Standard or Web and it’s running both physically and virtually)
4) Report SQL Business Intelligence (BI) which is licensed per user and can access multiple servers (physical and virtual)
5) Report SQL Standard per user. Same story as BI.
Don’t forget about license mobility within server farms. A server farm by Microsoft’s definition consists up to two datacenter located within 4 hours of each other. So if you have a datacenter in Seattle and another datacenter in New Jersey; that does not qualify. Likewise if you are in Europe; the datacenter must be “within the European Union (EU) and/or European Free Trade Association (EFTA)
One benefit of license mobility within server farms is it will allow a qualified VM to migrate from one host to the next within the same server farm without adding additional licensing costs. You have to license the machine with the most processors or cores to be compliant. In the Service Provider Use Rights (SPUR) it shows you if the product is license mobility within server farms eligible. Pay attention to this use right; there’s a lot of service providers who are reporting license mobility without license mobility.
Hope this brings some clarity. If you have additional questions contact me at email@example.com
Thanks for reading,
June 17, 2014 at 8:21 pm
Thank you for a very informative site. It has made my confidence in our monthly SPLA reporting skyrocket. 🙂
You mention SQL virtualization and I have a question in regards to that.
Currently our Hyper-V infrastructure is based on 2008R2, but as you can imagine we’d like to update it. We’re using VMM 2008 (R2?) currently which is using SQLExpress as a back end. Since that isn’t supported with SCVMM 2012 and later we have to look at licensing SQL. If used solely for the purpose of supporting SCVMM, what is the most cost effective way to license SQL?
June 18, 2014 at 7:32 am
Thank you for your support and kind words.
Good news is System Center 2012 will not include SCVMM but all the other components as well. Better news is it also includes the use of SQL (as long as it is used to only support System Center). If it is used to support other workloads – such as email, SharePoint, etc than a separate license is needed for SQL. Check out this TechNet article – http://social.technet.microsoft.com/Forums/systemcenter/en-US/d8b1a587-74c1-4bc0-b6fd-96cd44a83834/system-centre-2012-sql-licensing
June 18, 2014 at 9:38 am
Excelent! My life just got a lot easier.
Thanks so much for the clarification.
June 18, 2014 at 11:21 am
My pleasure. Thanks for reading
October 10, 2014 at 4:19 pm
Something I’m bumping into a bit wrt SQL licensing is whether I can deploy SQL core licenses on a hosted infrastructure like AWS (or Azure). The SPUR language is not at all straightforward on this. There’s mention that I can deploy on a virtual OSE, but can I report, for instance, 4 SQL cores and deploy that on an AWS 4 v-core VM? Is this addressed explicitly one way or the other in the SPUR? I’ve been told that proc and core licenses have to be reported by hardware hoster, and that only per-user SALs can be licensed in SPLA and deployed on multi-tenant VMs. But, where does it actually say this? (Thanks for any suggestions)
October 21, 2014 at 7:49 am
No, this is not applicable under SPLA. Azure/Amazon are public clouds. (shared resources). You can report SALs via your SPLA. This is highlighted in the FAQ guide for Azure.
It is highlighted in the SPUR. If you read under the SAL section it states the eligible software. Specifically if you look on page 32 under Exchange (as an example) it reads:
“Eligible for Software Services on Data Center Providers’ Servers: Yes”
You can also purchase a SQL image from Azure and Amazon. Same for other IaaS providers. I can promise you not everyone follows the rules.
July 18, 2017 at 4:23 am
You mentioned that one cannot combine CALS and SALS within a product (eg SQL server). Does this apply across editions – for example can a customer deploy SQL std via LM and then license SQL web via SPLA?
July 18, 2017 at 2:05 pm
Hi Craig, as long as they are on separate VM’s you should be fine.