A while ago I blogged about the discovery issue I was facing regarding AX instances. This appeared to be only the tip of the iceberg as other AX-objects (Environment and Database) refused to show up properly for some instances. There were also some false alerts afterwards due to a possible oversight in the MP’s design.
This small article will quickly explain how to overcome these issues:
Make sure that all servers involved with the AX environment(s) are allowed to execute powershell-scripts
The AX 2012 MP relies heavily on powershell. Both discovery- and monitor logic are mostly setup in powershell. Like I mentioned previously, a Windows Server 2008 system doesn’t allow this kind of scripts to run by default. Therefore it is important to set the policy to allow scripts by running the following command in an administrative powershell window on each AX-related server:
This will allow the discovery to run properly
Hardcode a specific AOS instance/server in order to correctly discover the environment- and database-objects
While the first step worked to get the instances discovered, there were still some discoveries failing as the environment- and database-objects failed to show up for some instances. When checking the documentation I found a section describing how to ‘hard code’ the instance to use for further discovery:
To specify which AOS instance is used to run discovery and end-to-end monitoring
You can specify which AOS instance is used for discoveries and end-to-end monitoring in the SysGlobalConfiguration table in the Microsoft Dynamics AX 2012 database. The default is the first AOS instance that is installed.
Note: If the AOS instance being used to perform discoveries is unavailable, discoveries will automatically be run from another AOS instance.
By coding the correct instance/server combination in each AX-environment’s database, we quickly got those missing objects visible!
Finetune the long waiting batch jobs and tasks monitors to account for time zone differences (if necessary)
After all AX-objects where present, I was contacted by our AX-engineer that he received a lot of the following alerts:
- Long waiting batch tasks
- Long waiting batch jobs
What these monitors did was check for jobs/tasks ready for execution, compare their planned runtime to the actual time, and then alert on intervals greater than 30 minutes.
But when we checked the jobs/tasks using the AX-client, nothing seemed wrong.
A possible cause of this issue was brought to light when the AX-engineer remarked that the AX-database stores dates in the GMT-time zone format, while the server-OS’ are running GMT+2. So it seemed that a comparison was happening between a GMT time (the start-time of the batch/task) and a GMT+2 time (the actual server time). This would result in a 2h30m interval, triggering the monitors to go critical.
I decided to test this theory by overriding the ‘TimeIntervalThresholdInMinutes’-parameter of both monitors from 30 minutes to 150 minutes (2 hour time zone compensation + the default 30 minutes threshold). This made the monitors to go back to healthy green! While I’m not 100% certain this is the right fix for the right problem, it certainly seems so.
So far my experiences on working with the AX 2012 MP. I hope this post will help other people to get their AX-monitoring running with fewer hurdles as I did!