{"id":15811,"date":"2011-01-24T00:01:00","date_gmt":"2011-01-24T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2011\/01\/24\/use-powershell-cmdlet-to-filter-event-log-for-easy-parsing\/"},"modified":"2011-01-24T00:01:00","modified_gmt":"2011-01-24T00:01:00","slug":"use-powershell-cmdlet-to-filter-event-log-for-easy-parsing","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-powershell-cmdlet-to-filter-event-log-for-easy-parsing\/","title":{"rendered":"Use PowerShell Cmdlet to Filter Event Log for Easy Parsing"},"content":{"rendered":"

 <\/p>\n

Summary<\/b>: Learn how to use the Get-WinEvent Windows PowerShell cmdlet to filter the event log prior to parsing it.<\/p>\n

\"Hey, Hey, Scripting Guy! I am confused. I have enjoyed using the Get-EventLog<\/b> Windows PowerShell cmdlet. It is fast, and easy to use. However, I do not always like the way it seems to return all the records from a remote computer before I can parse it with the Where-Object<\/b> cmdlet. Why does it not support a –filter<\/b> parameter?<\/p>\n

— RD<\/p>\n

\"Hey, Hello RD, <\/p>\n

Microsoft Scripting Guy Ed Wilson here. After SQL Saturday in Tampa, Florida, Dr. Scripto and I decided to head to the beach so we could play a little volleyball. The following action shot captures Dr. Scripto in peak beach volleyball form. <\/p>\n

\"Image<\/a><\/p>\n

Speaking of things that seem to bounce around, Windows PowerShell 2.0 introduces a new cmdlet to permit filtering of an event log prior to returning it to the workstation for additional parsing. I will admit that the Get-EventLog<\/b> Windows PowerShell cmdlet is extremely easy to use. In Windows PowerShell 2.0, it even has a computername<\/b> <\/i>parameter that provides easy access to remote event logs. There are a couple of problems with the Get-EventLog<\/b> cmdlet. The first is that it must first return the log entries before they can be parsed with the Where-Object<\/b> cmdlet. When working on a local computer, this might not be a huge issue, but when connecting across the network, it is better to filter the events at the remote computer before returning them to the local machine. The second issue with the Get-EventLog<\/b> cmdlet is that it does not allow one to query the ETL type of logs; it is limited to the so-called “traditional event logs” such as the system, application, and security logs. The last problem with Get-EventLog<\/b> is it is limited to online logs. When the event log is archived, Get-EventLog<\/b> cannot access it. All of these problems are addressed with the Get-WinEvent<\/b> cmdlet. <\/p>\n

Unfortunately, Get-WinEvent<\/b> is not as easy to use as the Get-EventLog<\/b> cmdlet. Confusion with Get-WinEvent<\/b> begins with its name—it sounds as if it would have something to do with Windows events such as a shutdown event instead of event logs. It extends to the use of hash tables for filter mechanisms, and concludes with reading the event logs backward. But do not let these quirks scare you away from using an extremely powerful cmdlet. <\/p>\n

If I want to look at the most recent event from the application log on my computer, I use the logname<\/b> <\/i>parameter and specify a value for maxevents<\/b>. <\/i>In the example that follows, I use the number 1 to retrieve the most recent event in the application log (1 maximum event is the most recent event). I illustrate this technique with the code that appears here. <\/i><\/p>\n

\n

PS C:\\> Get-WinEvent -LogName application -MaxEvents 1<\/p>\n

TimeCreated                     ProviderName                       Id          Message<\/p>\n

———–                            ————                              —          ——-<\/p>\n

1\/16\/2011 11:41:11 AM    Windows Error Reporting     1001      Fault bucket , type 0…<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

If I want to see all of the entries in a particular event log (or ETL log), I do not specify a value for maxevents<\/b>.<\/i> An example of doing that is shown here:<\/p>\n

\n

PS C:\\> Get-WinEvent -LogName system<\/p>\n

TimeCreated                         ProviderName                       Id           Message<\/p>\n

———–                                ————                              —           ——-<\/p>\n

1\/16\/2011 12:00:00 PM         EventLog                             6013      The system uptime is …<\/p>\n

1\/16\/2011 11:47:53 AM         Service Control Manager     7036       The Application Exper…<\/p>\n

1\/16\/2011 11:47:20 AM         Microsoft-Windows-Tim…     129         NtpClient was unable …<\/p>\n

1\/16\/2011 11:43:34 AM         Service Control Manager      7036       The Multimedia Class …<\/p>\n

<output truncated><\/p>\n<\/blockquote>\n

When I use a hash table to filter events prior to returning them, the power of the cmdlet begins to show. A hash table uses the syntax of key = value<\/b>, and each key must be unique. If I use the FilterHashTable<\/b> <\/i>parameter, I am not able to supply a value for the LogName<\/b> <\/i>parameter. I discovered this by examining the parameter sets that appear in the Get-Help Get-WinEvent<\/b> help topic. The two applicable parameter sets appear here:<\/p>\n

\n

Get-WinEvent [-LogName] <string[]> [-ComputerName <string>] [-Credential <PSCredential>] [-Filt<\/p>\n

erXPath <string>] [-Force <switch>] [-MaxEvents <int64>] [-Oldest] [<CommonParameters>]<\/p>\n

Get-WinEvent -FilterHashTable <Hashtable[]> [-ComputerName <string>] [-Credential <PSCredential<\/p>\n

>] [-Force <switch>] [-MaxEvents <int64>] [-Oldest] [<CommonParameters>]<\/p>\n<\/blockquote>\n

What this means is that I must include the log name in my hash table filter when I execute the command. The following table details the permitted key names and the associated data type of that associated value. Only two of the value fields accept wildcard characters. The *<\/b> key represents a named event data field. <\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

Key name<\/strong><\/p>\n<\/td>\n

\n

Value data type<\/strong><\/p>\n<\/td>\n

\n

Accepts wildcard characters?<\/strong><\/p>\n<\/td>\n<\/tr>\n

\n

LogName<\/p>\n<\/td>\n

\n

<String[]><\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n<\/tr>\n

\n

ProviderName<\/p>\n<\/td>\n

\n

<String[]><\/p>\n<\/td>\n

\n

Yes<\/p>\n<\/td>\n<\/tr>\n

\n

Path<\/p>\n<\/td>\n

\n

<String[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Keywords<\/p>\n<\/td>\n

\n

<Long[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

ID<\/p>\n<\/td>\n

\n

<Int32[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Level<\/p>\n<\/td>\n

\n

<Int32[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

StartTime<\/p>\n<\/td>\n

\n

<DateTime><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

EndTime<\/p>\n<\/td>\n

\n

<DataTime><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

UserID<\/p>\n<\/td>\n

\n

<SID><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

Data<\/p>\n<\/td>\n

\n

<String[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n

\n

*<\/p>\n<\/td>\n

\n

<String[]><\/p>\n<\/td>\n

\n

No<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Suppose I am concerned with events that are coming from Capi2<\/b> with the EventID of 4107. When developing these types of filters, I always like to look at the actual event log record so that I can test my results to ensure the accuracy of my efforts. The particular event log entry I am interested in obtaining is shown in the following image. <\/p>\n

<\/p>\n

To use the Get-WinEvent<\/b> cmdlet to query the application log for event ID 4107, I create a hash table that will be supplied to the FilterHashTable<\/b> <\/i>parameter. The key names (from the table above) do not need to be placed in quotation marks. The value data types that are listed as String or SID will need the quotation marks around it. The ID data type is an int32 and therefore does not need quotation marks around it. The resulting command appears here, along with the associated output. <\/p>\n

\n

PS C:\\> Get-WinEvent -FilterHashtable @{logname=’application’; id=4107}<\/p>\n

TimeCreated                           ProviderName                       Id             Message<\/p>\n

———–                                 ————                               —             ——-<\/p>\n

1\/17\/2011 8:18:27 AM            Microsoft-Windows-CAPI2    4107        Failed extract of thi…<\/p>\n

1\/16\/2011 11:32:02 AM          Microsoft-Windows-CAPI2    4107        Failed extract of thi…<\/p>\n

1\/15\/2011 9:23:30 AM            Microsoft-Windows-CAPI2    4107        Failed extract of thi…<\/p>\n

<truncated output><\/p>\n<\/blockquote>\n

If I want to limit the output to events from the current day, I add the StartTime<\/b> key. The StartTime<\/b> key expects a datetime<\/b> object. I therefore use the Get-Date<\/b> Windows PowerShell cmdlet to retrieve the current date and time. I then specify that I only want today’s date from the cmdlet. I do this by placing parentheses around the Get-Date<\/b> cmdlet, and then using dotted notation to retrieve only the date<\/b> property from the System.DateTime<\/b> object that is returned by Get-Date<\/b>. I knew which properties were available from the System.DateTime<\/b> object because I used the Get-Member<\/b> cmdlet to examine the properties. This is illustrated here:<\/p>\n

\n

PS C:\\> get-date | Get-Member -MemberType property<\/p>\n

TypeName: System.DateTime<\/p>\n

Name                     MemberType                           Definition<\/p>\n

—-                         ———-                                   ———-<\/p>\n

Date                       Property                                  System.DateTime Date {get;}<\/p>\n

Day                         Property                                  System.Int32 Day {get;}<\/p>\n

DayOfWeek            Property                                   System.DayOfWeek DayOfWeek {get;}<\/p>\n

DayOfYear              Property                                   System.Int32 DayOfYear {get;}<\/p>\n

Hour                       Property                                   System.Int32 Hour {get;}<\/p>\n

Kind                        Property                                   System.DateTimeKind Kind {get;}<\/p>\n

Millisecond              Property                                   System.Int32 Millisecond {get;}<\/p>\n

Minute                    Property                                   System.Int32 Minute {get;}<\/p>\n

Month                     Property                                   System.Int32 Month {get;}<\/p>\n

Second                   Property                                   System.Int32 Second {get;}<\/p>\n

Ticks                       Property                                   System.Int64 Ticks {get;}<\/p>\n

TimeOfDay              Property                                    System.TimeSpan TimeOfDay {get;}<\/p>\n

Year                        Property                                    System.Int32 Year {get;}<\/p>\n<\/blockquote>\n

Next, I tested the command to ensure it returned what I expected. This technique is shown here:<\/p>\n

\n

PS C:\\> (get-date).date<\/p>\n

Monday, January 17, 2011 12:00:00 AM<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

After I had confirmed that the command worked as I expected, I incorporated it into my previous hash table filter. This is shown here, along with the associated output:<\/p>\n

\n

PS C:\\> Get-WinEvent -FilterHashtable @{logname=’application’; id=4107; StartTime=(Get-Date).date}<\/p>\n

TimeCreated                        ProviderName                       Id              Message<\/p>\n

———–                              ————                               —              ——-<\/p>\n

1\/17\/2011 8:18:27 AM        Microsoft-Windows-CAPI2      4107         Failed extract of thi…<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

I then decided to try an experiment. Because the StartTIme<\/b> key expects a DateTime<\/b> data type, I wondered if I could give it a string and have it cast it to a System.DateTime<\/b> object for me. I knew that I could do something like the following command and that I would receive a DateTime<\/b> object:<\/p>\n

\n

PS C:\\> [datetime]”1\/17\/11″<\/p>\n

Monday, January 17, 2011 12:00:00 AM<\/p>\n

PS C:\\> ([datetime]”1\/17\/11″).GetType()<\/p>\n

IsPublic              IsSerial      Name              BaseType<\/p>\n

——–                ——–        —-                  ——–<\/p>\n

True                   True           DateTime         System.ValueType<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

However, I was not certain that Windows PowerShell was smart enough to perform the conversion for me. Therefore, I decided to test it out. As you can see, the command worked out great:<\/p>\n

\n

PS C:\\> Get-WinEvent -FilterHashtable @{logname=’application’; id=4107; StartTime=”1\/17\/11″}<\/p>\n

TimeCreated                    ProviderName                      Id          Message<\/p>\n

———–                           ———–                              —           ——-<\/p>\n

1\/17\/2011 8:18:27 AM     Microsoft-Windows-CAPI2   4107      Failed extract of thi…<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

When I had the previous command working, I decided to see if I could use the same technique to retrieve a range of records. To do this, I used both the StartTime<\/b> key and the EndTime<\/b> key. The command and associated output appear here:<\/p>\n

\n

PS C:\\> Get-WinEvent -FilterHashtable @{logname=’application’;id=4107;StartTime=”1\/15\/11″;EndTime=”1<\/p>\n

\/17\/11″}<\/p>\n

TimeCreated                    ProviderName                        Id          Message<\/p>\n

———–                           ————                               —          ——-<\/p>\n

1\/16\/2011 11:32:02 AM   Microsoft-Windows-CAPI2     4107     Failed extract of thi…<\/p>\n

1\/15\/2011 9:23:30 AM     Microsoft-Windows-CAPI2     4107     Failed extract of thi…<\/p>\n

1\/15\/2011 8:28:07 AM     Microsoft-Windows-CAPI2     4107     Failed extract of thi…<\/p>\n

1\/15\/2011 8:27:32 AM     Microsoft-Windows-CAPI2     4107     Failed extract of thi…<\/p>\n

PS C:\\><\/p>\n<\/blockquote>\n

RD, that is all there is to using the Get-WinEvent<\/b> cmdlet. Neglected Cmdlet Week will continue tomorrow when I will talk about using the Get-WinEvent<\/b> cmdlet to query offline event logs. <\/p>\n

I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n

 <\/p>\n

Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

  Summary: Learn how to use the Get-WinEvent Windows PowerShell cmdlet to filter the event log prior to parsing it. Hey, Scripting Guy! I am confused. I have enjoyed using the Get-EventLog Windows PowerShell cmdlet. It is fast, and easy to use. However, I do not always like the way it seems to return all […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[97,51,98,3,4,45],"class_list":["post-15811","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-event-logs","tag-getting-started","tag-logs-and-monitoring","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

  Summary: Learn how to use the Get-WinEvent Windows PowerShell cmdlet to filter the event log prior to parsing it. Hey, Scripting Guy! I am confused. I have enjoyed using the Get-EventLog Windows PowerShell cmdlet. It is fast, and easy to use. However, I do not always like the way it seems to return all […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15811","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=15811"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/15811\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=15811"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=15811"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=15811"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}