Microsoft MVP Award 2017 for Business Solutions

I have been awarded the Microsoft Most Valuable Professional (MVP) title for the 2017-2018 cycle. Being a Microsoft MVP is a recognition that only a handful of people within the Dynamics AX family have received. It is a great honor to be ranked among the bloggers, community volunteers, speakers and experts that I have been learning from for the past 15 years and have met at various projects, events and conferences.

Microsoft MVP

As a Microsoft MVP by getting more networking opportunities and access to the product teams it is becoming easier to share relevant, fresh content, exchange information with the professionals in the industry, and keep a finger on the pulse of new trends for Satya’s vision about business transformation.

This is giving an additional kick and motivation for releasing additional publications, and doing more community and conference participation.

See you guys around!

DAXRunBase / 2017-08-03 / Microsoft Dynamics AX / 1 Comment

Add call stack to InfoLog messages

The main communication channel for our ERP users in case we want to tell them something is via the InfoLog messages within Microsoft Dynamics AX. In case we get an error or a warning, the technical staff does not receive the details required to troubleshoot the issue much easier. In this post I would like to show you how to send the X++ or .Net CIL call stack to InfoLog messages.
Microsoft already has an article on this for AX 2009, but that was before the AX 2012 IL code execution for server-side code, so it needs slight adjustments.

My changes got the following improvements:

  • Can handle X++ and CIL execution.
  • Users only see the call stack when clicking the message line due to filling it with whitespace.
  • Specific users could be excluded from receiving the call stack, we are doing this for our service accounts such as the batch execution account. We are also excluding our eCommerce portal customers from seeing a call stack, which are the Claims-based users.
  • Current database server/name and user account is included in the message, in case we are storing the errors in the Event log and would like to know who had the problem.

Here is the example output:

call stack to InfoLog


DAXRunBase / 2017-07-20 / AX 2012 / 0 Comments

Troubleshooting batch jobs in AX

If your batch jobs are seemingly not executing in Microsoft Dynamics AX, there could be a multitude of reasons. This guide will help with troubleshooting batch jobs in AX by listing the possible causes and providing solutions for each points.

Initial setup

It is important to define what is a batch job first:

A batch job is a process which will carry out specific tasks at a certain date and time running as a background process within the AX Application Object Server service.

We need to tell the system what is the process that we want execute, which consists of a Batch job as a header, and at least one Batch task which is the actual processes running. The batch jobs can be grouped together by their roles with the help of a Batch group. If none is provided, it would still classify as one called the “Empty batch group”.

In typical AX Production installations you would want to isolate your batch execution from the rest of the business, so you would dedicate an AX AOS instance to be the batch server. Under System administration module > Setup > System > Server configuration make sure you set the following:

  • Is batch server checkbox enabled for your dedicated batch server
  • Batch server schedule has minimum 1 active thread, and the Start/End time has the default value of 00:00:00 – 23:59:59 to allow batch execution any time during the day. I typically set up 2 threads per physical CPU core available (16 for the recommended 8-core AOS for a Prod instance)
  • Batch server groups must have at least the Empty batch group listed, but if you associate batch jobs with other batch groups, they must be also allocated to one of the active batch servers.

A more detailed explanation and generic setup can be found in the online MSDN documentation with great detail, I would recommend to read through all the sub-pages to get a good understand and to validate your initial setup:

With a fresh AX deployment you have two batch jobs created out of the box, you can read up a bit about them and also with possible issues associated with them in the following article:

Stable environment

The most important prerequisite for successfully running batch jobs is to have a stable environment. In majority of the cases the biggest cause that batch jobs keeps sitting in a Waiting status is that the application is not stable.

Validate the following points to make sure your environment is stable:

  • You have a fully compiled Application Object Tree (AOT), that has 0 errors for all nodes. You must compile the AOT at least one time, after which you may use the axbuild tool for consequent, faster compilations
  • After you are sure that your system is error-free, you need to Generate Full CIL without errors
  • Restart the AOS instance after the above steps to make sure the assembly and the netmodule DLL files are correctly deployed
  • Once the AOS instance is back, verify if the Standard AX AIF ports do not have any stop signs under System administration module > Setup > Services and Application Integration Framework > Inbound ports.


Once your environment is considered to be stable, the next problem is your Technical staff (developers). Leaving active soft or hard breakpoints (text in X++) in the system in combination with attaching to the AX AOS service process with Visual Studio will stop the execution of all threads for the server, including batch jobs.


  • Disable Breakpoints for X++ code running on the server, Global breakpoints and hot-swapping of assemblies in Windows Control Panel > Administrative tools > Microsoft Dynamics AX Server Configuration Utility
  • Connect to the SQL Server instance that hosts the AX database, and remove breakpoints by running the following SQL statement against the data DB:
  • Restart the AX AOS service dedicated for batch execution to ensure there are no active debugging sessions going on

Execution account

Batch jobs are running under the AX AOS service account for the outside world, so if you are for example accessing files or folders in a network share, you have to make sure the AOS execution account has appropriate security permissions.

If someone is using a Development environment, it is common to run the AOS service under the developer’s active directory account. They usually forget to change the password also on the AOS service and restart it once the company policy forces them to set a new password every couple of months, which can break different parts of the system including batch job execution

For processes within the server thread they are impersonating the AX User who has scheduled the batch job through Windows Integrated Security. On Production instances the companies should be using one or more dedicated service accounts for batch execution. Selecting Right click > Run as a different user on the AX shortcut or client executable would allow you to open the AX client as a different account to schedule the batch jobs.

In many cases the user or batch accounts are locked out due to mistyping passwords (if the domain admin forces password lockout policy), in which case your system engineers should re-enable them in the Active Directory. A locked or deleted AD account is also a common cause why batch jobs are not running.

One more important setting is to associate the correct Security Roles for the batch execution accounts (System User is a must, and in many cases System Administrator are being used), and the account must be Enabled.

64-bit assembly

Batch jobs are executing within the Microsoft Dynamics AX Application Object Server service, which is a 64-bit process. In case you would like to call methods which require a client-bound process (such as trying to display a report on screen, open a form, ask for user input), or a 32-bit DLL/assembly, that is not going to work.

You can read up more about the problem and a possible solution here:


Within the AX Server configuration, you could define that during what time period how many batch threads could operate parallel in each AOS services.

If multiple batch jobs or tasks are scheduled to run at the same time, it is possible that the maximum number of threads are already exhausted, making addition Waiting batch tasks to be idle, until another thread becomes available. One example is the MRP scheduling with multiple helpers, which is essentially just splitting the batch job to multiple smaller parallel tasks, each consuming an available thread.

If everything else fails for troubleshooting batch jobs

The ultimate tip for troubleshooting batch jobs is to set up Visual Studio for AX debugging, attach to the Ax32serv.exe process, and place breakpoint on \Classes\BatchRun\serverGet*Task methods, which are being called by the kernel process for fetching the next available batch jobs to be executed. Stepping through the code should allow you to see what is missing.

Other relevant posts:

DAXRunBase / 2017-07-02 / AX 2012 / 0 Comments

1 2 3 11