Understanding Microsoft Dynamics Licensing

For Service Providers, hosting Line-of-Business (LOB) applications is the "sticky" service that keeps customers loyal. At the top of that food chain is Microsoft Dynamics (including Dynamics 365 on-premises, NAV, GP, and CRM).

However, Dynamics licensing under the Services Provider License Agreement (SPLA) is significantly different from the "User Subscription Licenses" (USLs) used in Microsoft 365. It involves strict dependency rules and specific counting methods.

Below is your guide to navigating Dynamics SALs, handling the SQL backend correctly, and utilizing the Flexible Virtualization Benefit.

The Standard SPLA Model: Subscriber Access Licenses (SAL)

In SPLA, the Dynamics family (both ERP and CRM solutions) is licensed exclusively by User via the Subscriber Access License (SAL) model.

• How it works: You must report a SAL for every unique individual authorized to access the solution directly or indirectly.
• No Server License: Unlike internal Volume Licensing, you generally do not pay for the Dynamics Server software itself in SPLA. You install the server software as needed, but you monetize and report based on the users accessing it.
• Access Types: Depending on the specific Dynamics product (e.g., Dynamics 365 for Customer Service, Sales, or Team Members), different SAL types are available. You must assign the SAL that matches the functionality available to the user.

The Critical Dependency: The SQL Server Backend

The single most common compliance error in hosting Dynamics is forgetting the engine that powers it: SQL Server.

Every instance of Microsoft Dynamics requires a SQL Server database to function. In SPLA, these two products are licensed separately, but they are inextricably linked.

• The Rule: If you are reporting Dynamics SALs, you must almost always be reporting SQL Server licenses (either Core or SAL) for the underlying database.
• The Audit Flag: Auditors cross-reference your reports. If they see "Dynamics CRM SALs" on your report but zero "SQL Server" licenses, it is an immediate red flag indicating non-compliance.

Common Compliance Pitfalls

1. Indirect Access (Multiplexing) Dynamics is often connected to other systems (e.g., a web portal where customers enter data that feeds into the CRM).

• The Rule: SPLA defines "Software Services" as services that interact with products directly or indirectly,.
• The Trap: If you have an automated feed inserting data into Dynamics, you don't just need a license for the automation tool. You need to ensure that the users benefiting from that data are licensed, or that the specific "External Connector" (if available for that specific edition) is utilized.

2. Internal Use vs. Commercial Hosting Service Providers often use Dynamics for their own ticketing or sales management.

• The Rule: You can use SPLA products for internal use, but only if that use is less than 50% of the total use of that product (aggregated with your commercial customers).
• Recommendation: For your own internal Dynamics environment, it is often safer and more cost-effective to use standard internal licensing or Microsoft 365 subscriptions rather than mixing it with your SPLA reporting.

4. Special Scenario: The Flexible Virtualization Benefit (FVB)

Before 2022, if a customer wanted to move their existing Dynamics on-premise licenses to a hoster, they had to use "License Mobility," which required specific forms and verification steps. The Flexible Virtualization Benefit (FVB) has streamlined this significantly.

• The Scenario: The "Dual Use" Customer Your customer, SalesCo, has purchased Dynamics 365 cloud subscriptions (e.g., Dynamics 365 Sales Enterprise) directly from Microsoft or a CSP. These subscriptions often include "Dual Use Rights," allowing them to run an on-premise instance of the software. They want you to host this instance.

The New Rules (FVB):

1. Authorized Outsourcer: You can host this if you are an Authorized Outsourcer (not a Listed Provider like AWS, Google, or Alibaba),.

2. Shared Hardware: Under FVB, SalesCo can run their Dynamics Server on your shared multi-tenant servers. You do not need dedicated hardware.

3. Licensing:

• Customer: SalesCo uses their existing subscriptions (or licenses with Software Assurance) to cover the Dynamics application.
• Provider: You do not report Dynamics SALs on your SPLA.

4. The Stack: The customer can also use FVB to bring their own SQL Server Core licenses (with SA/Subscription) to cover the database.

5. Windows Server: The customer can even bring their own Windows Server licenses (via FVB) to cover the VMs, provided they meet the 8-core minimum per VM rules.

Why this matters: This allows customers who are heavily invested in Microsoft 365/Dynamics 365 to utilize your private cloud services without "double paying" for licenses they already own.

Need Help Navigating Dynamics Licensing in SPLA?

Successful Dynamics hosting today is less about infrastructure and more about governance, reporting, and optimization. Providers that invest in proper tooling and licensing expertise will have a long-term advantage.

If you want help reviewing your Dynamics, SQL Server, and FVB setup, or improving your SPLA reporting processes, Octopus Cloud can support you.

Find out more about it here.