“Rain falls. Wind blows. Fire burns.” Each of these elements have some form of evidence when the associated action is happening and the average person can react accordingly. However, if you wanted to examine a specific rainstorm for example — reviewing the acid content, seeing if there is volcanic influence on it, checking for the stray sharknado — it can be difficult if you don’t know what you’re looking at. And if you need to catalog a potential mountain of individual raindrops, you could be completely overwhelmed by the sheer number of data points to measure and catalog if you don’t have help.
Individual Windows 10 systems can certainly be their own ecosystems. When they are issued to users from your organization, any number of systems can look exactly the same out of the box and yet act differently depending any number of factors — this stick of memory isn’t quite the same, this CPU has a slightly bent pin, this software installed an update that wasn’t pulled back in time and so on.
If we want to understand what is happening under the hood on a particular system, we need to be able to have it tell us what is happening and the easiest way to do this is to examine the system logs. More than that though, we need to be able to KNOW that we are seeing everything that it can offer us without too much noise. For that, we need to know how to audit our Windows 10 system logs.
Accessing Windows 10 logs is quite easy and, like most Windows functions, there are a number of ways to get there. For this example, we’ll want to right-click on the Start Menu and go to Computer Management.
Once we are in Computer Management, we will want to go down to Event Viewer. From here, we will see a number of categories, but we’ll want to drill down to Windows Logs and then select System.
This will show us the events for the system log that are currently available. The number of entries displayed here can vary wildly depending on the condition of your system, the maximum log size and the nature of the events occurring on your system.
There are three basic levels of events: Informational, Warnings and Errors.
Informational events are just that — informational. They could be good or bad, but most of the time they just mean “oh by the way, this thing happened in case you were interested.” These events happen all the time and, depending on the situation, can be considered noise unless you’re troubleshooting a specific issue. In the example shown above, there is an informational alert showing that Group Policy settings were applied successfully and there were no changes detected.
Warnings are the first level that might require attention. They mean that something has happened and that it could be bad on its own, but it may also mean that there is a larger issue on the way.
In the example shown above, there was a problem trying to get to time.windows.com. This could potentially mean that there is a problem with local DNS, or possibly that the system was just disconnected from the network for a while. If you start seeing Warnings regularly, it may be time to investigate further.
Errors mean that something bad has happened. Whether that is because a service stopped, a piece of hardware failed or even if Windows Updates didn’t work exactly as expected, it’s going to note it down along with any applicable error codes. These error codes are critical during troubleshooting, and in certain cases, just throwing them into a search engine can be enough to get you pointed in the right direction.
Let’s say, though, that in your situation you’re not seeing as many events as you’re expecting — or worse, none at all. First, we’ll want to make sure that your log settings are set the way you want them to be. While we still are in Event Viewer, we can right-click on System and select Properties, and that will give us a place to start.
This allows us to make sure that the log file maximum size hasn’t been set so low that it wouldn’t record any values. Additionally, we can also check the log path to make sure that a file exists there or remove it if we believe it has become corrupted.
Both the previous context menu and the Log Properties have options for Clear Log. It does exactly what it says and removes all values out the log with one key exception — it creates a new log entry saying that the log was cleared. If you are concerned about the integrity of your logs, this is a line to look for.
We can also make sure that as many events as possible are recorded in our system log through the use of Local Security Policy. To get here, we’ll want to go to Start and type in “Local Security Policy”.
For the options we’re looking for, we’re going to want to go to Local Policies and drill down to Audit Policy.
From here, we will see options for a wide variety of audit options for logs. The specific one we’d want to look for in this scenario is “Audit System Events”. With this, we can force Windows to record as much information as possible to the local Windows 10 system. Double-click on Audit System Events and select Success and Failure before pressing OK.
Let’s say for a moment though that we wanted to go further and across a number of systems all at once. Through the use of Group Policy and Active Directory, we can do this.
In order to access this section, you’ll need to go to Group Policy Management through the method of your choice. Once here, right-click on whichever GPO you wish to use and select Edit. We can then go down to Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\System.
This will give us a number of advanced options that, when set, will be applied to as many systems as we choose in the previous screen. This can be very useful when your organization wants to gather as much information as possible about their environment.
System logs are one of those tools that are always there, but most people don’t really think about until something is broken. As long as they are configured correctly, however, they are more than capable of continuing to do their job right along with no real user intervention. It is important to remember, though, that system logs are only one step of log auditing.