Event logs are an important troubleshooting asset. Windows and Windows applications can log a significant amount of information that can be invaluable in both troubleshooting and in the day-to-day administration of Windows Server 2019.
Windows computers maintain a set of event logs that document events that occur on a given machine. Any time an event occurs, the application or service can log events that can then be used to help in the debugging process.
In Windows, there are two types of event logs: Windows logs and application and services logs. Windows logs began with Windows NT 3.1 and continue in Windows Server 2019 and are important components in troubleshooting and system monitoring.
Windows Vista added a new category of logs, application and services logs. These logs contain events that are within a single application, service, or other Windows component. Windows comes, by default, with a set of application and service logs—adding components such as new Windows features or roles often results in additional application and service logs.
These logs give you a great picture of what your system is actually doing. Additionally, you can also add new event logs and enable scripts to log events that occur while the script is running.
PowerShell provides you with several useful cmdlets to help you comb the event log looking for key events. The Get-EventLog enables you to get details of the logs that exist as well as retrieving log events from the Windows logs. With Get-WinEvent, you can examine both the classic Windows logs and the new application and services logs. You use both these cmdlets in this recipe.
You run this recipe from SRV1, a domain joined server in the Reskit.Org domain. You also use the domain controller DC1. Reskit.Org in this recipe.
- Get the core event logs on
SRV1:Get-EventLog -LogName *
- Get the remote classic event logs from
DC1:Get-EventLog -LogName * -ComputerName DC1
- Clear the application log on
DC1:Clear-EventLog -LogName Application -ComputerName DC1
- Look at the types of events on
SRV1:Get-EventLog -LogName Application | Group-Object -Property EntryType | Format-Table -Property Name, Count - Examine which area created the events in the application log:
Get-EventLog -LogName System | Group-Object -Property Source | Sort-Object -Property Count -Descending | Select-Object -First 10 | Format-Table -Property Name, Count - Examine all the event logs on
SRV1:$LocEventLogs = Get-WinEvent -ListLog * $LocEventLogs.Count $LocEventLogs | Sort-Object -Property RecordCount -Descending | Select-Object -First 10 - Examine all the event logs on
DC1:$RemEventLogs = Get-WinEvent -ListLog * -ComputerName DC1 $RemEventLogs.count $RemEventLogs | Sort-Object -Property RecordCount -Descending | Select-Object -First 10 - Look at the
WindowsUpdateClientoperational event log on the localhost and discover the updates that the WU client has found:$LN = 'Microsoft-Windows-WindowsUpdateClient/Operational' $Updates = Get-WinEvent -LogName $LN | Where-Object ID -EQ 41 $Out = foreach ($Update in $Updates) { $HT = @{} $HT.Time = [System.DateTime] $Update.TimeCreated $HT.Update = ($Update.Properties | Select-Object -First 1).Value New-Object -TypeName PSObject -Property $HT } $Out | Sort -Property Time Sort-Object -Property TimeCreated | Format-Table -Wrap
In step 1, you used the Get-EventLog cmdlet to display the core event logs on SRV1, which looks like this:
In step 2, you retrieved the core event logs remotely on DC1, which looks like this:
In step 3, you cleared the application log remotely on DC1. There is no output from this step.
In step 4, you examined the event types that are in the event log on SRV1, which looks like this:
In step 5, you looked at the Windows event logs, using Get-EventLog to get all the different Windows components that are logging events to the System log. This step then displays the ten areas that are logging the most entries on SRV1, which looks like this:
In step 6, you displayed the total number of event logs found by Get-WinEvent, and then you listed the 10 busiest extended logs, as follows:
In step 8, you displayed the number of Windows updates that were discovered (and installed) on SRV1, which looks like this:
In step 1 and step 2, you examined the Windows event logs that exist on two systems (SRV1 and DC1). As you can see, the logs that are available differ—on DC1, you can see the Active Directory Web Services log, which does not exist on SRV1.
In step 3, you cleared the application log on DC1. As a best practice for event logs, you should only clear a log once you have copied the log elsewhere for safe keeping. Naturally, mileage varies on this point, since the vast majority of event log entries are not of very much use in day-to-day operations.
In step 4, you saw the different classifications of events, including one with a name of 0. In this case, the property containing the event log entry type is based on an enum, and this enum was not updated, so PowerShell was unable to display the entry name for this event log entry type.
In step 6 and step 7, you examined the service and application logs that exist on SRV1. These steps demonstrate how additional features or applications can result in additional event logs.
Step 8 showed you how to dive into a specific event in a specific event log. In this case, you examined the Software Update service's operational log to discover events with an event ID of 41. In general, when retrieving information from your event logs, you need to know which log and which event ID to look for.