Parsing Logs - Part I

Microsoft does a ton of great logging in their OS and Applications.  The hardest part is sorting through it.

A while ago, I discovered Microsoft's LogParser tool.  It's great for older systems that don't leverage PowerShell natively.  Certainly, WMI is out there, but learning curve can feel pretty steep.  Instead, utilizing LogParser's native SQL query engine, I can leverage a syntax I know and love.

Without further adieu, here's how I do it:

SELECT EventLog, -- The Name of the Event Log
   EventID, -- The number of the Event ID
   SourceName, -- The Source of the error
   COUNT(*) AS Frequency, -- Aggregate distinct results
   Message -- The body of text from the event
INTO Report.txt -- Return the results to txt, based on the execution path
FROM Application, -- The names of the default logs
   Security,
   System,
   'Directory Service', -- Explicitly specify extra logs
   'DNS Server',
   'File Replication Service' 
WHERE EventType IN(1;2;3;5;16) -- Ignore Information or Success event types
   AND TimeGenerated >= TO_LOCALTIME( SUB( SYSTEM_TIMESTAMP(),
       TIMESTAMP('30', 'd') ) ) -- Subtract 30 days from exec time
GROUP BY EventLog, -- Group our results, for the aforementioned aggregate
   EventID,
   SourceName,
   Message
HAVING COUNT(*) > 1 -- Only return events that have happened more than once
ORDER BY EventLog, -- Sort by log name, ascending
   EventID -- Then event id number, ascending

Adventures in Bare Metal Recovery

I've worked my way through several Bare Metal Recoveries before, including physical to virtual conversions, but this is the first time this has happened to me.  The fact that the server has been unable to contact the domain may have been a pre-existing condition which was further exasperated by a nasty malware infection.

This is a handy tool, if your server in question is a Domain Controller:

netdom resetpwd /server:server_name /userd:domain_name\administrator /passwordd:administrator_password

But if it's not, a tiny note on this page explains that:

Note: This method only works for DC. If it’s member server, we have to disjoin and rejoin domain.

And I was stuck with a member server.  Thankfully its services recovered after rejoining the domain without too much hacking.  A few updates later and we were back on track.

Weekend Warrior Wireless Project - Phase II

After this last weekend's project, I ended up with more on my plate to fix than originally planned.

Timing Really is Everything

As I noted in my last post, I love the Buffalo WHR-HP-G54, because its so well supported!  By setting my local physical NIC to 192.168.11.2/24, I was able to ping my device when it started up by using the 5/5/5 method:

ping -t -w 10 192.168.11.1

I found the Windows based GUI TFTP client listed here to be the best for restartable TFTP sessions.  First I'd get a a few errors, then at least 5 pings before it timed out.  Setting the timeout to 10, then starting the TFTP attempts prior to the 5/5/5 maintenance mode boot, I was able to send successfully!

Selecting options for a successful TFTP

Choosing the Right Firmware (Again)

Firmware was indeed what it came down to.  I chose a firmware that was both a different feature set, kernel, and wireless driver.  Essentially, it was too much for the nvram to handle.  Even during that initial upload, I was amazed at just how fast that firmware uploaded.  Oh, wait it actually didn't.  So back to my last "good" firmware, the 14929 vpn K24 sp2 build from Brainslayer.

From what research I have gathered, when making the jump to the NEWD-2 firmware, it includes a jump to the K26 series.  When I've got more time on my hands and as the builds mature, I'll jump back in and try out the latest and greatest.  Meanwhile the trusty 14929 will have to do.  At least if I did actually brick my device, I've got another one to spare.