Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support Teams Worldwide

Data collection for the Named User License Counts report in Dynamics AX 2012 R3 Cumulative Update 9 and later

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

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 systems (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.