With D365FO PU31/10.0.7 now becoming GA, we get our first look at Microsoft’s new licensing model within D365FO. I wrote about the high level changes in this post, but let’s look to see how this new licensing model is implemented.
First and foremost I wanted to try and find the association between the new license types and the menu items. I started by looking at menu item objects in the AOT and was unable to find anything pertaining to the new license types. The ViewUserLicense and MaintainUserLicense parameters still exist on the entry point objects and are still utilized to determine Operations, Activity, or Team Member license type requirements. But now the Operations level license is split out into Finance, Supply Chain Management, Retail, and Project. So we need to find the association between an entry point and the new license type.
User License Estimator Report
I found a new report that shows the user to new license type associations based on the user’s access. There report is found at System Administration -> Inquiries -> License Reports -> User License Estimator.
Whereas in the previous licensing model a user would have just required an Operations license, now there are different types of these ‘enterprise’ grade licenses and they are piece-meal. So one user can require multiple different ‘enterprise’ level licenses based on their access. So for example, in the previous license model the Alicia user would require an Operations license, now she requires a Finance, Supply Chain Management, and Retail licenses based on her assigned access.
How is the User License Estimator Report generated?
Since I was unable to find the new license type to menu item association in the AOT, I decided to try and determine how this report was being generated to see if that could give any clues on how the new license types were being calculated. The menu item output that drives this report is the SysUserLicenseEstimatorReport, by looking at how this report is generated we eventually find that the data source of this report is the LicensingServicePlansPrivilege table. By reviewing this table we can see that it shows the association between the new license type (SkuName column) and a privilege (PrivilegeIdentifier column).
But now the question is, how does this table get populated?
How does the LicensingServicePlansPrivilege table get populated?
If we look at the Object parameter that is associated with the SysUserLicenseEstimatorReport menu item output it directs us to the SysUserLicenseEstimatorController which immediately calls the processReport() method on the SysUserLicenseEstimatorDP class. In here we find the following code:
//forceRefresh is bool Microsoft.Dynamics.AX.Security.LicenseService.SKUAccessService::RefreshUserPrivilegeLicenses(forceRefresh); System.Data.DataTable dataTable = Microsoft.Dynamics.AX.Security.LicenseService.SKUAccessService::GetUserLicenseEstimates();
These two lines actual execute .NET methods found in the Microsoft.Dynamics.AX.Security.LicenseService.DLL, which hides the functionality that is actually used to populate the tables. Luckily if we grab that DLL and use an application like dotPeek we can see dig into these DLLs a bit further. The RefreshUserPrivilegeLicenses call from above appears to be the one that actually would populate the table, so if we follow that method call we eventually get to a method called GetLicensesPrivilege() which uses an embedded json file (LicensePrivileges.json) as the data source of how this is populated.
If we open this file up under Resources in dotPeek we can see that this contains the association between the new license types and privileges.
What does this mean for user licensing?
So now that we know how this report is being populated, what does it mean for determining user licensing?
- From the above process we can see that new user licenses are being determined at the privilege level and that association is determined at build time by a static file
- New user licenses are being determined in a different way than user licenses previously
- Previously licensing was being determined by ViewUserLicense and MaintainUserLicense property on the entry point, the new user license methodology is being done by associating a privilege with a license
- All custom privileges are not being evaluated for the new license type
- In a test I created a new privilege and assigned it a menu item that would require an Operations level license, when assigned to a user that user did not show up in the User License Estimator Report
- Any changes to out of box privileges are not being evaluated for the new license type
- If you add/remove entry points that would change license type to either a different Operations level license or to a lower level license this is not being reflected
My guess would be that this feature is still evolving and will be more solidified by the time the user license enforcement Microsoft has planned is deployed. I will continue working on this and if there are any updates, I will be making new posts on it.
Hi Alex, so if I understand this correctly, it takes into account all of the privileges assigned to a user? So if a user has multiple roles assigned, it looks at all the privileges across the roles? (I’m not technical so apologies if this is proven in the code).
That is correct, licensing analysis is always cumulative so if a user is assigned multiple roles (and therefore multiple privileges under those roles) with both the new and old licensing will look at all access assigned to a user to determine which license is required. With the new licensing model this is currently done at the privilege level so would look across all privileges assigned to a user.
Thank you very much Alex for this interesting article. Please make us updated if any progress.
Hi Alex, thank you for your post! Using this report to check out our customers licenses.
Recently, we created this report for the Customer who is using F&O enterprise functionality licenses (Unified operations plan – old licenses, before Finance and SCM) and were confused by report results – it indicated only Retail licenses instead of Finance and SCM licenses, do you have an idea why?
All versions of the report before PU36/PU37 are going to have incorrect results in one way or another as a number of bugs in this report were found. One of the bugs found was that the System User role was requiring a Retail license, so every user in the system was requiring an enterprise level Retail license. Unfortunately, unless you have a tool like Fastpath (with licensing reports I wrote) you will have to wait for Microsoft to release this version to have correct results.
Thank you for your comments!
I received an answer from MS today and it confirms your response, that there is no current plans to release the a new report, e.g. User License Compliance report. The current plans is to provide an additional update of the User License Estimator report as part of PU37 and port to PU36.