Vista Event Log Changes

As you may already know, Microsoft significantly changed the Windows event log in Windows Vista. I always found the Windows event log to be a very well designed logging infrastructure, at least compared to the logging facilities that are available in other major network operating systems. The Windows event log however hasn’t changed much since it was originally included in Windows NT. It has actually been 13 1/2 years since the core event log service and event viewer underwent a major improvement – other than updating security event ids to accommodate new events related to various security components – Windows NT 3.1 was first released in 1993. I have never actually seen the event viewer in Windows NT 3.1, but Windows NT 3.51’s event viewer for example was not too much different than Windows 2003’s.

So it appears that Microsoft finally realized that a good system can be improved (especially with compliance becoming more and more important over the last years), and so the event log subsystem, including the event viewer, appear to have been rewritten completely in Windows Vista and of course the upcoming Windows Server 2008.

As we are continuing to improve Vista support in EventSentry,  I will cover the changes that I believe are relevant to IT professionals that need to manage their event logs. Just as a side note, EventSentry already monitors the Vista event log since the end of 2006, however ES 2.81 currently accesses the Vista event log through the legacy API that Vista (fortunately) still provides to pre-Vista event log software.

Before I dig into the technical details about the new event log, I need to point out that Microsoft made a large amount of changes to the event log, and didn’t leave a stone unturned. While the overall logic is the same (you have event logs and events 🙂 ), a lot has changed under the hood.

While this will affect IT professionals that need to manage event logs (since they need to make sure that their software works with Vista & Windows 2008), it will affect software developers even more. While I like a lot of the changes that were introduced, and we all know improvements were overdue for a long time, I personally feel that the new event log has been over-engineered. A lot of the features that were added are a bit of overkill and accessing, especially writing to, the event log is significantly more involved with the new version (at least if you take advantage of the new XML functionality). I think it would have been better to gradually introduce improvements over the last 10 years, rather than ignoring the event log for a long time and then introduce a myriad of new functionality to it – some of which has yet to make sense (I will prove my point below with future posts).

In any case, I will get off my soapbox now and focus on the relevant changes that were introduced.

Keywords
One of the new fields added to the properties of an event is called “Keywords”. I find the most interesting thing about this field that security events now have their severity stored in the Keywords field instead of the Type field (Type was renamed to Level in Vista and later). As you know, events in Windows Server 2003 and earlier used to have their severity stored in the Type property of an event (Information, Warning, Error, Audit Success, Audit Failure), but in Vista and later the severity of security events (Audit Success, Audit Failure) have been moved to the new Keywords field.

This of course leaves the question what the Level is set to for audit events. Well, the answer is Information. All Audit Success and Audit Failure events have their main severity stored in the Keywords field, whereas the Level field is always set to Information. An Audit Failure event that is informational, yeah – that makes a lot of sense!

So in theory it would be possible to have an Audit Failure event logged with a level of Information/Warning/Error, but I am not sure how useful this would be. After all, an Audit Failure is an Audit Failure.

Why was this changed? I am not sure. After asking the head of the Windows Auditing Team at Microsoft I received an explanation that, unfortunately, failed to eliminate my confusion. The original Type field could obviously accommodate the two attributes (since had always been there), and there would have been room for even more. There was some consensus between the two of us that the keywords field, at least in combination with the security events, was maybe not implemented in the best way.

In EventSentry we currently ignore the Keywords field and merge it with the original Type field, so that you can search across Pre-Vista machines and Vista machines using the same field name.

So this is it for now, we will cover a lot more about the new Windows Event Log here in the future. As always, let us know if you have any questions or feedback.