In part I of our blog series, we revealed what SPLA is and its different applicable use cases. This post will focus on license mobility, Subscriber Access License (SAL) for Software Assurance (SA), and using a data center provider.
Transferring Software to Another Data Center Using License Mobility
In this article, “license mobility” refers to the end customer who wants to transfer the software to another data center; not license mobility within server farms.
What is license mobility? License mobility in its simplest terms is a software assurance benefit. It allows organizations who purchased certain applications the ability to transfer those licenses to another data center. There’s only certain applications that are eligible – Exchange, CRM, Skype for Business, SharePoint, SQL, among others. Check the PUR for any changes or for a full list of eligible software. Notice Windows is not license mobility eligible. Windows would have to be provided by the data center provider. For example:
You purchase SharePoint Standard with license and SA. Since you no longer have the resources to deploy it on premise (out of your data center), you decide to use someone else’s, such as Amazon. , Since SharePoint is license mobility eligible, you transfer the license to Amazon (server and applicable CAL’s), and Amazon will host a dedicated VM for you. Windows will be covered under Amazon’s own SPLA. Under license mobility, the service provider will have a shared hardware environment but dedicated virtual machines.
Keep these two things in mind when deciding to use license mobility with SA:
- You must have active SA on the server and CAL’s
- You can no longer deploy the servers on premise.
Subscriber Access License for Software Assurance
Subscriber Access License for Software Assurance is a discounted SKU (heavily discounted, I might add) on the SPLA pricelist. Similar to license mobility, SAL is an SA benefit for the end user (similar to a CAL but is a user license only under SPLA). It does require all eligible software to have active SA in order to qualify. The difference between license mobility and SAL for SA is you can still run the software on premise as well as in another data center provider. Why? Nothing is transferred because SAL for SA is an actual SKU; the end user pays a small fee for this service from a licensing perspective.
Why would an end user choose this model? I like to think of it more as a disaster recovery benefit than anything else. Let’s say you love your Exchange Server so much you are worried about it breaking down. With SAL for SA, you can still deploy your Exchange Server on premise, but for peace of mind have a secondary server (always on- backing up) in another data center. The benefit for the data center provider is unlike license mobility: you can deploy the software on shared hardware AND shared virtual machines. You would be required to report the SAL for SA SKU on the SPLA pricelist.
SPLA for Azure/Amazon and the Like
What happens if you decide to host your solution from another data center provider on behalf of your customers? Can you still use SPLA? Absolutely, but keep a few things in mind:
- You must purchase a Windows instance from the provider.
- You cannot report (license) cores or processors under your own agreement. If the solution requires cores or processors you must purchase them from the data center provider. Why? Unless it is a 100% dedicated environment (Amazon/Azure are not by the way) the use rights prohibit it.
- You CAN report user licenses under your SPLA and purchase Windows/SQL from the data center provider. Here’s a note from the Azure website that I think explains it well.
Can service providers build a cloud-based service on Azure using session-based hosting through RDS (Remote Desktop Services, formerly known as Terminal Services)?
Yes, service providers can offer hosted solutions through RDS running on Azure as long as they obtained RDS SALs (Subscriber Access Licenses) through a Microsoft Services Provider License Agreement (SPLA) reseller.
- You CAN have your customers purchase Azure and they can have you manage it on their behalf. Under this model you would be a managed service provider.
If you are an IaaS provider offering similar solutions as Amazon and Azure, the same rules would apply. There’s a lot of different scenarios that come in play when deploying applications on a 3rd party data center. If you would like a better overview please reach out to your SoftwareONE sales representative and let’s review it! See you next time for Part III– Application hosting and ISV’s.