As explained, the System Usage monitoring makes use of Windows Event logs for data gathering. While the Event Log has a ton of useful information by default, some events only log when enabled via an additional policy. Additionally, some won’t log at all until certain power settings are changed (See part 1.1, startup and shutdown events).
This article will cover further enabling additional auditing items to be logged, expanding the default limited size of the security log to assist with that, and altering the device’s power settings to ensure fast startup is not used instead of true restarts/shutdowns/startups.
- Head to the Intune Home
- Go to Devices, Configuration Profiles, and hit Create Profile
- Chose a platform of Windows 10 and Later and a profile type of Settings Catalog
- Name it and describe it as you see fit, this doesn’t affect the policy itself.
- Choose Add Settings
- Search for “Audit Other” and select the Auditing result
- Select Audit Other Logon Logoff Events
- Configure it for Success+Failure
- Again, choose Add Settings
- Search for “Account Logon Logoff Audit Logoff” and select the Auditing result
- Select Account Logon Logoff Audit Logoff Events
- Configure it for Success+Failure
- Again, choose Add Settings
- Search for “Account Logon Logoff Audit Logon” and select the Auditing result
- Select Account Logon Logoff Audit Logon Events
- Configure it for Success+Failure
- Again, hit Add Setting
- Search for Specify the maximum log file size
- Choose the \Security result
- Check the box for the Specify the Maximum Logfile Size option and Maximum Log Size if it does not auto select.
- Turn the policy to Enabled
- Enter a maximum size of 204800 which is 200 MB
Note: For those concerned about the size of 200MB, as explained in the information bubble next to the enable/disable toggle and pasted below, this log can easily handle MUCH larger sizes (2TB). 200MB in my experience will give you roughly two+ weeks of events on an average device with these auditing settings enabled. If directly viewing events, Event Viewer is slow to load that full 200MB, but that is easily fixed by limiting the range of your search with a filter.
Policy Description: This policy setting specifies the maximum size of the log file in kilobytes. If you enable this policy setting, you can configure the maximum log file size to be between 20 megabytes (20480 kilobytes) and 2 terabytes (2147483647 kilobytes), in kilobyte increments. If you disable or do not configure this policy setting, the maximum size of the log file will be set to the locally configured value. This value can be changed by the local administrator using the Log Properties dialog, and it defaults to 20 megabytes.
Power Settings:
Update Regarding Fast Startup:
Under the below header “Original Policy” you will find the original policies deployed in this series While these policies are still good to deploy from a security perspective, they do NOT directly solve the root cause of our issue. As such, you no longer need to deploy them as part of this guide.
Before I proceed further, I want to better explain fast startup. Fast startup is really a form of sleep / hibernation when shutting down and starting back up. When enabled and you press shutdown in the start menu or hit the power button, the system doesn’t truly shutdown, doesn’t reset uptime, and doesn’t make the logs for a shutdown/startup because it didn’t do one. It basically just went to sleep and will wake back up when you press the power button again. When you do press the power button, it will look like a cold boot, the BIOS screen/logo will even go by, but it won’t actually be a fresh start. It’s just resuming from hibernation.
As you can likely guess, disabling fast startup will slow down system boot time but, on modern systems with solid state storage it’s almost unnoticeable. Furthering that point, restarts do not use fast startup. As such, your new cold boot time will only be as slow as the boot following a restart. Odds are you haven’t even noticed that scenario is slower.
Unfortunately, while there is policy to forcibly enable fast startup, there is no policy to forcibly disable it. Instead, the following registry key will need to be deployed via a script or app. To my pleasant surprise, this has not required a reboot to apply in my testing.
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled
Value: 0
I have already built this into a very simple script on my GitHub here, as well as packaged it into an IntuneWin file here. I prefer to use an app as I can deploy/require that during ESP and can use a detection rule in conjunction with requiring the app to ensure it stays set. I have tested this in ESP in my environment without issue.
Install configuration information:
Install command: powershell.exe -executionpolicy bypass -windowstyle hidden ".\DisableFastStartup.ps1"
Detection Rule:
Key Path: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power
Value Name: HiberbootEnabled
Detection Method: String Comparison
Operator: Equals
Value: 0
Original Policy:
Again, these two policies are no longer required.
Next is the Power settings. If you wish, you can break this out into its own policy. Again, these are to prevent using sleep states over real shutdowns and startups as discussed in the Technical Details and Limitations article. In short, sleep states don’t reset uptime, are not true restarts/shutdowns, and don’t log the shutdown/restart/start events.
- Choose Add Settings
- Search for “Allow standby states (S1-S3) when sleeping (on battery)” and select the Sleep Settings result
- Check Allow standby states (S1-S3) when sleeping (on battery)
- Configure it to Disabled
- Again, choose Add Settings
- Search for “Allow standby states (S1-S3) when sleeping (plugged in)” and select the Sleep Settings result
- Select Allow standby states (S1-S3) when sleeping (plugged in)
- Configure it to Disabled
At this point you can his Next, scope it to tags as you see fit, assign it as needed, and create the policy! Keep in mind the policy will take time to sync to devices and may require a reboot to apply.
Conclusion:
You should now have your event logging properly configured to continue with this series. Keep in mind the policy will take time to sync to devices and may require a reboot to apply.
The Next Steps:
See the index page for all new updates!
Log Analytics Index – Getting the Most Out of Azure (azuretothemax.net)
I will be putting the System Usage guides on the Log Analytics Index page under the Windows Endpoint series.
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 