Search This Blog

17 July 2011

Redefining (mapping) Dynamics Ax EventLogs

Ever tried to monitor Dynamics Ax events with a monitoring tool that does only work with EventIds? Dynamics Ax does unfortunately writes nearly all relevant events with the eventId 110 (here a complete list). It is possible to create your own events, but it isn't possible to change the standard events.
For that reason I scripted a small tool that collects the events that are defined in a list (by EventId, EventType and a fragment of the EventMessage) from a list of servers (SourceServers)  and writes them locally based on mapping rules defined in the Xml-configuration file. so that it is now possible to create fine grained eventLogs. The scripts creates for each SourceServers a cookie to store the creation-DateTime of the last message, so that the script just reads out all newly created messages. Here's an example for an configuration

    
        
              
        
     
      
     
    

The XmlElement SourceServers does define the list of servers with its logName (for standard Ax EventLogs it is "Application"). The XmlElement Events does define the mapping-rules with:
  • EventId (id)
  • The part of the message (no wildcard character)
  • EventType (Information, Warning, Error)


  • The local eventSource (defined with the attribute destinationEventSource on the XmlElement Events) is automatically created if it does not already exist. The eventSource needs to be unique on the machine (1), so you can only define it once and not use it with another eventLog. You need to run the script with the EventPackage-name as argument (see documentation in the script) as with Administrator rights for the UAC. Please be aware that the local path is actually security reasons hardcoded for:
    $scriptPath = "C:\Scripts\MapEventIds\";
    
    This script is just an example. Feel free to customize it for your needs.

    Update: (23/07/11) Refactored the code so that it is now using the pipeline instead of referenced arguments. Please use the FQN instead of the IP to avoid issues with the machine name resolution. (hope that the cache on the WebServer refreshes the next hours...)

    No comments:

    Post a Comment