Categories Articles

Find what you need: Using PowerShell to parse Windows log files

Ever since the days of Windows NT, the Event Viewer has been to go-to tool for reviewing Windows logs. As great as the Event Viewer is, though, it isn’t perfect. For instance, the Event Viewer lacks the ability to take automated corrective action in response to a log entry. It also lacks the ability to analyze logs that are in other formats, such as text files. However, using PowerShell and a bit of creativity, you can go well beyond the Event Viewer’s native capabilities and filter the information you want from log files.

Let me begin by saying that PowerShell makes it surprisingly easy to parse Windows log files. Suppose, for instance, that you wanted to search the System log for event ID 43. (I’m just picking a random event number.) You could do so by using the Get-EventLog cmdlet:

Get-EventLog -LogName System | Where-Object {$_.EventID -eq '43'}

If you wanted to clean up the output a bit, you might tell PowerShell to show the Instance ID, the time, and the message. You might also consider limiting the output to the 10 most recent events. Here is what such a command would look like:

Get-EventLog -LogName System | Where-Object {$_.EventID -eq '43'} | Select-Object EventID, TimeGenerated, Message -First 10

You can see the command in action in the image below.

So what if you need to do the same thing for a log file generated by some random application that does not write event data to the Windows event logs? This type of log parsing is a bit trickier since you essentially have to perform pattern matching on a text file. Additionally, a log file produced by a random application might not necessarily have event IDs that you can search on.

To show you what I mean, I found a random log file on my desktop. The file was created a couple of years ago, and to be honest with you. I don’t even remember which tool created it. For the sake of demonstration, however, let’s search the log file for a text string.

If you look at the image above, you can see that the first entry was related to SeNetworkLogonRight. That being the case, let’s use PowerShell to search the file for any occurrence of SeNetworkLogonRight. Here is what such a script might look like:

$Text = "SeNetworkLogonRight"
Get-Content 'C:\Scripts\Brien.Log' | Select-String -Pattern $Text

Technically, I could have done this in a single line of code, but I chose instead to store the search string in a variable because doing so opens the door to designing a script that performs a search based on a string that is typed into an input field. You can see the script’s output below.

Locating an event ID or a text string within a log file is a great start, but what else can you do with this technique? One option might be to design a script that looks for a particular log entry and then takes some corrective action if that entry is found.

To show you how this works, let’s take the same script that I used a second ago, but this time if the script finds the string “SeNetworkLogonRight” in the log file, it will perform a corrective command. Of course, I don’t actually want a PowerShell script to take corrective action on a healthy computer in response to a nonsense log entry. That being the case, I will use PowerShell’s Get-Process cmdlet in place of a command that would ordinarily be used to remediate a problem. In other words, my script is going to search the log file for “SeNetworkLogonRight,” and if it finds that string in the file, it will run the Get-Process cmdlet. Here is what the script looks like:

$Text = "SeNetworkLogonRight"
$Results = Get-Content 'C:\Scripts\Brien.Log' | Select-String -Pattern $Text
If ($Results -ne ''){Get-Process}

As you can see, the script’s first line is the same as before. The second line hasn’t changed much either. The only real difference is that rather than simply running the Get-Content cmdlet, I am writing the command’s output to a variable named $Results.

The third line is what determines whether or not the Get-Process cmdlet executes. This command checks to see if the $Results variable is empty. It does this by checking to see if the variable is not equal (-ne) to an empty string. If the $Results variable contains any data at all, it means that the script found the target log entries, and the Get-Process cmdlet is allowed to run. If, on the other hand, the $Results variable is empty, then it means that the log file did not contain the string of interest, so the Get-Process cmdlet does not run.

In case you are wondering, you can do the same thing with entries in the Windows event logs. Let’s suppose for a moment that we wanted to check the Windows System log to see if Event ID 43 was present and then perform some corrective action if the log entry exists. Once again, we will use the Get-Process cmdlet as a stand-in for a command that might perform a corrective action. Here is what the script looks like:

$Results = Get-EventLog -LogName System | Where-Object {$_.EventID -eq '43'}
If ($Results -ne ‘‘){Get-Process}

As you can see, this is nearly identical to the script that I showed you a moment ago. The only difference is that rather than parsing a text file, the $Results variable is populated by entries from the System log.

PowerShell and Windows log files: Endless possibilities

PowerShell makes it possible to parse a variety of log types and to take corrective action based on the presence (or absence) of specific log entries. There are countless ways to build on this technique. For instance, you could use a ForEach loop to build a script that searches multiple log files for a text string rather than limiting your search to a single log.

Featured image: Shutterstock / TechGenix photo illustration

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at:

Published by
Brien Posey

Recent Posts

Contactless payments are hot, but are they secure?

The trend to contactless payments has accelerated as retailers and consumers adjust to COVID-19 realities.…

7 hours ago

Season’s fleecings: CISA warns on holiday shopping scams

The U.S. Department of Homeland Security is warning that online holiday shopping scams may be…

10 hours ago

Azure DNS: Using Azure DevOps to protect public DNS zones

This in-depth tutorial shows you how to use features available in Azure DevOps to boost…

13 hours ago

Report: Baidu Android apps had potential to expose data

Two apps from Chinese tech giant Baidu that had been available in the Google Play…

1 day ago

Shining a light on the dark shadow cast by shadow IT

Employees who don’t have the tools to get their jobs done sometimes turn to the…

2 days ago

Microsoft 365 troubleshooting: Diagnostic tools at your fingertips

Many Exchange Server troubleshooting tools don’t work with Microsoft 365. Fortunately, Microsoft has a bunch…

4 days ago