Part–2 : Working with Event Logs using PowerShell :- Get-EventLog

 

In my previous blog post, i had tried to cover the basics of “Event Logs”, and in previous post we had also saw the use of “Show-EventLog” cmdlet.

There is no benefit of PowerShell if we are exploring “Event Logs” using GUI tools. So let’s start working on PowerShell console.

There are two main cmdlets in PowerShell those are use to get events from various  “Event Logs”, the first cmdlet  is “Get-EventLog” and the another one is “Get-WinEvent”.

The main difference between these two cmdlets are , The Get-EventLog works only with classic type of Event Logs and on other hand “Get-WinEvent” work with both type of event logs the classic one and the Applications and Service logs too.

Let’s see the use of “Get-EventLog” cmdlet.

Just for your information, I am using Windows 8, so might be you may see few extra event logs in my command outputs.

Let’s check which classic event logs are exists on my laptop. To check that, run the below command.

Get-EventLog -LogName *

You can see that , now we have a list of all classic event logs.

Let’ see the all events in Application Log,  run the below command. In the below command we are asking Get-Event log to give us the list of all event log entries is the event log name “Application”

Get-EventLog -LogName Application

But, when you run the above command , your PowerShell console will fill with lots-lots-lost of events.

This massive information is not much useful for us right now, what if ?I want to see the  newest 10 event log entries only.

You can do that, you can use –Newest parameter and provide the number of entries which you want to see.

In below command , we are asking Get-EventLog to show the newest 10 entries in the Event log.

Get-EventLog -LogName Application -Newest 10

If you want to see more details of the event log entries, you can use “Format-List” cmdlet to  format the output and show us full details of the event log entry.

Get-EventLog -LogName Application -Newest 10 | Format-List -Property *

If you remember, that in my previous blog post , i have mentioned about four type of log’s severity levels, information, warning, error, critical, Failure Audit and Success Audit , we can use those here too, just to a quick note, Get-EventLog cmdlet doesn’t support the Entry type Critical.

what if, you want to see the newest 10 events of  entry type Warning.

Get-EventLog -LogName Application –EntryType Warning -Newest 10

See how easy it is  

One last trick for today,

You can also define the the time period in After , before format in Get-Eventlog to see the event logs accordingly.

let see the Application’s event log entries  those are created after 11th Nov 2013

Get-EventLog -LogName Application -After 11/11/2013

If you want to see the event log entries those are created before a specific date, you can use –Before parameter.

Get-EventLog -LogName Application -Before 11/11/2013”

We also have the flexibility of searching event log entries in a specific time frame, You can use –After and –Before paramters to define a date range to search with-in.

“Get-EventLog -LogName Application  -After 7/11/2013  -Before 10/11/2013”

That’s all for today, see you in next post.

Part-1: Working with Event Logs using PowerShell.

Regards

Aman Dhally

 

     

"More" Can Be Dangerous - Use Better Alternative in PowerShell

 

PowerTip of the Day, from PowerShell.com:

 

You might know the more.com tool: when you pipe output to more.com, the output is displayed page by page:

PS> Get-EventLog -LogName System | more

However, "more" can be dangerous as you see here. You will not get any results for a long time, and your CPU load increases. more.com first collects all results before it starts paginating it. This takes a long time and a lot of resources.

That's why you should avoid more.com and instead use Out-Host with the parameter -Paging.

PS> Get-EventLog -LogName System | Out-Host -Paging

You immediately see the benefit: results appear momentarily, and no additional CPU load is created.

Creating a "Better" More in PowerShell

 

PowerTip of the Day, from PowerShell.com:

 

In a previous tip you learned that using "more" to paginate output can be dangerous, and instead you should use Out-Host -Paging. To "update" more.com and make it behave like Out-Host with the -Paging parameter set, use a proxy function like this one:

function more {

 param(

 [Parameter(ValueFromPipeline=$true)]

 [System.Management.Automation.PSObject]

 $InputObject

 )

 

 begin

 {

  $type = [System.Management.Automation.CommandTypes]::Cmdlet

  $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Out-Host', $type)

  $scriptCmd = {& $wrappedCmd @PSBoundParameters -Paging }

  $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)

  $steppablePipeline.Begin($PSCmdlet)

 }

 process { $steppablePipeline.Process($_) }

 end { $steppablePipeline.End() }

#.ForwardHelpTargetName Out-Host

#.ForwardHelpCategory Cmdlet

}

Once you run it, whenever you use "more", behind the scenes PowerShell will now call "Out-Host -Paging" instead. That's why now, with the new "more" in place, you can safely use lines like this:

PS> Get-EventLog -LogName System | more

Note that your new "more" now works anywhere. The built-in "help" function, for example, also uses the outdated "more.com" and now will work faster, too.

Spying on Parameters in Powershell

 

PowerTip of the Day, from PowerShell.com:

 

Your own PowerShell functions can have the same sophisticated parameters, parameter types and parameter sets that you know from cmdlets. However, it is not always obvious how to construct the param() block appropriately.

A clever way is to spy on cmdlets and look how they did it. For example, if you wonder how Get-EventLog made its -LogName parameter mandatory, check out its param() block:

PS> $cmd = Get-Command -commandType cmdlet Get-EventLog

PS> [System.Management.Automation.ProxyCommand]::GetParamBlock($cmd)

 

    [Parameter(ParameterSetName='LogName', Mandatory=$true, Position=0)]

    [Alias('LN')]

    [System.String]

    ${LogName},

 

    [Alias('Cn')]

    [ValidateNotNullOrEmpty()]

    [System.String[]]

    ${ComputerName},

 

    [Parameter(ParameterSetName='LogName')]

    [ValidateRange(0, 2147483647)]

    [System.Int32]

    ${Newest},

(...)

Not only will you discover that the keyword Mandatory=$true made -LogName mandatory. You also see all the hidden parameter aliases as well as validator attributes. The parameter -Newest for example will only accept a range between 0 and 2147483647, and your own parameters could do the same now, too

Thanks