[Autogenerated] As servers run that generate tons of event log data
that provides insight into performance and security.
Let's look at some high value events to focus on first
application or timeouts on IIS servers.
These help identify app issues affecting users.
Next tracking log on failures for disabled ad accounts is useful for auditing
potential security breaches and monitoring for system resource exhaustion
events allows proactively tuning before outages occur.
Getting familiar with key event scenarios like this will help
guide you to what you're searching for.
I'm here on my PowerShell console,
pulled up with the PowerShell remoting session connected to
my problematic IIS server in question.
So lets start with a simple example, querying the Windows of vlogs.
The most common log is the system log which contains
events log by Windows system components.
And to query this log, we can use the GWIN event command.
So let's run Gwent now to query the system log and
look at the five most recent events.
You can see this return the five most recent events from the system blog.
Simple enough get when event returns various attributes related to each event,
including the time stamp message and more each event is separated by
the event provider or the source of the event.
Now that you have the basics down.
Let's look at the log specific to IIS first.
What if you don't know where the IIS records are even recorded at?
Let's look at all the event log names first,
using the list log parameter and providing a couple of wildcards here.
I can find all the logs with the text ias in them somewhere.
You see the official is event logs as the three on the bottom there.
And a mac one that I've created at the top called IIS event log.
I created this one to easily show you how to query various events.
I can then specify the IAS event log,
just a single event log and only find events in that event log.
So we're now seeing ias specific events in the log.
You can also filter event logs down by the provider name.
The provider is capable of recording events to many different
event logs using the provider name parameter.
You can see that the provider of IIS troubleshooting demo did not
record events inside of the IIS event log event log.
So maybe you need to filter these down to only critical
errors and warnings to pinpoint issues.
Well, let's retrieve critical errors and warnings which are levels one and two.
Now,
I'm filtering out all the low level noise and focusing on events
that are likely to indicate problems and also introduced a new
parameter here called filter hash table.
Notice that I consolidated the log name into a hash table and
added the level key filter hash table lets you specify multiple
filters inside of a hash table.
But maybe you only want to see events that occurred,
I don't know, 24 hours ago or more recent.
Now, I'm getting a little fancier here by dynamically creating a start time date,
but it works great here for the start time.
I'm getting the current date and then removing one day
from it using a time span object,
you can filter on just about anything you wish with the
filter hash table parameter legacy.
We have three events recorded since yesterday.
So by walking through GWIN event usage,
we've learned how to pinpoint vital information in the Windows logs.
This will let you rapidly troubleshoot issues like
IAS crashes and a whole lot more.