Summary: Ed Wilson, Microsoft Scripting Guy, talks about using Windows PowerShell to explore classic event logs.
Microsoft Scripting Guy, Ed Wilson, is here. When you get to version five of anything, you already begin to see signs on strain and pain. I mean, take Windows NT 5.0, for example. Oh yeah. That one was delayed for about five years, and it eventually became Windows 2000.
Part of the reason is that no matter how good the original version or vision was, things change. Priorities change. And more often than not, computers and technology change. Often, it is easier to create a new tool, than to retrofit an old tool. But you can’t just give up on the old tool, so you end up with two (or more) tools that do the same job, only differently.
In Windows PowerShell, there are at least five ways of querying event logs. I am not going to catalogue them here, nor am I going to mention them all. but if you have been scripting for very long, you can probably figure them out for yourself. This is because several techniques that you may have used in other scripting languages (such as VBScript) remain valid in Windows PowerShell.
But even “native” Windows PowerShell has two clearly defined ways of querying event logs:
- The Get-EventLog cmdlet
- The rather obscurely named Get-WinEvent cmdlet
To really make things confusing, we also have Get-Event, and it has absolutely nothing to do with event logs.
The reason that Get-WinEvent is obscurely named is because Get-EventLog came out in Windows PowerShell 1.0; and therefore, it grabbed the best cmdlet name for querying event logs. The Get-WinEvent cmdlet could have been called Get-MoreEventLogs, but cmdlet names prefer the singular, and it would have really sounded strange if was named Get-MoreEventLog. The issue with Get-WinEvent as a name is that it sounds like it has more to do with eventing (as a subsystem) than with event logs.
Oh, well. What’s the difference anyway? Well, if you think about it, why did we create a second cmdlet to query event logs? For the record, Get-WinEvent came out in Windows PowerShell 2.0. It is a very powerful cmdlet. It can query not only the classic event logs, but also the Event Tracing for Windows (ETW) logs. This makes it a highly valuable tool for diagnostics.
Now, you just might be thinking, "Yeah, but…," and you would be right. Whenever we say "powerful" and "flexible," we can also insert the ominous word "complicated." And that is the problem.
For example, if I want to get events from the application log that occurred on September 24, 2015, I can easily type use the Get-EventLog cmdlet. Tab expansion works great, and it will take me about a second to type the query. The command is shown here:
Get-EventLog -LogName application -After "9/24/15" -Before "9/25/15"
But to get the same information using the Get-WinEvent cmdlet requires using a rather complicated filter hash table. To do this, I have to have reference to the full Get-Help output so I know the keyword parameters. I come up with the following command:
Get-WinEvent -FilterHashtable @{Logname='application';starttime='9/24/15';endtime='9/25/15'}
Both commands work, but the second is much more difficult to compose. One thing that is cool about this command is that it automatically sorts the output by provider name. This can be useful when troubleshooting errors. The output is shown in the following image:
On the other hand, the Get-WinEvent command is more than four times faster than the corresponding Get-EventLog command. To find this, I use the Measure-Command cmdlet, and here is the output:
The great thing is that we have two cmdlets for querying event logs. One is super easy to use, and one is super fast. One is rather basic, and one is very powerful. Which do I need? Well, I need both! And that is the great thing about a mature product…choices!
Join me tomorrow when I will talk about more cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy