During the set up some 2012 environments lately, we got warnings like
An error occured in writing to the event log on machine <DBServer>: cannot open log for source 'Microsoft Dynamics AX - AXUtil. You may not have write access.
when we're using the axUtil or perform actions where the axUtil tool is used behind the scenes.
It seems the problem occurs when the account running the AOS instance does not have sufficient privileges on the database server hosting the AX database.
You can go all wild add the AOS service account to the administrators group on the DB server. Or you can handle it more suble by just granting that AOS service account write access to the application log.
Windows comes with a nifty tools (called 'wevtutil') to regulate this. You can read all about it here.
What we did to solve the issue is:
- open an elevated command prompt on the DB server
- run 'wevtutil gl appication > c:\temp\out.txt', which will give you a textfile containing the security settings for the application log
- from that texfile, you copy the (seemingly uncomprehensable, but all part of MS's security descriptor definition language (SDDL)) expression that's after the 'channelAccess: ' keyword. This is the string that actually defines who has (or hasn't) access to the application log
- now you need to make sure the AOS service account is added to that string. I took the easy way and gave all 'authenticated users' the 'file write' permission by adding '(A;;FW;;;AU)'.
- the last step is to send that modification back into the system using the 'sl /ca' option on the wevtutil command: 'wevtutil sl Application /ca:<the modified channelAccess string>'
I got my inspiration on 'The Raven Report' blog, so it's only fair to mention that.