In this two-part series I will cover a solution I recently created to manage HP driver updates on Windows workstations. In part 1, I’ll show you a reporting solution giving you visibility of available HP driver updates across your managed estate and in part 2, I’ll show a flexible solution for deploying driver updates, whether all updates, by category, criticality or specific updates to specific devices.
Background
First, a bit of background as to why this solution was created. Some time ago, we enabled drivers in Intune-managed Windows Update for Business, and for the most part this has been quite successful. The user experience is good and drivers are generally updated without any user knowledge, except for the reboot prompts, and except for BIOS firmware updates which will, of course, be visible to the user at the pre-boot stage.
However, if you run the HP Image Assistant on any workstation you’ll quickly find that there are several out-of-date drivers. In my naivety, I assumed that most all missing driver updates would be installed through Windows Update but clearly this is not the case.
A quick search of the update history in Windows Settings shows that several driver updates have been installed, but some of them are woefully non-descript, for example SoftwareComponent, or Extension – so what exactly is getting updated?
With the help of a little PowerShell I was able to determine the friendly names of the components being updated using the version numbers:
Get-CimInstance -ClassName Win32_PnPSignedDriver -Filter "DriverVersion = '6.0.9341.1'" |
Select Description,DeviceName,FriendlyName,DriverDate,DriverVersion,DriverProviderName,Manufacturer
Here is a list of some of the drivers with their more friendly names from my own laptop, and who could have guessed that’s what they were, right?!
| Windows Update name | Friendly driver/device name |
|---|---|
| HP Development Company, L.P. – SoftwareComponent – 1.0.4.27 | HP LAN/WLAN/WWAN Switching and Hotkey Service |
| Intel® Corporation – Extension – 1.41.1193.0 | Thunderbolt(TM) Toast Component, Thunderbolt(TM) HSA Component, Thunderbolt(TM) Controller – 15E8 |
| HP Inc. – SoftwareComponent – 1.52.3317.0 | HP Application Enabling Services |
| HP Inc. – SoftwareComponent – 4.2.1217.0 | HP Device Health Service |
| Intel – SoftwareComponent – 7.9.1.3 | Intel(R) XTU Component Device |
| Intel – System – 11.7.0.1006 | Intel(R) Watchdog Timer Driver (Intel(R) WDT) |
| HP Development Company, L.P. – Keyboard – 11.1.8.1 | Standard 101/102-Key or Microsoft Natural PS/2 Keyboard for HP Hotkey Support |
| Intel – net – 22.170.0.3 | Intel(R) Wi-Fi 6 AX201 160MHz |
| Intel – SoftwareComponent – 2227.71.54.0 | Intel(R) Wireless Manageability |
| Sound research Corp. – SoftwareComponent – 2.0.10.69 | Sound Research Audio Effects Component |
| Intel – Net – 12.19.2.45 | Intel(R) Ethernet Connection (10) I219-LM |
| Intel – System – 2220.3.1.0 | Intel(R) Management Engine Interface #1 |
| Intel – SoftwareComponent – 2227.3.3.1 | Intel(R) Management and Security Application Local Management |
| Intel – Ports – 2219.3.0.0 | Intel(R) Active Management Technology – SOL |
| Realtek – SoftwareComponent – 12.0.6000.269 | HP Audio Hardware Support Application |
| Realtek Semiconductor Copr. – MEDIA – 6.0.9341.1 | Realtek High Definition Audio (Realtek(R) Audio) |
From this list we can see that, whilst there are some ‘core’ drivers like WiFi or NIC drivers getting updated, a majority seem to be the software components of drivers, like services or app binaries.
My guess is as to why there is a disparity between the drivers being installed via Windows Update and the drivers that can be installed via the HP Image Assistant is that (1) vendors simply do not make all driver updates available through Windows Update and (2) it takes longer for drivers to get through the signing process required for publishing with Windows Update.
In any case, I wanted to have both visibility of missing drivers across my devices and the ability to update drivers as and when I consider it necessary. For example, if you subscribe to the HP Security Bulletins, you’ll get notified of some high severity updates that may be applicable to your devices and you’ll want to have a mechanism to get your devices updated in a timely manner.
So on to the solution…
Driver Analysis Script
First up, I deploy a PowerShell script to my devices on a schedule using Proactive remediations in Intune.
The script does the following:
- Downloads and extracts the latest version of the HP Image Assistant if not already present
- Runs an analysis of available drivers in any category
- Reads the resulting XML report and builds a list of update recommendations
- Posts those recommendations to a Log Analytics workspace in Azure
- Logs all activities to a local log file
The Log Analytics workspace table becomes the data source for the Power BI report.
Here is an example of the log file output:
The script can be download here.
There are a couple of parameters which need to be set in the script which are described below:
- WorkspaceID. The ID of your Log Analytics workspace, which you can get from the Overview page.
- PrimaryKey. The primary key of your Log Analytics workspace, which you can get from the Agents page (more on this in a sec).
- LogName. This is the name of the custom table that will be created in the Log Analytics workspace. This will be suffixed with “_CL” when created as for all custom logs. Note that the PowerBI report expects to use the parameter value that is already present in the script, so if you change it you’ll need to also change the data source query in the report.
- ParentFolderName. This is the name of the folder that will be created on the local machine under %ProgramData% and in the registry under HKLM:\Software.
- ChildFolderName. This is the name of the subfolder that will be created underneath the parent folder.
- MinimumFrequency. This value, in hours, simply sets a gate that prevents the script from running too frequently, as can be the case with PR scripts that can attempt to run multiple times in different user contexts, even with a one-time deployment.
I appreciate that for some, having the workspace shared key in plain text in the script is a security concern, and I totally respect that. For myself, I consider this to be low risk and the benefits can outweigh the risk. Some things to consider:
- Although the PR script is cached on the client side, it is only accessible in an elevated context.
- As far as I can tell, the shared keys can only be used to post data to your workspace, or to connect the now deprecated Log Analytics agent to the workspace. It cannot be used to either query data or perform any activity on the management plane – this requires Azure AD authentication.
- Probably the worst that a bad actor could do with that key is to post unwanted data to your workspace. But what motivation does anyone have to do that? What’s in it for them?
- Keys can be rotated in the event they are compromised.
Once you’ve populated the parameters, create a Proactive remediations script in Intune and use the script as a detection script – no remediation script is needed. Personally I run this on a schedule every 3 days as drivers don’t get updated that often and I can live with the latency.
The Report
Once you’ve got some data in your Log Analytics workspace, create the report. You can download the Power BI template here.
Upon opening, you’ll be prompted for your Workspace ID and the data retention period of your workspace. You can find/change this in the Usage and estimated costs page of the workspace, and the Data Retention menu item. I use a 60 day retention period – the value you use will determine how much historical data you can view in your report.
If it’s your first connection to the Log Analytics workspace in Power BI, you’ll be asked to sign in and connect – use an Organizational account and make sure the account has at least the Log Analytics Reader role in the Log Analytics workspace.
Once connected, you’ll see your data in the report.
You can slice and dice this data any way you wish, for example, to identify missing updates marked as critical, missing updates per model, which drivers are updated by which SoftPaq, different driver versions you have out there, or missing drivers for a specific device etc.
You can then use this data to decide which updates you want to deploy and who you want to target.
In the next blog, we’ll look at how to deploy these driver updates as well as an updated version of the report that includes a driver installation log.
Great article Trevor, looking forward to part 2!
I’m not that up to speed on the pricing model for Log Analytics. Do you have any idea on a cost for ingesting this data for a large number of devices and retaining it for 30 days?
You get 31 days for free but you can find more detailed pricing info here: https://azure.microsoft.com/en-gb/pricing/details/monitor/
Can you explain what >>
top-nested 1 InventoryDate=InventoryDate_t by temp1=max(InventoryDate_t),
means? I had 2 different days of data and I was only seeing the latest until I changed it to 2, but I don’t know what that does.. should it be 30 if I have 30 days in LAW?
Yes, this returns only the most recent data per device. If the script is running on a schedule it will send data regularly to the LAW, but you don’t want to report on outdated data – only the most recent.
Nice article Trevor!
I’m getting an error when trying to upload data to Log Analytics.
“Unable to connect to the Log Analytics endpoint: Retry logic is active
Ending with “Gave up trying to connect to the Log Analytics endpoint. The log entry will not be posted”
WorkspaceID and PrimaryKey are correct – double checked.
Any idea what’s needed to proceed with the upload?
I would suspect the LA workspace endpoint is being blocked by a firewall?
Amazing work, thank you for sharing.
Appreciate the feedback 🙂