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 events
from 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) rather
than 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 parameter
with an xpath query, as in
"/q:*[System[(<xmlvalue=value>)]]"
For example, if you wanted to see all the so-called heartbeat messages
that appear in the event log announcing how long the system
has 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 so
got tons of XML-encoded event dumps. A small excerpt looked like
<EventID Qualifiers='32768'>6013</EventID>…<Level>4</Level>
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 the
security 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 both
the 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. Doing
so would yield something like the following:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[band(Keywords,
13510798882111488)]]</Select>
</Query>
</QueryList>
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.
End of Article
Register
