{"id":1261,"date":"2014-06-03T00:01:00","date_gmt":"2014-06-03T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/06\/03\/use-filterhashtable-to-filter-event-log-with-powershell\/"},"modified":"2014-06-03T00:01:00","modified_gmt":"2014-06-03T00:01:00","slug":"use-filterhashtable-to-filter-event-log-with-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-filterhashtable-to-filter-event-log-with-powershell\/","title":{"rendered":"Use FilterHashTable to Filter Event Log with PowerShell"},"content":{"rendered":"

Summary<\/b>: Microsoft Scripting Guy, Ed Wilson, talks about using a filter hash table to filter the event log with Windows PowerShell.<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. The weather here in Charlotte, North Carolina has turned hot and humid. As a result, the Scripting Wife decided to migrate north for a while. Actually, she is attending a conference in Cincinnati, Ohio. This has given me a bit of extra time to play around with Windows PowerShell and to work on my laptop.<\/p>\n

The most powerful way to filter event and diagnostic logs by using Windows PowerShell is to use the Get-WinEvent cmdlet<\/b>. Introduced in Windows PowerShell 2.0, the Get-WinEvent<\/b> cmdlet is not new technology. But most people do not use the Get-WinEvent<\/b> cmdlet because it seems to be more difficult to use. The Get-EventLog<\/b> cmdlet that I used yesterday is easy-to-use, and for a lot of things, it works just fine.<\/p>\n

But Get-WinEvent<\/b> has several ways to filter the left side of the pipeline. When working with large logs, grabbing everything and sending it down the pipeline to a Where-Object<\/b> cmdlet is not the most efficient thing to do. It fact, it can be downright slow. An example of this sort of slow command is shown here:<\/p>\n

Get-EventLog -LogName application | where source -match 'defrag'<\/p>\n

Get-WinEvent the easy way<\/h2>\n

The easiest way to perform powerful queries by using the Get-WinEvent<\/b> cmdlet is to use the FilterHashTable<\/b> parameter. As the parameter name might imply, it accepts a hash table as a filter. A hash table is made up of key\/value pairs. Therefore, the trick is to know the permissible key names and what an acceptable value for that key might look like. Here is a table that shows the key names, the data type it accepts, and whether it will accept a wildcard character for that data value.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

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

\n

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

\n

Accepts wildcard characters?<\/b><\/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

One thing I like to do when I build a query using Get-Winevent<\/b> is to take it a step at a time. I begin with the LogName<\/b>. As shown here, this first query is the same as typing Get-EventLog –LogName<\/b> Application<\/b>:<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'}<\/p>\n

The next thing I want to specify (I do not have to use the order that is presented in my previous table) is the ProviderName<\/b>. This example returns entries generated by the .NET RunTime <\/b>source, in the Application<\/b> log:<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime' }<\/p>\n

The ProviderName<\/b> is the name that appears in the Source<\/b> field in the Event Viewer. This is shown here:<\/p>\n

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

I use the –path<\/b> parameter when I am working with archived event logs. I wrote a good blog post about that: Use PowerShell to Parse Saved Event Logs for Errors<\/a>.<\/p>\n

In my hash table, the next key is the Keywords<\/b> key name. This sounds like you would be able to use keywords to filter out event log events. But the Data Type<\/b> field holds an array made up of the [long] <\/b>value type, and a [long]<\/b> value type holds a really large number. Here is the maximum value:<\/p>\n

PS C:\\> [long]::MaxValue<\/p>\n

9223372036854775807<\/p>\n

Therefore, what Windows PowerShell wants is a number, not a keyword (such as Security<\/b>). I can use the GUI to see what permissible keywords are feasible. This is shown here:<\/p>\n

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

The problem is that when I attempt to use one of these keywords, I get an error message. This is because these are string values, and not long numbers. So when I have a potential list of keywords that have associated numeric values, I think enumeration. In fact, these are the StandardEventKeywords<\/b> enumeration, as shown here:<\/p>\n

PS C:\\> [System.Diagnostics.Eventing.Reader.StandardEventKeywords] | gm -s -MemberType property<\/p>\n

   TypeName: System.Diagnostics.Eventing.Reader.StandardEventKeywords<\/p>\n

Name             MemberType Definition<\/p>\n

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

AuditFailure     Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

AuditSuccess     Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

CorrelationHint  Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

CorrelationHint2 Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

EventLogClassic  Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

None             Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

ResponseTime     Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

Sqm              Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

WdiContext       Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

WdiDiagnostic    Property   static System.Diagnostics.Eventing.Reader.StandardEventKey…<\/p>\n

This enumeration is documented on MSDN (StandardEventKeywords Enumeration<\/a>), but it does not display the enumeration numeric values. For a function that will do this, take a look at my series of blog posts about enumerations<\/a>, and in particular, read Enumerations and Values<\/a>. In fact, my Get-EnumAndValues<\/b> function is so helpful that it is a function I have in my Windows PowerShell profile<\/a>. When I use the Get-EnumAndValues<\/b> function, I retrieve the following results:<\/p>\n

Name                           Value                                          <\/p>\n

—-                           —–                                          <\/p>\n

AuditFailure                   4503599627370496                               <\/p>\n

AuditSuccess                   9007199254740992                               <\/p>\n

CorrelationHint2               18014398509481984                              <\/p>\n

EventLogClassic                36028797018963968                              <\/p>\n

Sqm                            2251799813685248                               <\/p>\n

WdiDiagnostic                  1125899906842624                               <\/p>\n

WdiContext                     562949953421312                                <\/p>\n

ResponseTime                   281474976710656                                <\/p>\n

None                           0                                            <\/p>\n

Now the query looks like the following (this is a one-line command that is wrapped for readability):<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime'; keywords=36028797018963968}<\/p>\n

Because this is an enumeration, I can also use the actual enumeration static property, but I have to convert it to the value by calling the value__<\/b> property, and not to the returned string. To do this, I might use the following script:<\/p>\n

$c = [System.Diagnostics.Eventing.Reader.StandardEventKeywords]::EventLogClassic<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime'; keywords=$c.value__}<\/p>\n

As I have been running my commands, I have been getting increasingly shorter outputs of event log records. From that list, I select the particular event ID, which in FilterHashTable<\/b> becomes the keyword ID. This command is shown here:<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime'<\/p>\n

; keywords=36028797018963968; ID=1023}<\/p>\n

