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
    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
  • 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.


Yammer Thread