We wanted to have more details and ability to search across our entire estate of apps and devices in Intune and decided to Enhance Intune Inventory data by creating a custom data collector using a PowerShell script to gather data from all our devices using Proactive Remediations. The native logging in Intune is continuously improving , but we still see need for enhanced custom inventory in many cases.
What is Log Analytics?
Log Analytics used to be a service in Operation Management Suite (OMS), retirement of OMS brand was announced in April 2018 and start moving into Azure Monitor. In February 2019, Log Analytics, Log Analytics workspaces, and Management solutions became part of Azure monitor components, and OMS portal has been officially retired on May 15, 2019.
Log Analytics is a tool in Azure, used to edit and run log queries with data in Azure Monitor logs. We can write a simple query that return a set of records, and we can use more advanced KQL query language to analyze and return data that match our particular requirements. Besides running log queries, we can also collector our own data as custom logs, create beautiful workbooks, and integrated with alerts and advance automation, for example Logic Apps.
Custom Logs
Azure Monitor HTTP Data Collector API is currently in public preview, we can use the HTTP Data Collector API to send log data to a Log Analytics workspace in Azure Monitor from any client that can call a REST API. In our scenario, we want our Windows 10 clients to send device and application inventory data to Log Analytics workspace. What we need here is a PowerShell script to collect the data locally on the devices, and then a Log Analytics workspace to send the data to. It is strongly recommended that all Intune logs from the Diagnostics tabs also is enabled and forwarded to the same log workspace in Azure.
The Log Workspace setup
We are not going into details on how to setup the log workspace itself, but there is 2 parameters we need from the workspace for this solution to work.
- Workspace ID
- Shared Key
These 2 values can be found under Agents management in the Log Analytics workspace:
The script
The script Invoke-CustomInventory.ps1 will by default collect both the defined inventory of devices and apps. If you only want to collect one of them, you need to change the variables in the initialize region where you also need to add your 2 values for your workspace:
#region initialize # Enable TLS 1.2 support [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # Replace with your Log Analytics Workspace ID $CustomerId = "" # Replace with your Primary Key $SharedKey = "" #Control if you want to collect App or Device Inventory or both (True = Collect) $CollectAppInventory = $true $CollectDeviceInventory = $true # You can use an optional field to specify the timestamp from the data. If the time field is not specified, Azure Monitor assumes the time is the message ingestion time # DO NOT DELETE THIS VARIABLE. Recommened keep this blank. $TimeStampField = "" #endregion initialize
The full script is available at this location: Github
Inventory script is updated to a newer version to support BIOS Update compliance among other new additions. We do also not collect computer location information anymore for privacy reasons.
Running the Script
We recommend using Endpoint Analytics – Proactive Remediations for this, but if that is not an option, you can also run this as a scheduled task on your computers. We recommend 1 daily run of the inventory script.
Go to the Endpoint Analytics blade in Endpoint Manager admin center and click on Proactive remediations. Here you click on Create script Package.

