Skip to content
Microsoft Dynamics 365

You may be already familiar with the blog post of my colleague in which the background of the Named User License Counts report is explained.

Using the Named User License Count report

In this post, I would like to explain a change that was introduced in relation to this report in Cumulative Update 9 for Microsoft Dynamics AX 2012 R3.

In previous releases of Microsoft Dynamics AX 2012, data for consumption by this report were collected by the batch job “Named user license count reports processing” that was created automatically upon installation. This batch job was scheduled to run weekly and so data were up to date on a weekly basis. Starting with Cumulative Update 9, in AX 2012 R3 release, this data collection is initiated by kernel directly, each day at midnight. (See notes at the end of this post for more information on configuring a different time for this execution).

The change involved modifications in the application and in the kernel.

  • On the kernel side, invoking the X++ SysUserLicenseMiner::GenerateUserLicenseCountReportInfo() method is implemented.
  • On the application side, a new table SysUserLicenseMinerJobRun was created and is used to control the execution of this task in a multiple-AOS system (the task should be executed by only one AOS to save resources) and to hold the history on those executions.

It is to be mentioned that the update does not remove the existing batch job, so in consequence data collection will be taking place daily at midnight, invoked by the kernel, and once per week, invoked by the batch job according to its schedule. It is obvious that this batch job can be removed in systems that have this or a later update installed.

Each execution of the SysUserLicenseMiner::generateUserLicenseCountReportInfo() method is recorded in the SysUserLicenseMinerJobRun table. The information that is stored is the name of the AOS that executed the task (AosName), a flag if the task finished successfully (Finished), a GUID that allows for uniqueness (ID), the date and time when the task was completed (modifiedDateTime), and the account the record was created by (modifiedBy).

Note: The Visible property is set to No for the fields of this table. To see the full information in the table browser it is required that this property is set to Yes. Alternatively, you can examine the information on the SQL Server side.

In multiple-AOS systems, when the first AOS invokes the task it creates a record with an empty ID {00000000-0000-0000-0000-000000000000} in this table and locks it. Only the AOS that locked the record will perform the task. Any other AOS will fail when attempting to lock this record when it is locked by the first AOS and so collecting data will be skipped by the remaining AOS instances. Failures in invoking the method by the kernel are logged in the Event Log.

You will find in this table also records for this method being invoked by the batch job if the batch job has not been removed from the system. There will be one record per week with the user name of the AOS service account of the batch server instance. While you will find a completed batch job in the Batch job history for those records, you will not find any for the records created through kernel invocation because it is not the batch job that is invoked by the kernel – it is the user license miner class’ generateUserLicenseCountReportInfo() method.

It is recommended to install hotfixes related to this report that were generated post CU 9 in systems which are not at the latest patch level. Hotfixes can be found using Issue Search in LCS.

Note: This change was not implemented in the previous AX 2012 releases.

Note: By default, the task is invoked by the kernel each day at midnight. However, if the requirement is to move this task to another time of the day it can be done by setting an offset value (in seconds) in the registry. For example, to move the execution of this task by two hours to 2am in the night, a String Value with the name licensemineroffset and value 7200 should be added in the registry under the current AOS server configuration key, which is AOSPROD configuration in the example below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dynamics Server\6.0\01\AOSPROD
Name: licensemineroffset
Type: REG_SZ
Data: 7200

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!