Ezine 144 PowerShell's Eventlog -list
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
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.
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.
Pre-requisite: Visit Microsoft's site and download the correct version of PowerShell for your operating system.
Note 1: You could learn even more
by trying my 'Trusty Twosome' help and also get-member:
Note 2: PowerShell commands are not case sensitive. Get-eventlog works as well as get-Eventlog.
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.
The idea behind this script is to give you extra control over the formatting
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*'
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:
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.
$Log = "Application"
Note 1: I said, 'Not bad Mick, but will readers know they must change the variable $Server?'
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.
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 confirms that in PowerShell v2.0 Get-Eventlog does support the -ComputerName parameter, thus you can interrogate the Eventlogs on network machines.
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
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.