PowerShell Ezine, Logon Scripts

Ezine 144 PowerShell's Eventlog -list

PowerShell's Eventlog

I am going to spend another week asking PowerShell to examine our Eventlogs.  One reason that I am reinforcing the message: 'Look at your event logs', is because I cannot think of another operating system GUI that is so neglected as the Event Viewer.  Another advantage of investigating a different aspect of the event logs is to provide continuity from the last ezine.

Topics for PowerShell Eventlogs

Addendum - Real Life Example


This Week's Secret

You will find lots of articles on PowerShell, that seek to impress you with stuff that you you cannot do with a GUI, but you can do easily with a script.  My advice for beginners is - do the opposite.  What I mean is actively seek tasks where you can use BOTH the Event Viewer GUI AND PowerShell.  Each has their advantages, moreover one will enhance the other.  At the very least, by working in tandem they will encourage you to check out places that you don't often visit, for example the Disk Manager, and of course the Event Viewer.

This Week's Mission

The first task for This Week's Mission is to list the event logs.  Incidentally, you could play a guessing game; before you execute the script, predict how many logs there are on your machine.  Thanks to Brandon Shell, I even have a script which lists logs on another machine, for example a domain controller.

The second task is to check the maximum size of the logs, particularly the application log.  Potential problems include security events going unnoticed because they were overwritten.  It is also possible that if the log fills up then the system is configured to shutdown.  While that would be undesirable in most situations, for high security companies it would be the only way to prevent a breach of security due to events being overwritten.

Knowledge is power; therefore once you know the names and the purpose of all your logs, then you can make sensible adjustments in the size of each event log.

Guy's Double or Quits Bet

Following last week's bet that you discovered at least one interesting error message in the event log, I bet that if you run the scripts that follow then you will change at least one log setting.  What I am betting is that some of your event logs are set to, 'Overwrite every 7 Days'.  On reflection, you may think 'Overwrite' is a bad idea.  The other half of my bet is that will be horrified because your logs are allocated only 512k of disk space.  That is kilobytes not mega or gigabytes.

So, take my challenge run the script.  Once you see the results I bet that you change at least one log to: 'Do not overwrite events' (my advice would be start with the Security Log).  Your biggest log is likely to be the Application log, is a miserly 512K enough?  My bet is that you will increase the size of the Application log to 4mb.

Example 1: Listing the Eventlogs


Pre-requisite: Visit Microsoft's site and download the correct version of PowerShell for your operating system.

  • Launch PowerShell
  • Copy the three lines of code below (into memory)
  • Right-click on the PowerShell symbol
  • Edit --> Paste
  • Press enter to execute the code.

# PowerShell script to list all the event logs.
get-EventLog -list

Learning Points

Note 1:  You could learn even more by trying my 'Trusty Twosome' help and also get-member:
a) Help get-Eventlog -full
b) Get-Eventlog | get-Member

Note 2: PowerShell commands are not case sensitive.  Get-eventlog works as well as get-Eventlog.

Guy Recommends: Tools4ever's UMRAUMRA The User Management Resource Administrator

Tired of writing scripts? The User Management Resource Administrator solution by Tools4ever offers an alternative to time-consuming manual processes.

It features 100% auto provisioning, Helpdesk Delegation, Connectors to more than 130 systems/applications, Workflow Management, Self Service and many other benefits. Click on the link for more information on UMRA.

Example 2: Formatting Eventlog Output

The idea behind this script is to give you extra control over the formatting

# PowerShell script to list all the event logs.
$EventVwr = get-EventLog -list
$EventVwr | format-Table log, OverflowAction, MinimumRetentionDays, MaximumKilobytes -auto

Learning Points

Note 1: When I showed example to my friend 'Mad' Mick, he said 'Example 2 is Drivel.  If you going to use that poser formatting rubbish at least shorten it using a wild card*'
$EventVwr | ft log, Over*, Min*, Max* -auto.

Addendum  'What's more' said Mick, 'example 2 is useless because Eventlog just will not connect to another machine'.  'Let me show you a really useful PowerShell script.'   What Mick wrote on the back of a beer mat was Example 3:

Guy Recommends:  SolarWinds' Log & Event Management ToolSolarwinds Log and Event Management Tool

LEM will alert you to problems such as when a key application on a particular server is unavailable.  It can also detect when services have stopped, or if there is a network latency problem.  Perhaps this log and event management tool's most interesting ability is to take corrective action, for example by restarting services, or isolating the source of a maleware attack.

Yet perhaps the killer reason why people use LEM is for its compliance capability, with a little help from you, it will ensure that your organization complies with industry standards such as CISP or FERPA.  LEM is a really smart application that can make correlations between data in different logs, then use its built-in logic to take corrective action, to restart services, or thwart potential security breaches - give LEM a whirl.

Download your FREE trial of SolarWinds Log & Event Management tool.

Example 3: Interrogating Eventlogs on other machines

$Log = "Application"
$Server = "BigServer"
$DifEvtLog = New-Object System.Diagnostics.Eventlog($Log,$Server)
$DifEvtLog.Entries | select -first 50

Learning Points

Note 1:  I said, 'Not bad Mick, but will readers know they must change the variable $Server?'
'Of course they will, readers aren't stupid.' Mick replied.

Example 4: Returning Full Circle - List logs on a DIFFERENT machine

Curiously, at least to my way of thinking, you cannot modify the above script to LIST the logs on a different machine.  Fortunately for us, Brandon Shell has ridden to the rescue by providing the following short, but effective technique.


Learning Points

Note 1:  PowerShell supports three types of brackets, square, parenthesis and curly.  My point is that you must use the correct type of bracket for that particular job.  If you enclosed system.Diagnostics.EventLog in parenthesis, or indeed, removed the brackets all together, the script fails.

Note 2:  Instead of the property  '.', also called a period, or a dot, this script employs the :: operator.  This is referred as the static member accessor.  In conclusion [system.Diagnostics.EventLog]::GetEventLogs($Server) is correct, whereas [system.Diagnostics.EventLog].GetEventLogs($Server), is incorrect.

Remote Eventlog Update in PowerShell v 2.0:

# Investigate PowerShell Get-Eventlog -parameters
Get-Help Get-Eventlog -full

Get-Help confirms that in PowerShell v2.0 Get-Eventlog does support the -ComputerName parameter, thus you can interrogate the Eventlogs on network machines.

Addendum:  Real-life Example.  Kindly sent by Bryan

I have about 750 desktops local to my site, and another 4000 at other sites that I work with.  Back before we had enforced procedures that require changes be reviewed by our desktop team, our security department thought they would change the properties on the security log to 4mb, overwrite events older than 14 days.  Granted, this did work for about 3 weeks.  But we also use Kaseya to manage these desktops, and one night the service account got locked.  Needless to say we came in the next morning to 3000 desktops that could not be logged into because the security event log was full.  A quick VBscript to update the log properties remotely and set them to overwrite as needed was able to execute on the machines, and fixed the problem.  

The same principle can be applied to servers as hackers will often fill the eventlogs to cover their tracks.   We currently make sure that our event log is large enough to capture the data we need, and have it set to overwrite as needed.  I also gained some job security as my managers now respect the fact that they need alternate methods of managing large numbers of machines (and other automated tasks) instead of relying on a single product, like Kaseya.


Seek co-operation between PowerShell's scripts and the operating system's GUI, for example the Event Viewer.  This ezine's script will not only show you how to list the event logs on your current machine, but also how to interrogate logs on a network server.  From a practical point of view, I hope that you will adjust the size and 'Overwrite' settings for at least your Application and Security logs.

If you like this page then please share it with your friends


See more PowerShell examples to read, write and list Windows event logs

PowerShell Home   • Get-Eventlog   • EventVwr -list   • Get-WinEvent   • Remote-WinEvent

WMI Win32_NTLogEvent   • Windows 8 Event Viewer  • Windows 8 Security Event Log

PowerShell real-life task   • Write-Eventlog   • EventVwr errors   • Log Event Manager

Please email me if you have a better example script. Also please report any factual mistakes, grammatical errors or broken links, I will be happy to correct the fault.


Custom Search

Site Home

Guy Recommends: WMI Monitor and It's Free!Solarwinds WMI Monitor

Windows Management Instrumentation (WMI) is one of the hidden treasures of Microsoft operating systems.

Fortunately, SolarWinds have created the Free WMI Monitor so that you can actually see and understand these gems of operating system information.  Take the guess work out of which WMI counters to use for scripts.

Download your free copy of WMI Monitor

Author: Guy Thomas Copyright © 1999-2017 Computer Performance LTD All rights reserved.

Please report a broken link, or an error to: