Logging Infolog to Event Viewer

This is probably a bit far fetched in real life, but still a cool feature built in AX 2012, and I really wanted to make a new blog post after a long summer vacation. Maybe someone will enjoy it still. :-)

This is already explained on the MSDN article "Propagate Infolog Messages to the Windows Event Log [AX 2012]", but I thought I'd throw in some screenshots just to make it even more appealing.

Obviously, this will only log client side as the Infolog push its messages to the client, and this tracing feature runs in the client scope.
There are some options to introduce server side logging using for example log4net. It is pretty good covered in this blog post, but it would require rewriting X++ code in order to trigger logging.

Developers will have the ability to use the static Debug::printDebug()-method to push any string to the debugger output window. These messages will open up the debugger, unless it isn't already running, and unless the output window is hidden, it should reveal the strings on the Debug-tab. Remember, in AX2012 only the users who are in the local (machine) usergroup named "Microsoft Dynamics AX Debugging Users" will see the debugger, as explained here.

Anyway, let us have a look at the easy and quick logging of Infolog messages.

1) Start by locating the ax32.exe.config file, normally located under "C:\Program Files (x86)\Microsoft Dynamics AX\\Client\Bin\"

2) Open the file in notepad and add some additional XML sections in order to trigger the functionality. You can copy from the MSDN article or just type in what I have used.

3) In order to test this, let us create a simple job that triggers a Info, Warning and Error message.

4) Then let us open the Event Viewer and filter the log, just to focus on the events we just created.

4) Notice the Info-message was not included in my example, due to how I defined the switchValue only to include warnings and errors.

Now imagine having this set on a busy terminal server where everyone would be using the same logging setting. Depending on your requirements you could use this to preserve the most recent warnings and errors thrown to the client and browse through them when end users complain about all sorts of "mysterious" errors. Who haven't experienced end users complain about an error they can't remember the content of? Now you can go back and look in the Event Viewer and find it - hopefully.