In this article, we will take a closer look at CAL’s and SAL’s…what they are and how to license them. We will also look at the User Subscription License (USL) for Microsoft Online Services.
Client Access License
A Client Access License (CAL) provides the right to access a server. Depending on the environment and product licensed, a CAL can either be a user or a device. Many resellers, consultants, and even Microsoft, make it a lot more complicated than it needs to be. The biggest trick to CAL licensing is remembering it is just a “right” not a technical requirement to access the server. In other words, you can spin up a server, users can access it (in most cases with or without a CAL) and away they go. Sounds great, but it’s not compliant, and I would argue that is the #1 reason customer’s fall victim to compliance.
SQL is a great example of this. When I go to my SharePoint site, I pull reports, store information, share information, and perform many other tasks. What I don’t know is SQL is used in the background to provide access to this information. Did I log into a SQL Server? No. Did I “use” SQL? Yes. This is where multiplexing come into play. Multiplexing uses hardware and/or software to pool connections. The best way to know if a user needs a license (and I’ve said this before) is to ask yourself “If I remove this from my hosted solution would it still work the same as it did prior?” If you answer “no” you need a license. If your SQL Server is licensed in the Server/CAL model, you’re required to have CALs for any User or Device that accesses that application directly or indirectly. Very few users in an organization have credentials to a SQL Server. One way to eliminate some of the risk with SQL is to license by core. Cores allow unlimited number of users to access the server. If they use the server or not, they are covered.
Under SPLA there is a Subscriber Access License (SAL). SAL’s are licensed by user only (there are very few exceptions such as desktop applications and System Center). Like a client access license, a SAL license is not concurrent. This is important, since other vendors are based on concurrent licensing. SAL is like your cable bill, your provider is going to charge you regardless if you turn your TV on or not, SAL licensing works the same way. I’ve written about this before but it’s worth repeating – SAL is for any person that HAS access not who does access. Unlike CAL’s, there is no need to purchase a server license in SPLA.
To add a bit more complexity, let’s review Microsoft Online Services. If you license Exchange Online or an Office 365 Suite, you will purchase a User Subscription License (USL). A USL provides a user access to the online solution. Unlike a CAL and like a SAL (that’s a mouthful) you do not need a server license to access the solution if it’s online. If you want to run anything on premise or in another third-party datacenter, you would require a server license. In other words, if you have SharePoint Online, the USL license will provide on-premises rights (essentially CALs) in addition to their online rights. This allows for the ability to migrate over time and have hybrid environments without incurring additional cost. Keep in mind, when you run hybrid, you do require a server license on premise.
Additionally, if you to purchase an online suite (Exchange Online, SharePoint Online, Skype) you can run pieces of the suite on premise. For example, maybe you want to keep SharePoint on-premises but move Exchange to the cloud. An Office 365 Suite includes both online and on-premises rights for each product in the suite, which means you don’t have to pay for the E Suite and then buy Exchange CALs separately. Just remember the server license!
It is very important to understand the licensing rules before purchasing any software. There has and always will be a difference in the way in which technology can be deployed and the way it must be licensed. Don’t waste money, time, and effort planning a cloud solution without considering the license impact. I was on a call recently where a customer wanted to leverage their Windows Server with Software Assurance in a shared public cloud. Unfortunately, Windows is not license mobility eligible. They worked with a consultant or “expert” who told them one thing, but the rules state otherwise. Yes, maybe they can take advantage of Windows HUB, but Azure unfortunately was not the right fit. Pay attention to the license rules, it can save you. Question? Email firstname.lastname@example.org
Thanks for reading,