In regards to drivers and BIOS updates on workstations in your environment, a lot of organizations have held the mindset for many years that ‘If it ain’t broke, don’t fix it!‘. We did too up until we had a Windows Desktop RaaS with Microsoft in 2014.
Premier Services site: https://services.premier.microsoft.com/assess?
What we found is that by not managing our driver and BIOS versions, we had no baseline, and there for a very difficult time troubleshooting hardware and performance related issues. Now we inventory our driver information in SCCM, and can report on how we are doing with versions out in our environment. This information is not available out of the box, so it takes a little setup.
Inventoring the Win32_PnpSignedDriver WMI class
- This class cannot be inventoried directly, so a custom WMI class must be created and populated
- This has been tried before, and not many had luck
- http://www.systemcentercentral.com/forums-archive/topic/win32_pnpsigneddriver-inventory/
- https://blogs.technet.microsoft.com/configmgr_geek_speak/2013/11/10/inventorying-and-reporting-network-adapter-driver-details-and-how-to-report-only-the-wireless-type-with-bonus-mini-primer-on-sql-report-builder-in-configuration-manager-2012/
- http://www.myitforum.com/forums/SMS-MOF-file-for-Win32_PnPSignedDriver-m178956.aspx
- https://social.technet.microsoft.com/Forums/systemcenter/en-US/20e7e3f7-31c0-48f5-9d99-5d2b215bb218/win32pnpsigneddriver-diles-to-add-to-smsdefmof?forum=configmgrgeneral
- Special thanks to EASULIN and Sherry Kissinger for providing the bulk of the process and inventory scripts
Like all scripts, they should be written in PowerShell, so I created one for a SCCM Script Compliance Item in PowerShell.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
## Define new class name and date $NewClassName = 'Win32_PnpSignedDriver_Custom' $Date = get-date ## Remove class if exists Remove-WmiObject $NewClassName -ErrorAction SilentlyContinue # Create new WMI class $newClass = New-Object System.Management.ManagementClass ("root\cimv2", [String]::Empty, $null) $newClass["__CLASS"] = $NewClassName ## Create properties you want inventoried $newClass.Qualifiers.Add("Static", $true) $newClass.Properties.Add("DeviceClass", [System.Management.CimType]::String, $false) $newClass.Properties.Add("DeviceName", [System.Management.CimType]::String, $false) $newClass.Properties.Add("DriverDate", [System.Management.CimType]::DateTime, $false) $newClass.Properties.Add("DriverProviderName", [System.Management.CimType]::String, $false) $newClass.Properties.Add("DriverVersion", [System.Management.CimType]::String, $false) $newClass.Properties.Add("HardwareID", [System.Management.CimType]::String, $false) $newClass.Properties.Add("DeviceID", [System.Management.CimType]::String, $false) $newClass.Properties.Add("ScriptLastRan", [System.Management.CimType]::String, $false) $newClass.Properties["DeviceName"].Qualifiers.Add("Key", $true) $newClass.Properties["DeviceID"].Qualifiers.Add("Key", $true) $newClass.Put() | Out-Null ## Gather current driver information Get-WmiObject win32_pnpsigneddriver -Property DeviceClass, DeviceName,DriverDate,DriverProviderName,DriverVersion,HardwareID,DeviceID | where{$_.DeviceClass -ne 'VOLUMESNAPSHOT' -and $_.DeviceClass -ne 'LEGACYDRIVER' -and $_.DriverProviderName -ne 'Microsoft' -and $_.DriverVersion -notlike "2:5*"} | ForEach-Object { ## Set driver information in new class Set-WmiInstance -Namespace root\cimv2 -class $NewClassName -argument @{ DeviceClass = $_.DeviceClass; DeviceName = $_.DeviceName; DriverDate = $_.DriverDate; DriverProviderName = $_.DriverProviderName; DriverVersion = $_.DriverVersion; HardwareID = $_.HardwareID; DeviceID = $_.DeviceID; ScriptLastRan = $Date } | Out-Null } Write-Output "Complete" |
A few notes:
- A new WMI class Win32_PnpSignedDriver_Custom is created. Edit $NewClassName if you would like to change it.
- The custom class is deleted and recreated on each run
- The following Properties are inventoried: DeviceClass, DeviceName, DriverDate, DriverProviderName, DriverVersion, HardwareID, DeviceID
- The timestamp is inventoried
- Feel free to edit the filter for your own organizations needs
- $_.DeviceClass -ne ‘VOLUMESNAPSHOT’ -and $_.DeviceClass -ne ‘LEGACYDRIVER’ -and $_.DriverProviderName -ne ‘Microsoft’ -and $_.DriverVersion -notlike “2:5*”
Download the Configuration Item CAB here: Script – Windows – PNP Signed Drivers
Once the script has been deployed and ran on a few machines, just connect to WMI and you can add the new Win32_PnpSignedDriver_Custom class to your SCCM hardware inventory.
Reporting on driver versions
Once you have the data in your inventory, you just need to report on it.
The SQL view v_gs_pnp_signed_driver_custom gets created from your hardware inventory and contains all the raw data. Here are a few sample SQL queries:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
-- Raw data select * from v_gs_pnp_signed_driver_custom -- All network drivers list select DeviceClass0, DeviceName0, DriverDate0, DriverProviderName0, DriverVersion0 from v_gs_pnp_signed_driver_custom where DeviceClass0 = 'NET' -- All LAN network drivers count select DeviceName0 [Name], DriverVersion0 [Version], count(*) [Total] from v_gs_pnp_signed_driver_custom where DeviceClass0 = 'NET' and DriverProviderName0 in ( 'Broadcom', 'Intel', 'Marvell', 'Microsoft Corporation', 'Realtek', 'Realtek Semiconductor Corp.') and DeviceName0 not in ( 'ThinkPad OneLink Pro Dock Giga Ethernet', 'Thinkpad USB 3.0 Ethernet Adapter', 'Microsoft Windows Mobile Remote Adapter', 'Remote NDIS based Internet Sharing Device') and ( DeviceName0 not like '%Wireless%' and DeviceName0 not like '%WLAN%' and DeviceName0 not like '%Centrino%' and DeviceName0 not like '%WiFi%') group by DeviceName0, DriverProviderName0, DriverVersion0 order by DriverProviderName0, DeviceName0, DriverVersion0 -- All WLAN network drivers count select DeviceName0 [Name], DriverVersion0 [Version], count(*) [Total] from v_gs_pnp_signed_driver_custom where DeviceClass0 = 'NET' and DriverProviderName0 in ( 'Broadcom', 'Intel', 'Marvell', 'Microsoft Corporation', 'Realtek', 'Realtek Semiconductor Corp.') and DeviceName0 not in ( 'ThinkPad OneLink Pro Dock Giga Ethernet', 'Thinkpad USB 3.0 Ethernet Adapter', 'Microsoft Windows Mobile Remote Adapter', 'Remote NDIS based Internet Sharing Device') and ( DeviceName0 like '%Wireless%' or DeviceName0 like '%WLAN%' or DeviceName0 like '%Centrino%' or DeviceName0 like '%WiFi%') group by DeviceName0, DriverProviderName0, DriverVersion0 order by DriverProviderName0, DeviceName0, DriverVersion0 |
Here is a look at some of the raw data:
It was asked by a few members of the community what impact this may have on your database, and how large the table may be. My data is below, but you will need to judge for yourself if this would be an impact to your environment.
There are 77,767 unique resource IDs (total clients reporting) in this table in our environment.
| TableName | SchemaName | RowCounts | TotalSpaceKB | UsedSpaceKB | UnusedSpaceKB |
| PNP_SIGNED_DRIVER_CUSTOM_DATA | dbo | 0 | 32 | 32 | 0 |
| PNP_SIGNED_DRIVER_CUSTOM_DATA | dbo | 639759 | 514512 | 512840 | 1672 |
| PNP_SIGNED_DRIVER_CUSTOM_DATA | dbo | 983014 | 767456 | 764480 | 2976 |
| PNP_SIGNED_DRIVER_CUSTOM_DATA_DD | SCCM_Ext | 911122 | 40752 | 40656 | 96 |
We use the two LAN and WLAN queries above to create a network driver dashboard to report on how standardized we are. We highlight the current standard versions to quickly see any drift.
The .RDL is tailored for our environment, primarily Intel NICs with a few Broadcom and Realtek, so you may need to customize it for your models. The highlights also are “point in time” choices, and will also need to be modified for your needs.
Network – Workstation Dashboard
Enjoy!
I couldn’t resist commenting. Very well written!
This is terrific, Ive been working figuring out how to create driver baselines for weeks with no success. I’m having trouble getting the inventory class into SCCM 2012. Can you provide some more details? Thanks
Sure! Here is the TechNet docs: https://technet.microsoft.com/en-us/library/gg712290.aspx and here is a friendlier walkthrough: http://powershelldistrict.com/how-to-extend-hardware-inventory-in-configuration-manager/.
Let me know if the issue is that the WMI class isn’t there, that would be a different story.
[…] default SCCM doesn’t collect drive info. Potent Engineer have a great post about adding driver info to […]
Looks clean. What if any impact on HINV if managing 10k endpoints?
The only impact is the size of your DB. We inventory over 100 things with HINV, and it runs in about 60 seconds on all of our machines.
Great post Daniel – Many thanks. A couple of queries;
Do I need to run the script on all client systems? I have only ran it on one by managed to add the custom class to our inventory.
How long would you expect for it to take for the database to be populated with results? I presume it is dependant on the Hardware Inventory schedule within the default client settings………
The scope of clients you want the inventory information on would be who you would target, for both your inventory script as well as client settings to inventory the class. You could target as few or as many as you want. We target all physical workstations for our needs.
Your hardware inventory cycle schedule does play a part, so it should never take longer than that cycle, plus a little processing time policy to the MP, MP to drop the inventory file, and for the inbox to update and SQL to be injected. We run our HINV daily across all clients so we never expect data to be more than a day or so old.
Nice script, WMI class and reports 🙂 Thanks!
Does the script need to run on a schedule to collect updated information about drivers beeing updated?
Or is the WMI class dynamic ?
just looking at the “scriptLastRan” value…
//John
Thanks! Yes, the compliance item will need to be re-ran on a schedule to populate new information. We run ours weekly or monthly in some cases.
Your way of explaining the whoe thing in this post is actually nice, all be
capable of without dificulty know it, Thanks a lot.
Can you give more details on the CI creation? This part has me hung up. I am able to create the class if I run the script manually, but for some reason the CI is not creating the class for the clients. I am able to see that the CI is running, and I can run the CI from the client ad-hoc, but no dice on the WMI class creation. Thoughts?
Sorry for the delay! Are you running the script as a monitor, not remediate? Double check your x86/x64 settings as well. We only have x64 clients so we do not check the box to run as x86.
I just updated the post with my exact CI export. Give it a try!
I’m having the same trouble as Curtis. Could you send me a few screenshots of your CI settings?
I updated the post with my CI CAB. Give it a try!
It turns out it was an issue with the certificate we used to sign the script. So the CI and baseline are now working when ran manually* but I’m having some trouble with the evaluation schedule. I set a “simple schedule” to run the compliance evaluation every 30 minutes on my test collection but it doesn’t seem to be running at all.
*Open CM Configurations tab, manually run it by clicking “Evaluate”. The Last Evaluation column updates with the current date and time, the compliance column shows compliant. Open a PowerShell window and run “get-wmiobject win32_pnpsigneddriver_custom | select DeviceName, DriverVersion, ScriptLastRan” the driver version column is updated if a driver was changed and the ScriptLastRan column shows the same info as the Last Evaluation column in the CM Configurations tab.
Although the technical limit for it to re-evaluate is 15 minutes, 30 minutes might still be too often. There is also the 2 hour randomization that may impact it running so soon. From experience we usually never set anything to run more than every 2 hours. Most of our baselines deploy once a day.
Torsten has a great explanation here: https://social.technet.microsoft.com/Forums/en-US/9fa2fe83-90fc-4e73-ab2f-6d350ec29016/frequent-configuration-baseline-evaluation?forum=configmgrgeneral.
Official doc: https://technet.microsoft.com/en-us/library/bb680847.aspx
Hi Daniel, the link gives a 500 – Internal server error…
Sorry about that, it is fixed!
This is the greatest thing since sliced bread! I love it. Can you share the RDL files of the reports? I would love to use them.
Done! They will need to be customized for your needs, but the framework is there!
Thx a bunch. The green highlight in the dashboard, is it meant to highlight the newest driver? Or what does it do?
For us it represents our current stable driver version. We manually set it, but it could definitely be done dynamically just looking for the max version if you wanted.
Hi there, i’m not seeing the view in the SCCM DB any clue why it would still be missing after running for a week and over 1000 clients checking in?
Make sure you extend hardware inventory to start collecting it.
https://docs.microsoft.com/en-us/sccm/core/clients/manage/inventory/extend-hardware-inventory
Great post Thanks. I copy pasted the script and ran on few machines. The WMI class has been created and in the report also am able to see the driver info of Win 7 machines. However I could not collect info from Win10 physical machines. Is there anything needs to be done for Win 10 environment.
Nothing special, it works for both OS for us. Is the class created in the Win 10 machines? Is your CI set to run on both OS? Are the client settings different for Win10?
Below are the steps which I followed,
Copy the script to powershell ISE in a win7 machine and ran the script manually. I have not created any CI or compliance baseline.
After running the script, class got created and added the class to default client settings
Since I dont want to disturb the default settings, created a custom client settings with only this class and removed it from default client settings
Deployed the custom client settings to a collection which has all types of machines
Got the result from win7 machines. However the class did not get created on Win10 machine.
Am I missing something?
In the machine that didn’t report check inventoryagent.log and see if the class was inventoried when hardware inventory was ran.
In the inventoryagent log the error was Class “Win32 PNP.. custom” does not exist
Ah double check the class name and what you have in hinv. Sounds like it may not match exactly.
Class name is correct. Instead of typing the full name I gave the short form
Class Name in the log is “Win32_PNPSignedDriver_Custom” We did not change anything in the PS script.
If the class name in WMI and in inventoryagent.log match, not sure what else would prevent it from inventorying. It could be a Windows issue or a SCCM issue, not sure. May want to test on a few other Win10 machines to see if they all fail.
To create the class in all the machines for the first time, do we have to deploy the script in each machine once so that the class gets created in all the machines and sends data to the inventory cycle?
Yes, you have to create the custom WMI class some way or another. You also have to rerun it to gather new data when there are changes. The script will delete the class and recreate it with the updated data every time it is ran.
Thanks Daniel.
Its working fine.
Great news!
We are pulling the driver data, but for some reason there is no data being gathered for Universal Serial Bus hardware? Only USB under the System section in Device Manager. Nothing from under Universal Serial Bus section. Anyone have a similar problem?
Check WMI locally, is the data there?
Hi Daniel. Thanks for the reply. Yes it is in WMI. WMI query:
Select * From Win32_PnPSignedDriver Where DeviceName Like “Intel(R) USB 3.0 eXtensible Host Controller” and driverversion < "5.0.4.43"
Select * From Win32_PnPSignedDriver Where DeviceName Like "Intel(R) USB 3.0 eXtensible Host Controller" and DriverVersion < "5.0.3.42"
The next thing I would try is to run your Compliance Item script locally and see what output you get. Does it show the USB drivers?
Our engineer made an update in the script and it now captures the USB controller data. Thanks.
Ah great!