Monitoring Server Core Event Logs

Now that Windows Server 2008 Server Core has been available for half a year, I’ve had the chance to talk to a lot of people about it. Some people flatly disbelieve that anyone would try to run a CLI-based server. Recently, someone asked, “How can you ‘run’ a server when you can’t see how well or badly it’s running?”

Remember, although Task Manager is a GUI tool, it’s one of those GUI tools (like Notepad and Regedit) that will run in Server Core’s very simple GUI. But what about monitoring a Server Core system’s event log? Clearly, the Microsoft Management Console (MMC) Event Monitor snap-in doesn’t work on Server Core, but Server Core (and Windows Vista) sports a powerful command-line event-log query and control tool called Wevtutil (wevtutil.qe), which dumps eventsfrom any log.

The command’s syntax is best described through example:

wevtutil qe system /c:1 /rd:true /f:text

This command queries (qe) the system (system) event log, displays the first event (/c:1), starts from the most recent event and works backward (/rd:true, which means “reverse direction” or “start from the most recent events”), and displays the data as text (/f:text) ratherthan as XML.

You don't want to waste your life analyzing gazillions of event-log entries, so you’ll need some sort of filtering ability to separate the wheat from the chaff. To specify query filters, you can add a parameterwith an xpath query, as in

"/q:*[System[()]]"

For example, if you wanted to see all the so-called heartbeat messages that appear in the event log announcing how long the systemhas been up, you’d type

wevtutil qe system "/q:*[System [(EventID=6013)]]" /f:text

I didn’t include either /c: or /rd: because I wanted to see all the events and didn’t care about the order in which I got them. I constructed the query text “EventID=6013” by looking at a large dump of event-log entries where I didn’t include the /f:text parameter and sogot tons of XML-encoded event dumps. A small excerpt looked like

6013…4

Comparing those snippets of XML to their text version told me first that the XML attribute name for the event ID was EventID, and ID 6013 corresponded to the system-uptime messages. Notice the XML attribute Level: A brief comparison with the text version of event-log entries showed me that a Level value of 4 meant information, 3 meant warning, 2 meant error, and 1 meant critical. (There are also events with Level values of 0, but in my experience you find them only in thesecurity logs; they’re the audit-success and audit-failure entries.)

To see just the critical event log entries in the system log, I’d type

wevtutil qe system "/q:*[System [(Level=1)]]" /f:text

By including “and” or “or” in your query criteria, you can see boththe critical and error log entries:

wevtutil qe system "/q:*[System [(Level=1 or Level=2)]]" /f:text

I know; this all looks a bit difficult. Fortunately, there’s a way to cheat. Suppose you want a filter for the security log that will show you only audit failures and audit successes. To do that, you’d go to a Server 2008 or Vista system with the full GUI working. In the GUIbased Event Viewer, you’d right-click the security log, choose Filter current log, and form the query you want, through the GUI. Then, you’d click the XML tab on the Filter Current Log dialog box. Doingso would yield something like the following:

    *[System[band(Keywords,  13510798882111488)]]  

All you need to do is grab the bracketed portion of the third line, make an RDP connection to the Server Core system, and paste the code into a Wevtutil query to get the following:

wevtutil qe Security "/q:*[System[band(Keywords,13510798882  111488)]]"

Of course, I could then add /c:, /f:, and other options, but that would do the trick.