At first glance, this might seem like a good thing but it’s not. All BizTalk developers know and depend on the event viewer log “Application” to debug deployed BizTalk code. Not to mention how monitoring software tend to work.
Many monitoring scenarios are based on the fact that BizTalk writes errors to the application log. These errors are reported to who ever might be interested and the problem can be solved.
So imagine what would happen if your production environment suddenly stopped writing errors and even warnings to the event log!!!
This happened to me and it has also happened to a forum poster called BizTech and I posted about the problem as well.
The problem: BizTalk cannot write to the event log and it does not report any errors nor warnings what so ever, also nothing can be found about it in any other logs. If messages are suspended, these can be found in the BizTalk console with error messages as per usual.
However I encountered an even worse problem: I posted a message to SQL server using the old (non wcf) adapter. This message was malformatted and just got stuck as “Active” in the BizTalk console. The error information could not be read as the message wasn’t suspended and there was no information in the event log.
The solution: Some “Group Policy” update that was implemented by “the IS/IT”-guys updated settings in the registry. This setting was enforced after a server restart that was due to OS updates. So this has nothing to do with the OS updates themselves. As might be the more usual case.
The policy updated this setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application and added a key called CustomSD. This key customizes the access rights to the event log and looks something like: O:BAG:SYD:(D;; 0xf0007;;;AN)(D;; 0xf0007;;;BG)(A;; 0xf0007;;;SY)(A;; 0x5;;;BA)(A;; 0x7;;;SO)(A;; 0x3;;;IU)(A;; 0x2;;;BA)(A;; 0x2;;;LS)(A;; 0x2;;;NS)… (The content of this key can be understood reading the article.)
In order to make BizTalk start writing errors again, I simply removed the whole CustomSD-key. Then the IS/IT-guy had to update the group policy setting to not rewrite it, the server was restarted and now it’s working again.
I have never been so happy about seeing BizTalk errors!
A side note: “BizTech” solved the problem by reinstalling but is very limited as to what was reinstalled and how it was related to the problem.
Also, I have absolutely no idea as to how the Group Policy was updated. One of my lessons in life is to leave IT-Pro stuff to the IT-Pro guys and gals.
If you have any input about this problem I welcome feedback. Don’t hesitate to leave a comment, or drop me an e-mail.