I now decide that I want to filter out only the errors. This is the Level<\/b> property. But when I use the command shown here, it generates an error message.<\/p>\n

PS C:\\> Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime'<\/p>\n

; keywords=36028797018963968; ID=1023; level='error'}<\/p>\n

I go back to my has table, and sure enough, I see that Level<\/b> needs an Int32<\/b>, or an array of Int32s. So it wants another number, and not the standard error, warning, information that I am used to using. This smells like another enumeration.<\/p>\n

I look back at the MSDN page I had open for the previous enumeration, and I discover that there is a StandardEventLevel Enumeration<\/a>. It works the same way as the previous enumeration. I can create the class, use the Get-Member<\/b> with –Static<\/b>, and use my enumeration value function. Here are the enumeration member names and their associated values:<\/p>\n

Name                           Value                                           <\/p>\n

—-                           —–                                          <\/p>\n

Verbose                        5                                              <\/p>\n

Informational                  4                                              <\/p>\n

Warning                        3                                              <\/p>\n

Error                          2                                              <\/p>\n

Critical                       1                                              <\/p>\n

LogAlways                      0        <\/p>\n

Armed with this information, I know that an error is level 2. So here is the modified command:<\/p>\n

Get-WinEvent -FilterHashtable @{logname='application'; providername='.Net Runtime'; keywords=36028797018963968; ID=1023; level=2}<\/p>\n

That is all there is to using Get-WinEvent<\/b> to look at event log keywords. Event Log Week will continue tomorrow when I will talk about more way cool stuff.<\/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

Ed Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using a filter hash table to filter the event log with Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. The weather here in Charlotte, North Carolina has turned hot and humid. As a result, the Scripting Wife decided to migrate north for a while. Actually, she […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[97,98,3,45],"class_list":["post-1261","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-event-logs","tag-logs-and-monitoring","tag-scripting-guy","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using a filter hash table to filter the event log with Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. The weather here in Charlotte, North Carolina has turned hot and humid. As a result, the Scripting Wife decided to migrate north for a while. Actually, she […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1261","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\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=1261"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1261\/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=1261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=1261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=1261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}