Some administrators may hesitate to make the switch as many get in a comfort zone with tools. But since you can't read the new .evtx formatted logs on the older event-log viewers -- and the Vista/2008 event viewers will read the older .evt files -- it makes sense to use a Vista or 2008 machine for log analysis.
Improvements to Event Viewer
The event messages were significantly improved in the newest version. More descriptive troubleshooting help and links to the appropriate knowledge base articles have made interpreting the events easier for both new and experienced administrators.
In addition, the number of event logs increased. The standard logs -- application, security, system and server logs like DNS, Directory Services and FRS -- are in the Windows Logs folder. In the Applications and Services logs folder, there are several new event logs, including many application-specific ones like Microsoft Office, Internet Explorer and Windows PowerShell. The folders can be seen in Figure 1.
This takes troubleshooting to a new level. Instead of a few nondescript events lumped in the application event log, you now have very specific logs dedicated to an application. The logs shown will depend on the configuration of your computer.
Collecting data with Event Viewer
While reviewing event logs of one or two computers is fairly simple, diagnosing problems in an enterprise and getting information to support engineers is a different story.
I frequently work with admins who send me logs from a number of servers and clients when they're working on something like an authentication issue that is either affecting some -- but not all --users or has a random occurrence.
If you have to sort through a lot of data, it's important to filter it. Before Vista, the entire event log needed to be collected, even if you only needed a few hours to capture the problem period. While we can easily filter the resultant log, the logs can be huge.
Now there are several features that make collecting data more efficient. These include custom views and filtering on multiple sources, IDs and keywords. In addition, there are new features for saving filtered logs.
A custom view is basically a template in which you can define one or more event levels, different event logs, and multiple event sources and keywords as well as other categories.
For example, in Figure 2, the results would return critical and error status events from the application and system logs -- and they could then be filtered further.
This filter can be saved, reused and even exported to other machines. As a result, you can develop custom views to gather data for various situations. You might, for example, have filters to help gather data for authentication failures and hardware failures. As you work through various problem scenarios, save the custom views that can be applied in other situations.
Note that by default, the standard custom view is Administrative Events. This view filters all the Windows logs for critical, error and warning level events, and it provides a glimpse of important events without you having to go back and forth between logs and applying filters each time.
To apply a saved event to the custom view -- and automatically get results in the Event Viewer -- right-click on the Administrative Events custom view, and select Open Saved Log. For even more specific filters, you can manually edit custom views by clicking the XML tab and editing the XML code.
A noteworthy filtering feature, shown in Figure 3, allows you to save events in a narrow time period without having to save the entire log. To do this, select a group of events, right click and select Save Selected Events. This is useful when you need to get logs to support engineers but your company security policy prevents you from sending the entire log.
While the emphasis here has been on Vista and workstations, the new Event Viewer is available in Windows Server 2008 and later versions. On a server, these features are even more powerful. With all the new event logs created, the ability to slice and dice events from various logs and sources into a single view is a huge advantage in isolating specific events that you want to monitor over time and getting rid of the fluff that you don't care about. Transferring a filter to other logs and building a library of filters will further reduce administrative effort in problem solving.
Getting the right events under the right circumstances while limiting the data you have to sort through to get to those events will go a long way in bringing problems to a quick resolution -- in addition to aiding monitoring efforts.
ABOUT THE AUTHOR:
Gary Olsen is a systems software engineer in Global Solutions Engineering at Hewlett-Packard. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
This was first published in June 2010