Richard Siddaway's Blog

I have mentioned PowerGUI many times – I especially like the editor.  There is a large, and growing, library of PowerGUI powerpacks (additional functionality) available for download from www.powergui.org.

I have just added the PowerShell Help powerpack to my system.  Written by Kirk Munro (PowerShell MVP) it gives many views into the PowerShell help system.  I may even drop my own help utility in favour of using this. It can be downloaded from http://www.powergui.org/entry.jspa?externalID=801&categoryID=55  - - highly recommended.

If we look at the event logs that are present on our system we will see how the logs are configured in terms of maximum size, retention days and the action to take in the event of the log becoming full (overflow).

PS> Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Name
  ------ ------ --------------        ------- ----
  25,600      0 OverwriteAsNeeded       8,871 Application
  15,168      0 OverwriteAsNeeded           0 DFS Replication
  20,480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 Internet Explorer
  20,480      0 OverwriteAsNeeded           0 Key Management Service
  16,384      0 OverwriteAsNeeded           0 ODiag
  16,384      0 OverwriteAsNeeded       1,083 OSession
     512      7 OverwriteOlder              2 Scripts
                                              Security
  20,480      0 OverwriteAsNeeded      38,517 System
     512      7 OverwriteOlder              0 test23
  15,360      0 OverwriteAsNeeded       1,000 Windows PowerShell

We can use the Limit-EventLog cmdlet to control these settings.

Limit-EventLog -LogName Scripts -MaximumSize 2mb -RetentionDays 9 -OverflowAction OverWriteOlder

Note that the maximum size is translated to KB (and must be divisable by 64KB).  The overflow actions are limited to

• DoNotOverwrite
• OverwriteAsNeeded
• OverwriteOlder

This cmdlet has a computername parameter so we can work remotely – there is a los a whatif and confirm parameter.  Remember the need for Administrator privileges to make the changes.

Show-EventLog is a very straight forward cmdlet with a minimum of parameters.  Outside of the common parameters it can only take a computer name.  As it says in the name the cmdlet opens Event Viewer on the local or remote machine (remember need for admin privileges on Vista and later so start PowerShell using Run as Administrator).  The computername parameter accepts a name, an IP Address or a FQDN.

Show-EventLog -ComputerName pcrs2
Show-EventLog -ComputerName 192.168.86.17
Show-EventLog -ComputerName pcrs2.somedomain.com

The PowerShell prompt is returned as soon as event viewer is opened.

No doubt there will be a mass of posts on the new features in CTP3 over the next weeks and months.  What I want to try and do is concentrate on those features that are of most benefit to administrators. I am going to start with functionality to work with event logs.  I have blogged a number of times about writing scripts to go beyond the get-eventlog of PowerShell version 1 – most of that functionality is now available as cmdlets.  We now have a number of cmdlets for working with event logs:

Clear-EventLog
Get-EventLog
Limit-EventLog
New-EventLog
Remove-EventLog
Show-EventLog
Write-EventLog

We’ll start by looking at what is new in get-eventlog and then look at the others.  Get-Eventlog brings a bunch of new parameters:

* LogName
ComputerName
* Newest
After
Before
UserName
InstanceId
Index
EntryType
Source
Message
AsBaseObject
* List
* AsString

Parameters marked * are present in PowerShell v1

Note - I have deliberately left off the common parameters -  -verbose etc etc.

One of the most obvious additions is the computername parameter – we can now work with logs on remote computers.  We don’t need PowerShell remoting enabled for this.

Get-EventLog -List -ComputerName pcrs2

After and before allow us to view the log between two time bounds -

$d1 = (Get-Date).AddDays(-5)
$d2 = (Get-Date).AddDays(-2)
Get-EventLog -LogName system -After $d1 -Before $d2

Index enables us to access a particular entry.  InstanceId means we can pick out a particular type of entry – note that instanceid is not necessarily the same as eventid.

Using Entrytype means we can select by the type of entry ie

Error
Warning
Information
SuccessAudit
FailureAudit

such as

Get-EventLog -LogName system -EntryType Error

With the source parameter we can filter based on the source used to write to the event log and –message allows us to select based on the message contents.

These new parameters enable us to interrogate the event logs in a much simpler manner – all of this can be performed in V1 but we need to pipe into where to perform the filtering – now we can do it in one pass in the cmdlet.  Add this to the capability of accessing the logs on remote computers and we can really start to integrate the data across our server logs – for instance we can easily check the logs on a number of domain controllers for logins in a certain time frame.