Third Party Updates - some updates frequently fail & cause restarts - false negatives

Hi,

Just throwing out some information that may assist some people and if logged more often to Dell, we might get a better result before these updates are sent out. Might just save time trawling through MECM, re-sycning catalogs, re-adding catalogs, re-adding certs, re-deploying to pilot groups etc etc.

Problem: Some Dell TPU's cause user machines to continually restart, MECM and TPU client logs and the driver details (wmi, devmgmt.msc) indicate a successful install, however, next update scan cycle the update will re-install and invoke a restart again.

You'll see on the client machine that UpdatesStore.log will have repeating entries like;
Update status from update (cccb12bd-7016-4b39-b075-f20c9f52d4dc) already exists, will modify existing instance.

Queried Update (cccb12bd-7016-4b39-b075-f20c9f52d4dc): Status=Missing, Title=Intel Serial IO Driver,30.100.1841.2,A02, BulletinID=, QNumbers=M31NN, LocaleID=, ProductID=5a0031d6-edef-f08b-6a12-ff17ac03525e, UpdateClassification = cd5ffd1e-e932-4e3a-bf74-18bf0b1bbd83, ExcludeForStateReporting=FALSE.

UpdatesHandler.log will repeat lines like;
Update (cccb12bd-7016-4b39-b075-f20c9f52d4dc) execution completed with state COMPLETE_SOFT_REBOOT_NEEDED.

Machine will re-boot, then next update evaluation cycle, it all kicks off again.

Download Microsofts System Center Updates Publisher
Under catalogs workspace, add the Dell TPU: https://downloads.dell.com/Catalog/DellSDPCatalogPC.cab
Let it sync

Search for one of your problem updates, right click and check that XML

I have found that on almost all failing updates, the XML applicability rules for IsInstalled and IsInstallable refrence a shortened version string, e.g.

Translate that to powershell to test out the queries

Get-WmiObject -Namespace 'root\dell\sysinv' -Query "SELECT * FROM Dell_SoftwareIdentity WHERE (Description >= 'Dell:DRVR_100950__' AND Description < 'Dell:DRVR_100950__~') AND VersionString < '1946.12.0.1328'"

Now replace that version string with the full format, as per the object property that's returned from WMI/CIM: 1946.0012.0000.1328

Test some more with the logic.

If you aren't too great with powershell, get a list of all objects sitting in that library

$delldrvrs = Get-WmiObject -Namespace 'root\dell\sysinv' -Class Dell_SoftwareIdentity
or, akin to the query from the xml;
$delldrvrs = Get-WmiObject -Namespace 'root\dell\sysinv' -Query "SELECT * FROM Dell_SoftwareIdentity"

You'll see in the xml query that it's looking for devices with description 'Dell:DRVR_ '

Check your test machines list of these descriptions with that powershell variable: $delldrvrs.description

Now trawl through the xml looking for the wmiquery that's applicable to your device, once you find a matching description, you can check it's full 'VersionString' and other properties;

$delldrivers | where {$_.Description -eq 'Dell:DRVR_100950__'}
or
$delldrivers | where {$_.Description -like 'Dell:DRVR_100950*'}

Now play around testing the xml query in Powershell; as I mentioned, almost every failing update i've found is NOT referencing the full 'VersionString' property properly, it's querying against the short form.

Now go find a working update that uses the same XML queries and see that it's referencing the full format 'VersionString'

Log a job to Dell