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.
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'
Same here. Reporting this problem to Dell via twitter @DellCaresPro to no avail. OpenManage Inventory Agent is publishing modified Version Strings that do not match detection rules of Dell Command Update Catalog.
Also I posted started two discussions in this section - always were moved to Precission Workstation section. I have no idea why.
Thanks @Mickjo for bringing this topic up. We are having a familiar situation, were some updates showing as failed in Software Center, when the opposite is true.
Just an update, Dell Advanced Tech Support contacted me early in the month and asked that I try the latest iteration of the catalogue updates as they did not wish to escalate the job further without us having tried this. I could not at the time as we’d changed MECM servers and some SUP issues came with that. I’ve since re-synced to the catalogue and we do have revised versions of the same updates, however, the xml queries are still the same and we have the same problem. E.g. Intel Serial IO Driver,30.100.1841.2,A02, old unique ID “cccb12bd-7016-4b39-b075-f20c9f52d4dc”. The revised version, currently sitting in MECM, unique ID “e95dbc73-105f-43af-b88c-4739486beda7”; I did that sync several days ago and it appears there is yet another revision as when I’ve imported the catalogue into SCUP, we now have “f19a34e9-48ec-4da7-a0bc-b5b51d36aa35” (does supersede the previous versions), however, the xml applicability rules have not been updated, they’re still querying the short version number and still causing the evaluation to fail as originally described. There are several other updates like this for just one model. The Dell TPU’s didn’t get past our first pilot group. They're re-opening my case and I'll update as I can.
Thanks for letting us know. Do you any by chance have the tech support case#? If you do, could you either PM me or @Dell-Stephane T so we could attach our social case together with the case that you were on with the oncall tech support.
DELL-Joey C
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell
Did I answer your query? Please click on ‘Mark as Accepted Answer’ if I did.
I found your service tag from a previous post you did, and found the case#. I shall inform the case owner about this post, and you can continue contacting the tech support for assistance.
DELL-Joey C
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell
Did I answer your query? Please click on ‘Mark as Accepted Answer’ if I did.
Because that case has reached the client engineering team, I will also move this post to the Precision board based on the product. You may continue to post your updates on the same thread.
DELL-Joey C
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell
Did I answer your query? Please click on ‘Mark as Accepted Answer’ if I did.
Dell-Stephane T
11 Legend
•
3699 Posts
1832
0
Posted August 24th, 2020 01:00
Hello Mickjo,
Thank you for this excellent sharing. I will check with the content team to see if this sharing can be the subject of a knowledge base article.
Best regards,