This is the first in what will likely be many “News:” articles of mine. These are pretty much exactly what they sound like, just simple newsletters regarding what I have been working on, some things that have received some updates and adjustments, and what you can expect coming up.
Updates:
Fast Startup: System Usage & Device Inventory
First up, pertaining to both System Usage and Device Inventory is the topic of Fast Startup.
In short, I had some wires crossed during the System Usage policy article and you do not need to deploy the sleep state policies. However, you do need to deploy an app (as there is no policy) to disable Fast Startup. This is fully explained in the updated article here under the header “Update Regarding Fast Startup.”
Following this topic, the use of fast startup can make tracking device uptime in Device Inventory problematic. A note briefly explaining this has been added to the Device Inventory Overview here under the header “Uptime Monitoring.” That said, the note references the above link in the System Usage Policy article as that article explains it in more depth. In short, for proper uptime monitoring, one should disable fast start OR make sure they understand the complexities it brings.
Device Inventory: Uptime Monitoring
Still following the topic of Uptime Monitoring, I realized the last boot time was pulling in the device’s local time zone, not UTC. The original code is below.
$ComputerOSInfo = Get-CimInstance -ClassName Win32_OperatingSystem
$ComputerLastBoot = $ComputerOSInfo.LastBootUpTime
This has been updated to ensure the date/time is translated to UTC. The new Device Inventory V1.1 script with this change and the below change can be found here.
$ComputerLastBoot = ($ComputerOSInfo.LastBootUpTime).ToUniversalTime()Computer Name:
As many of my article’s mention, my introduction to Log Analytics was from the Intune Enhanced Inventory project by Jan Ketil Skanke of the MSEndpointMgr team and as such, many of my scripts were based on their original works. One of the remnants of their scripts which made its way into nearly all of my scripts was how the Computer Name is queried. This queries return filled in the ComputerName value/column and got used for other purposes such as the filtering of Windows Events.
$ComputerInfo = Get-CimInstance -ClassName Win32_ComputerSystem
$ComputerName = $ComputerInfo.Name
I have discovered that on literally .0011% of devices, this query fails citing either an Access Denied or a Class Not Found error. Neither of these makes much sense as we are running as admin, just as we are on the other thousands of devices executing this query without issue, nor can I explain how this class could just vanish.
While this is likely indicative of other problems the machine is having, it’s ultimately easy to correct by changing to the below. This method is my preferred option and is already in use in other areas/functions in the script. I validated that devices having issues with the above commands have no such issues when going this route.
$ComputerName = $env:COMPUTERNAMEThis has been updated in the following collectors…
- Windows365AppCollectorV2.ps1 – The sibling W365 Event Collector script used the ENV method on birth.
- ATTM System Usage Script V1.2.ps1 – Without this correction, devices which exhibit this issue (.0011%) may cause events to ingest that should have been filtered out. Additionally, events may ingest that lack a value in the ComputerName field.
- ATTM Device Inventory Script V1.1.ps1 – Without this correction, devices which exhibit this issue (.0011%) may cause events to ingest that lack a value in the ComputerName field.
Future Plans:
Log Analytics for Windows Patch Compliance and Monitoring:
I bumped into a collection script over a year ago (maybe two?) which pulled a multitude of registry keys pertaining to Windows Updates and then displayed them in a workbook along with various queries to help determine if any of them were problematic. This collector was based on GPO though so, I worked to update it to work with Intune policy and its registry key locations, as well as created a new collector to pull Windows Update events.
Event collection allowed us to see when devices were updating, what KBs they were installing, what KBs were failing, trend monitoring, etc. All in all, this solution allowed you to verify the settings you configured in Intune were actually properly in place on devices, as well as that those devices were then doing what those settings said they should successfully.
Since releasing my last series (System Usage) I have been working to get these two collectors and the corresponding workbook ready for release. However, I went digging to try and find the original creator of the workbook I had found and ultimately stumbled into some other methods of capturing some of this same information. At first glance, it appears to me the other methods may be better. While I am not sure of that yet, with that potiential and that this collector was already taking longer than expected, I think it makes more sense for me to pivot to another project for now and circle back to this once my backlog is otherwise handled.
App Usage:
The project I will instead be pivoting to is the collection of Application Usage. This will collect events 4688 and 4689 where a human was likely involved (not the system account, machine account, etc). In other words, every time an employee starts or stops an application. This is a great addon to System Usage as far as understanding who is using a system and when, understanding where there may be click-to-run apps that don’t install and are getting used, understanding who is and is not using their licensed apps (and thus where license reduction may be possible), and so on. More details will be provided in the overview article.
With some luck, this will be done by the end of October.
I have one other item I will likely hit before circling back to Windows Patch, but I don’t want to get too ahead of myself here.
Thanks for reading and stay tuned!
Azure to the Max 