Before we jump into today’s script here are some current events:
Now for today’s topic…
Maybe I haven’t looked hard enough, but I’ve just not found any clear documentation aimed at IT Pros for what I am posting today. As an IT Pro type guy (not a .NET type guy) I have avoided XML for years. CSV and HTML are so much easier. XML seems to be a labyrinth of complexity in my mind, and it still is, at least from a PowerShell perspective. The object model is convenient, but trying to navigate it loses me. Yeah, I know XML makes the world a happy place, but I’m just not there yet.
Despite this disparaging disclaimer I believe I have drafted a script that will help many of us IT Pros as we weed through event logs (or ETL trace files or EVTX files).
The good: PowerShell works with event logs out of the box. You have two cmdlets: Get-EventLog and Get-WinEvent. Get-WinEvent is the one we’re all supposed to use now.
The bad: All of a sudden reading event logs gets complicated. The filtering in particular requires some crazy syntax. We are far removed from the simplicity of DUMPEL. PowerShell team blog posts from 2009 here and here attempt to make this look routine. Um… yeah.
The ugly: All of the juicy nuggets of event data in the message body are stored in XML. And nearly every combination of event ID and provider has a unique event schema for storing the data we want. Neo’s MSDN blog post gets us most of the way there. AskDS and Hey Scripting Guy show how we can use the GUI to help write the XML filter syntax. Now my head is spinning. This is the farthest point from intuitive. Don’t even get me started on XPATH.
Note: In all fairness to the product this data structure is necessary. All events have a few common properties like provider, ID number, date/time, source, etc. But in order to capture the unique details of each event we needed a way to store a variable number of properties. So the design is good, just a bit complicated to script.
In the life of every scripter you will come to challenges like this. You just have to cowboy up and dive in.
The thing I’ve not seen in these blog posts is how to dump out the event message data in a CSV file where I can easily report and manipulate the data I need. For example, if I’m collecting logon failure event 4625, then I want the guts of the message body in separate columns where I can easily summarize and report on the user and computer accounts involved. While I can harvest event logs from multiple servers in the GUI, it is just not friendly for mass reporting, sorting and visualization like Excel. This is the problem I am trying to solve.