Microsoft has been extremely busy the last few months updating their user licensing functionality as they get ready for enabling license enforcement later this year.
Let’s look at some of the updates that appear in the 10.44 release!
#1 – SysAdmins ‘Really’ Do Not Require A License
I have written about this topic in the past, previously for a user to not require a license they would have to be assigned only the SysAdmin role. If any other roles were assigned to the user, they would have to be licensed properly for these additional roles. With this update, if a user is assigned the SysAdmin role it does not matter what other roles are assigned to the user, the user does not require a license.
#2 – License Type of ‘None’ No Longer Exists
If you’ve been reviewing licenses in the past you may have noticed some objects in the system actually required a license type of ‘None’. Microsoft is making a push to identify these objects and correctly license them going forward. Because of these changes to object licenses, you may notice that some license requirements for users, roles, duties, and privileges changing when you update to this version.
#3 – Further Deprecating Legacy User License Reporting Functionality
Microsoft is continuing their push to deprecate / hide / remove legacy user licensing reporting. The following areas that provide licensing information will either be hidden / removed in a future release but have been deprecated in the current release:
- The View Permissions report within the System Administration -> Security Configuration form.
- The license information provided when assigning a role to a user in the System Administration -> Users form.
#4 – Change to License Methodology
I kind of ‘buried the headline’ here a bit in the sense that I think this is the biggest change to licensing we have seen to date. In 10.44 Microsoft has deployed a number of new tables which are storing the licensing information being analyzed within the Power Platform Admin Center (PPAC). Below is a (non-comprehensive) listing of tables and queries I have found / am using to help determine the license requirements.
Before I jump in, I wanted to give a huge shout out to Brad Bateman who helped document and confirm some of my findings below.
LicensingEntitlementObjects
A listing of all objects within the system.
LicensingAllSKUs
A table that stores all current licenses, their priority order in the analysis, and the ‘group name’ they are a part of.
LicensingElementsRequiringEntitlement
This table stores the objects that have a license requirement.
LicensingAllEntitledPermissions
A table that stores the association between an object and the licenses that would meet the requirements for assignment.
Object License Query
This is a query I developed that joins the above tables to help determine the lowest license requirement for each object.
LicensingRolePermissions
This table stores the role -> object -> AccessLevel assigned.
LicensingRoleRequirementsSummaryView
This view shows each role in the system and the license required, it also shows how many objects within the role are entitled, not entitled, and not required for licensing. This view is used to populate the top grid of the License Usage Summary report in the User Security Governance feature.
This view also exists at the duty / privilege level at:
- LicensingDutyRequirementsSummaryView
- LicensingPrivielgeRequirementsSummaryView
LicensingRoleRequirementsDetailedView
This view shows the detailed version the above view and shows the role -> object -> license assignment. This data is used to populate the detailed bottom grid of the License Usage Summary report in the User Security Governance feature.
This view also exists at the duty / privilege level at:
- LicensingDutyRequirementsDetailedView
- LicensingPrivielgeRequirementsDetailedView
LicensingUserRequirementsDetailedView
This is the same view as above at the user level, I wanted to call this out separately as this data can potentially show which objects a user is assigned that are entitled vs not entitled so could potentially be used to help diagnose user licensing issues.
This data is what populates the detailed grid within the user licenses tab for the License Usage Summary report in the User Security Governance feature.
Licensing Methodology Changes
The above represents the first real change to the underlying licensing methodology that Microsoft has made since 2019 and structurally changes how D365 is licensed.The biggest changes being:
- Objects themselves actually drive all license requirements from Team Member -> Activity, to License SKUs (Finance, SCM, Commerce, etc)
- We move away from ‘privilege based licensing’ where the privilege assigned to the user causes certain license SKUs to be required for a user
I am in the process of updating my user licensing documentation on my blog to reflect these changes.
My recommendation is to start to review any custom security to validate if any license changes have occurred as it is very possible that a previously designed role, duty, or privilege that required a particular license previously might have changed.
Other Resources
D365FSC License Enforcement Overview
Missing Licensing Reports in D365FSC
I’m also finding a bunch of cases where “inquiry only” duties and privileges that previously required a Team Member license have now been changed to Activity. Frustrating.
Hi Alex,
Our company works actually on licensing D365 users following MS FnO licensing enforcement.
The information “User Count Report”, which let us know if user need an operations, activity or team member license, has disappeared from LCS report and it is not easy to determine which user consumes which license.
We’ve also discovered a strange behavior in PPAC. Many Entra ID users who have access to D365 FnO don’t appear in the licensing report genereated in PPAC.
Do you know what might be causing this problem ?
How can we force user synchronization between D365 and PPAC knowing that all users are well synchronized with Entra ID ?
Thank you for your help.
TC,
Microsoft is deprecating ‘legacy’ licensing reports including the User License Count Report: https://alexdmeyer.com/2025/05/27/missing-licensing-reports-in-d365fsc/
Their stated final goal is that PPAC should be the ‘source of truth’ and push this data back into D365FSC and that the new User Security Governance feature should show this new data and instead of trying to back fit these changes into other licensing reports they have decided to deprecate them.
There is no current way to ‘force’ a sync between PPAC and D365FSC, in fact the PPAC report currently states that the data for their reports are updated every 72 hours. They have stated they are hoping to shorten this time but have not stated when this will happen or how often the sync will occur.
There are also still bugs in the licensing reports from PPAC / D365FSC (as you are finding) but there is not centralized place (that I know of) that documents all of these issues with a stated fix timeline.
We are kind of in a tough spot right now with multiple reports stating different requirements, and a lot of end users / partners / ISVs are in the same boat.
Hello Alex,
thanks for another very insightful article – as per your usual very high standards
One question with regards to the 72 hours PPAC report update window. Does that mean that when I make a change to a custom security role / duty / privilege, I will not see the true impact on licensing until the next PPAC report refresh?
Jozef,
The way it has been described to me is that when making security changes, the ‘enforcement’ piece will be immediate (meaning the user will immediately have be assigned the correct license to log into the application) but the ‘reporting’ side can take up to 72 hours to be reflected in PPAC. MSFT has also mentioned they are trying to reduce this time but have given no specifics on what that will be or when it will be implemented.
Hi Alex,
May I ask you, how you managed to populate the mentioned tables? I see these tables and views in my AOT, but I cant find the way to populate them as you have.
Thank you for the answer.
JS,
I pulled this data from a 10.44 UDE instance I have deployed that is connected to PPAC, these tables are not populated on my 10.44 CHE deployments.
Hi Alex,
Thank you, I can see some data now, it´s exactly what i needed.
There is one think that catch my eye and it´s in table LicensingAllSKUs. There is a field Priority. First thing is, that in my table it is not same as in yours, since what I see is everything multiply by 10. So Finance has 70, SCM 80, Team Member 20 etc.
Second thing is that there is no license with the same priority. I thought that SCM and Finance are on the same level but these new tables shows it different.
Do you now why is that?
Thank you for the answer.
JS,
So since I took that initial screenshot the ‘Priority’ field on the LicensingAllSKUs table has updated to be from 10 -> 100, these priorities help define the order in which the licenses should be applied to a user. If a user requires multiple licenses, the highest priority license should be the base while lower level licenses should be attached.
Your question about Finance & SCM licenses brings up another attribute on this table, which is the ‘Group Name’. These should the ‘tiers’ of different licenses. So while the Finance, SCM, and Commerce licenses have a different priority they are all within the same Group Name / tier of ‘Base – Commerce, Finance, Supply Chain Management’.
How did you run SQL query against tdb? did you update your cloud hosted environment to 10.0.044?
Ray,
I ran these queries against a deployed 10.44 UDE instance, I followed this guide from Laze Janev: https://www.linkedin.com/pulse/access-your-ude-database-through-sql-jit-laze-janev-dbgre/
As always, a great set of insights — thank you!
Could you please elaborate on the following two points?
“Objects themselves actually drive all license requirements from Team Member…”
“We move away from ‘privilege-based licensing’…”
Also, do we have any official source or documentation explaining how the object itself determines the license requirement?
And specifically, is there any known impact on ISV forms that use custom objects?
We currently assign either Activity or Team Member licenses based on the actions/operations performed.
Would appreciate any clarification or examples.
Udaya,
“Objects themselves actually drive all license requirements …” – what access you have to objects within the system will dictate the license required for a user, role, duty, or privilege.
“We move away from ‘privilege-based licensing…” – in previous blog posts, I described the previous process of how what privileges were assigned to a user, role, or duty actually determine the license SKU required (Finance, SCM, Commerce, etc). This is all now done at the object level.
Also, do we have any official source or documentation explaining how the object itself determines the license requirement? – No, this is all done in the ‘black box’ of PPAC. I have asked some MSFT resources for the logic used to determine the object -> license association but they have not provided that publicly yet.
And specifically, is there any known impact on ISV forms that use custom objects? – I have not seen this happen in the ISV I am in charge of but I would highly recommend all ISVs and anyone doing customizations for clients to validate this within their solution.
We currently assign either Activity or Team Member licenses based on the actions/operations performed. – Unfortunately, it is not always as easy as ‘this user should be an (insert license type) because they do (certain business process). It really comes down to w’hat objects is this user assigned at what access level, and what license is required for that object access’.
Thanks a lot for sharing and helping the community!
It’s a bit surprising—and admittedly frustrating—to learn that Microsoft is moving away from privilege-based licensing. This change also implies that all the work we’ve done setting “Maintain” and “View” license values at the menu item level may no longer be relevant going forward.
Looking forward to the July preview release for new updates.
Hello Alex,
our costumers are skipping every second update. So we have some costumers who had recently update on the 10.43 and are waiting for the 10.45. Do you know what this mean for the license reporting? Will we have a functional licensing with the 10.43?
“If any other roles were assigned to the user, they would have to be licensed properly for these additional roles. With this update, if a user is assigned the SysAdmin role it does not matter what other roles are assigned to the user, the user does not require a license.”
How does this work with the older 10.43 Version? Will the PPAC look on the dynamics version and decide after that, if you can use roles beneath the system admin role?
Nicolas,
If you are still on 10.43 then you will have the ‘legacy’ licensing reports available to you until you update to 10.45, but MSFT has stated these reports are deprecated and the information they provide is no longer accurate.
This will also means other updates listed in the blog (including the change to the SysAdmin license reporting) will not apply until you update to 10.44 or newer.
Alex,
I am currently getting a preview via the UGS into the systems via function management. The problem with the UGS is well known and Microsoft has not answered me whether the new UGS V2 will also come into 10.43 via the function management.
I now understand you to mean that all these features you described in your post will only come via 10.44 and there is no way to do any meaningful reporting with 10.43.
If this is your impression or the impression of the Microsoft contacts you mentioned, then we have to prepare our customers for the updates very quickly. Until now we had hoped to stay on 10.43 and report everything via the previews.
Nicolas,
I cannot speak to whether Microsoft will back port any of the changes from 10.44 into previous versions as I have not heard any confirmation one way or the other.
I have been told that the licensing reporting within 10.44 is ‘stable’ from a Microsoft perspective.
Alex,
Love the SQL code.
Question, the new structure identies what license(s) is required, but does the service actually enforce that license requirement?
When a user performs work, will the service actually compare the object they are using with the license(s) assigned to them and stop them if it’s not correct?
Or is the new licensing structure really about auditing. In other words, is it a method to compare what a user has done (and the security roles) assigned to them with the license(s) they have?
Here’s my dilemna. We use a combination of Power Apps and other custom solutions to update the D365 data. Everyone is assigned security roles and everyone has a license (that we think is the right level) as well. But since we’re not going through the main UI, how will D365 be able to enforce the license requirement?
Thanks…
Andy
Andrew,
The license enforcement for D365 will occur during the sign in process. The framework will check to see what roles the user is assigned and determine which license(s) the user should be assigned. If the user is assigned those licenses, the login will continue as normal. If the user is not assigned the correct licenses, the login will be stopped and the user will not be able to log in.
This ‘hard enforcement’ will not happen until Nov 1st, 2025 but I have been highly recommending end users to be proactive and validate if their assignments are correct before then to avoid a ‘licensing fire drill’ later this year.