Exchange & SharePoint Licensing in SPLA

For Service Providers, hosting email (Exchange) and collaboration portals (SharePoint) are often the bread-and-butter services that get a foot in the customer's door. However, because these products have been around for decades, their licensing models in the Services Provider License Agreement (SPLA) are often assumed to be simple.

‍

In reality, they contain specific rules regarding "Additive" licenses, internet-facing usage, and hidden dependencies. Below is your guide to licensing the Microsoft collaboration stack and how the Flexible Virtualization Benefit changes the equation.

Unlike SQL Server or Windows Server, which offer core-based options, Exchange Server in SPLA is strictly a Subscriber Access License (SAL) model.

• No Server License: You do not pay for the Exchange Server software itself. You can install it on as many servers as you need (redundancy, DAGs, etc.) without extra cost.
• User SALs: You must report a SAL for every unique user authorized to access the system.
• Editions & Features: Exchange SALs are generally split into Basic, Standard, and Enterprise:
  
  • Basic: Limited features (Outlook Web Access, POP/IMAP), usually for low-cost mailboxes.
  • Standard: Adds full Outlook support.
  • Enterprise: Adds advanced features like Unified Messaging, Data Loss Prevention (DLP), and In-Place Holds.

• The "Plus" SKU: If your customer does not already own a license for the Outlook desktop client (e.g., via Office Standard), you must report the "Plus" version of the SAL (e.g., "Exchange Standard Plus") to legally provide the Outlook client to them.

SharePoint is more complex because its licensing changes based on who is accessing it.

Scenario A: Internal/Intranet (The SAL Model) 

If the SharePoint site is used for a customer's employees (Intranet) or named external partners (Extranet), you must use the SAL Model.

• Standard SAL: Required for base functionality.
• Additive Enterprise SAL: If you use Enterprise features (like BI components or Access Services), you must report both the Standard SAL and the Enterprise SAL for that user.

Scenario B: Public Internet Sites (The Core/Processor Model) 

If you are hosting a public-facing website for anonymous users (e.g., a corporate website or e-commerce store), reporting SALs is impossible because you don't know who the users are.

• The Solution: You license the hardware using SharePoint for Internet/Hosting licenses (historically Processor/Core based). This allows an unlimited number of anonymous users to access the site.

Auditors frequently flag these products because of their "hidden" dependencies.

The SQL Server Trap (SharePoint)

SharePoint cannot function without a database backend. A top compliance mistake is reporting SharePoint SALs but reporting zero SQL Server licenses.

• The Rule: You must license the SQL Server underneath SharePoint, either by Core (for the server) or by SAL (for every SharePoint user).

The Windows Server Trap (Both) 

Just because Exchange and SharePoint are licensed by User (SAL) does not mean the Operating System is free. You must still license Windows Server on every physical core of the host hardware (or VM) running these applications.

"Generic" Accounts 

Creating a generic email account like "sales@company.com" and allowing 5 different salespeople to check it requires 5 Exchange SALs, not 1. Licensing is based on the human user accessing the service, not the mailbox itself.

The Flexible Virtualization Benefit (FVB) is highly relevant for Exchange and SharePoint because many customers already own these licenses (with Software Assurance) or subscribe to them via Microsoft 365.

‍The Scenario: "Migrate and Modernize" Your customer, CollabCorp, has 500 users with Microsoft 365 E3 subscriptions (which include rights to Exchange Online and SharePoint Online, but also "Dual Use Rights" for on-premise servers). They want to move their historical on-premise Exchange/SharePoint servers to your private cloud for compliance reasons, but they don't want to pay double for licenses.

1. Authorized Outsourcer: You can host this as long as you are not a "Listed Provider" (AWS, Google, Microsoft, Alibaba).
2. Shared Hardware: CollabCorp can deploy their Exchange and SharePoint Virtual Machines on your shared multi-tenant hardware.
3. Licensing:

• The Customer: Uses their existing Microsoft 365 E3 or Exchange/SharePoint Server licenses with active SA to cover the application.
• The Provider: You do not report Exchange or SharePoint SALs on your SPLA.

4. No Forms: Unlike the old "License Mobility" process, there is no verification form required for FVB.

‍Why this matters: This is a massive cost-saver. Under standard SPLA, a 500-user Exchange deployment would cost thousands of dollars per month in SALs. Under FVB, the customer leverages the investment they already made in Microsoft 365, paying you only for the Infrastructure (IaaS) and management.

Navigating Exchange and SharePoint licensing under SPLA and FVB requires precise tracking of users, enabled features, and infrastructure usage. Mistakes can quickly turn into costly audit findings. Octopus Cloud helps service providers maintain full visibility over their Microsoft environments, automate license reporting, and identify hidden compliance risks across Windows, SQL, and collaboration workloads. 

‍

Whether you are running traditional SPLA deployments or enabling customers to benefit from Flexible Virtualization, our team ensures your licensing position is optimized, defensible, and aligned with Microsoft’s latest rules, so you can focus on delivering value instead of managing risk.

‍

To find out more about how Octopus Cloud can help, click here.