Now make sure you have updated the script with your own workplaceID and SharedKey before you upload the file to Intune.
Click next on Scope tags, and go to Assignments. Here you can either choose all devices, or just a group of devices you want to start testing on. We recommend using device groups for this. Remember to verify the schedule. I run this every morning at 09:00 AM on all devices.
Now continue through and create the script package.
Monitor script execution
To verify that the script is running and actually publishing data to your workspace, use the Overview blade on your script package.
Now this all looks good, we don’t see any errors on the overview page. But let us take a deeper look, and go to the Device status blade. We are only interested in Device name, Detection status, sync time, Pre-remediation detection error (This is where you will see script errors) and Pre-remediation detection output.
And lets have a look at the details of the output by clicking on Review (in blue) on one of the entries.
What we see here is that both Inventories have been uploaded OK to Log Analytics. Return code 200. And that the Device inventory size is 1.8Kb and the App Inventory is 22.1Kb. This will give you a pointer to the cost of this setup in your environment. Device Inventory will be pretty static in size, while App inventory size is driven by the number of apps on your devices.
Reports
So the reason for this is to extend the inventory beyond what we get natively in Intune and allow us to easily search through it. We have some examples of queries and workbooks in the github repository here
Some examples screenshot’s from the workbooks:
What data is collected?
DeviceInventory
Device Inventory is found in the Custom Log DeviceInventory_CL
- TenantId
- SourceSystem
- TimeGenerated
- InstallDate_s
- ManagedDeviceID_g
- WindowsVersion_s
- Manufacturer_s
- BitlockerVolumeStatus_s
- OSRevision_s
- SMBIOSUUID_g
- SystemSKU_s
- SystemSkuNumber_s
- NetworkAdapters_s [Array]
- MacAddress
- NetIPv4Adress
- NetIPv4DefaultGateway
- NetInterfaceAlias
- NetInterfaceDescription
- NetProfileName
- TPMEnabled_s
- OSName_s
- ComputerUpTime_s
- ManagedDeviceName_s
- DefaultAUService_s
- OSBuild_s
- SerialNumber_s
- CPUName_s
- TPMPresent_s
- BitlockerCipher_s
- TPMActived_s
- CPUManufacturer_s
- AzureADDeviceID_g
- DiskHealth_s [Array]
- Disk 0 Read Errors
- Disk 0 ReadErrorsTotal
- Disk 0 ReadErrorsUncorrected
- Disk 0 Temperature Delta
- Disk 0 WriteErrorsTotal
- Disk 0 WriteErrorsUncorrected
- Disk Number
- Disk Wear
- FriendlyName
- HealthStatus
- MediaType
- BiosDate_s
- TPMReady_s
- ComputerName_s
- FirmwareType_s
- PCSystemType_s
- TPMThumbprint_s
- AUMetered_s
- LastBoot_s
- BitlockerProtectionStatus_s
- CPULogical_s
- Memory_s
- CPUCores_s
- BiosVersion_s
- Model_s
- PCSystemTypeEx_s
App Inventory
App Inventory is found in the Custom Log AppInventory_CL. We collect the following information about all apps detected on the device (System and current user)
- TenantId
- SourceSystem
- TimeGenerated
- AzureADDeviceID_g
- ComputerName_s
- AppName_s
- AppUninstallRegPath_s
- AppVersion_s
- AppPublisher_s
- AppUninstallString_s
Feedback
If you have any suggestion or feedback to workbooks or the script, feel free to comment here or in github. If you have any modification or add-on please feel free to do a pull request in github as well.
(28244)
Fantastic work gents, super helpful!
Unfortunately where i work there is a culture of closing laptop lid = shut down resulting in many devices showing miraculous uptimes of 30 days + is there a way we can enforce this with a toast notification to inform the user? say device has been up x days enforce a shut down with prompt to end user?
Is there a specific reason for setting the payload limit?
Thats a limitation of the API itself.
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/data-collector-api#data-limits
I’m running into a issue regarding the app inventory, i think its exceeding the cap limit. Is there a specific reason that payload size is set to 32 mb?
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/data-collector-api#data-limits
Thanks for sharing this article, I dont get why this isn’t yet in intune. This is crucial information that you need for reporting about the environment. It seems that Microsoft is not willing to provide this…
Anyhow, I have a question about the workbook in the github repo.
I am a beginner in KQL and I am getting issues with the Device Inventory workbook. The networkadapters field is being recognized as a string and therefore I am unable to project the sub key and value pair. Any idea how to address this?
The current workbook has some bugs. A new one will be released soon.
How do you avoid having the shared key for the Log Analytics workspace in plain text on the PCs? My understanding is that the PowerShell script is left on the PC after it runs, so it’s accessible to anyone with access to the folder it resides in.
In the current version local administrative users can see the sharedkey in the IMECache. Solution is in the works, but will require more azure services to be used.