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 firstname.lastname@example.org
Thanks for reading,