Licensing Advent Calendar – Day 18 – Microsoft motivation

While providing a lot of content related to the Dynamics 365 user license enforcement, I didn’t elaborate on the motivation from Microsoft to go for enforcement on assigned licenses. Curious? Continue reading.

License enforcement

On March 28, 2025, Microsoft announced in a blog that it would start enforcing licenses soon. The blog is still available here, but with particular updates applied: Simplifying License Management for Dynamics 365

A lot of people wondered why the license enforcement would come into place. I will try to provide my thoughts on this. The explanations in this post are my own opinion and don’t necessarily have to be the exact reason from Microsoft’s point of view.

Let’s start several years ago. Microsoft released the first cloud-based version of Dynamics 365, which initially was called Microsoft Dynamics AX. This was without a year indication, where the latest client/server product was called Microsoft Dynamics AX 2012 R3.

When clients acquired licenses, they were made visible on the Microsoft admin portal next to other licenses such as Office, SharePoint, CRM, and more. Where these other products were validating the licenses, this was not enforced in Dynamics AX. After several name changes of the product, Microsoft also split the product into multiple product SKUs, such as Finance and Supply Chain Management. About that time, in 2019, Microsoft mentioned to me it wanted to enforce the licenses, just like any other solution they offered. This is fair, as there shouldn’t be a difference between assigning a Microsoft 365 or Dynamics 365 Sales license and Dynamics ERP licenses. At that time, the product split was not stable as Microsoft was also working on Dynamics 365 Project Operations as a replacement for the “CE” based PSA and “F&O” based Project Management and Accounting modules.

As a first step, Microsoft mentioned in the documentation for creating users to assign a product license as part of the process. However, this instruction was not followed by a lot of organizations. See: Create new users – Finance & Operations (Assign a license to a user) | Dynamics 365 | Microsoft Learn

In the meantime, Microsoft was working on enhanced license reporting and introduced the privilege-based license calculation, tagging the product SKU for base licenses per standard privilege. As a fallback, in case no license was listed for a privilege, the license indication on menu items was used. Together with this update, a report was released called the User License Estimator. This report showed only the base product licenses, where Operations – Activity and Team members were not shown. Also, the report did not have a count per license SKU.

Still, with this report, it was too hard to let clients know if they are compliant with the number of licenses.

Note that together with the new calculation logic performed in an external microservice, this report has been deprecated and is not available anymore in recent Dynamics 365 versions.

In the meantime, Microsoft was able to see from telemetry that in production environments, more users were active and more products per user than licenses were acquired. Some organizations acquired the minimum number of licenses (20), but are using the application with, e.g., over 200 users. So, effectively, Microsoft Dynamics 365 F&O was the only ERP in the world where you could use the system with free users. When you are aware of that, then prioritizing a license enforcement where all users should be assigned a license is logical.

When Microsoft acquired the Security and Compliance ISV from Executive Automats, a License Usage Summary page with the required number of licenses per SKU was now available. This might have been a trigger for Microsoft to start the license enforcement.

After a lot of feedback from clients, Microsoft postponed the initial planned license enforcement. The privilege-based calculation logic was not consistent in case copies of existing security objects were used. To bring a consistent license calculation, an object-based license calculation was introduced, where the form, as shown above, was changed to its current layout. As part of this change, all previously used metadata, such as the list of SKUs per privilege and the license properties on menu items, have been deprecated. You can’t rely on this anymore. Instead, a list of SKUs for each securable object part of the license is maintained in a new microservice.

Of course, there are a lot of clients compliant or almost compliant. During some license assessments this year, I have seen enough organizations that wanted to be compliant with licenses, but due to incorrect or inconsistent reporting, it was too hard to be in that position. Anyway, the effort for license enforcement was initially underestimated by Microsoft. That led to a lot of work to be done by not only clients and partners, but also Microsoft itself. For me, the top 2 focus areas this year were Copilot and license enforcement.

There is more…

During the Advent period, each day in December, I will share some thoughts and tips related to the Dynamics 365 user license enforcement. If you have questions about this topic, feel free to contact me via LinkedIn, the comments section below, or the contact form on this blog. I will then either update one of the planned blogs for the coming 24 days or answer questions in a new post.

Dynamics 365 Licensing Enforcement Advent Calendar

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!