Update "a6be5a94-00b8-4d1d-aefa-9faaab9d6766" content was not published due to a hash mismatch, content revisions are not supported. See SMS_ISVUPDATES_SYNCAGENT.log for further details.
Update "ee1819b4-c296-4911-9a02-a1442def0050" content was not published due to a hash mismatch, content revisions are not supported. See SMS_ISVUPDATES_SYNCAGENT.log for further details.
Have this issue with almost all of the intel rapid storage downloads. Catalog also seems like its not grabbing everything and I couldn't help but notice it seems its because its split between downloads.dell.com (prebuilt into dell sccm integration) and dl.dell.com (not integrated). Do I need to go do a custom catalog subscription for dl.dell.com??
I have done everything under the sun, resync, unsubscribe and resubscribe, kill av, check firewall and let everything through without inspection.
Any way we can get someone on Dell end to check the update catalogs? At least for the two provided? Its a ton of the bios packages too, not all but plenty.
Solved! Go to Solution.
So basically SCCM goes and gets the catalog from the URL and I don't think OpenManage plays a role here. Although both are involved with deploying updates and might work similarly or at least perform similar tasks.
So, I think I may have failed to explain this clearly. This is Dell catalog subscription within SCCM - the problem I am having deals specifically with publishing the 3rd party within SCCM as, I believe the issue deals with the catalog metadata stating the expected hash should be X - at one point for that package the hash was X, but if a package is revised and the hash changes to Y it causes an issue.
Now NORMALLY your issue would be something like:
-You need to resync your catalog as it didn't update this. (not the case watched it sync in logs)
-You need to ensure your network or local AV are not <Profanity removed. TOS67> the download resulting in a hash that is incorrect. (Not the case as I went to the download.dell directory for that exact package, looked at hash on the page for dell and then checked after download, no change)
From a lot of reading I hear that most 3rd parties will mess up with adding a revision and not updating the hash when it isn't one of those things. I don't know exactly the hash expected for this because in the database I don't see hashes for metadata, I see hashes for downloaded data. Problem is, is if I can't publish from just the metadata alone - I can't download it. So if there were an actual issue on the catalog side, there would be literally nothing I could do about it that I can tell. SCCM no longer allows 'do not validate hash' for security reasons, which makes this extremely painful.
If we simply had a way to contact dell with maybe a simple ticket that says "Hey I can publish all of these Dell updates except package xxxxx-xxxxx-xxxxx-xxxx. Tried everything under the sun, could you ensure the actual package hash and catalog hash are matching?" That would be SO extremely helpful, when it comes to large deployments trying to patch serious vulnerabilities - SCCM in full Dell environments, which is most. Publishing Catalogs and products for enterprise should honestly have a system in which we can talk to catalog support techs directly. I think Dell should be receptive (if they don't already have it) to a ticket system that deals specifically with catalog hash checking.
When dealing with other 3rd party catalogs, I have noticed it's near impossible to get hooked up with someone who can help. I have seen it happen though, and it's amazing when it does - when it doesn't? These problems just hang out there forever until someone finally publishes a new package which supersedes the old one and it is SO PAINFUL! The people that joined this thread, I really bet they all feel the same way.
I literally could be wrong, but I'm like 99.99% sure of this. I'm sure you have dealt with many problems from dunces that can't troubleshoot their way out of a paper bag. I've been doing this for a very long time at a professional level and I wouldn't press this if I didn't spend an insane amount of time ensuring it wasn't my side.
Any luck with contacting whoever controls the hashes for the catalogs? https://downloads.dell.com/catalog/
I'm seeing more people with the same issues and I'm testing their same packages only to get those same errors.
I'm seeing the same error and I have a support call logged but they are struggling to direct it to the correct team to look at.
The error is with the Dell Command Update Catalog here and this is the error I'm seeing in the SMS_ISVUPDATES_SYNCAGENT.log is:-
SyncUpdate: 'Intel 9560/9260/8265/7265/3165 Wi-Fi Driver,188.8.131.52,A27' (Update:'57c5c247-f3f5-4128-b323-1c96e054957c') Vendor 'Dell' Product:'Drivers and Applications' is synchronized to WSUS without content.
SyncUpdate: 57c5c247-f3f5-4128-b323-1c96e054957c - Hash for downloaded content file does not match update 57c5c247-f3f5-4128-b323-1c96e054957c expected hash1. SMS_ISVUPDATES_SYNCAGENT 20/08/2021 15:30:15 4712 (0x1268)
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_HASH_FAIL). SMS_ISVUPDATES_SYNCAGENT 20/08/2021 15:30:15 4712 (0x1268)
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_FAIL). SMS_ISVUPDATES_SYNCAGENT 20/08/2021 15:30:15 4712 (0x1268)
As per Mike's post I'm seeing this on the majority of drivers but some are still working. I've also tried re-syncing the catalog and synchoronizing the updates but still getting the hash error. I'm using Config Manager 2103.
Yup, in SMS_ISVUPDATES Logs I get the exact same thing. word for word.
SyncUpdate: a6be5a94-00b8-4d1d-aefa-9faaab9d6766 - Hash for downloaded content file does not match update a6be5a94-00b8-4d1d-aefa-9faaab9d6766 expected hash1.
I could be wrong, but even someone else I know with a different system has the exact same issues with the EXACT same packages, making me believe the hash values are not correct in the catalog on Dell's side.
We started seeing the same errors "Hash for downloaded content file does not match update" in our SCCM, for multiple packages, for example for the OptiPlex_7070_1.8.4.exe BIOS update:
SyncUpdate: 680d1ec7-7df6-4ed9-967f-11f5820ccb77 - Successfully completed download of content from 'https://downloads.dell.com/FOLDER07439441M/1/OptiPlex_7070_1.8.4.exe' to 'C:\Program Files\Microsoft Configuration Manager\ISVTemp\myrp010n.spp\OptiPlex_7070_1.8.4.exe. SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:31 PM 27316 (0x6AB4)
SyncUpdate: File 'C:\Program Files\Microsoft Configuration Manager\ISVTemp\myrp010n.spp\OptiPlex_7070_1.8.4.exe' appears to be signed, retrieved certificate, checking signature... SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:32 PM 34888 (0x8848)
SyncUpdate: 680d1ec7-7df6-4ed9-967f-11f5820ccb77 - Signature check on download binary has completed. SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:32 PM 34888 (0x8848)
SyncUpdate: 680d1ec7-7df6-4ed9-967f-11f5820ccb77 - Hash for downloaded content file does not match update 680d1ec7-7df6-4ed9-967f-11f5820ccb77 expected hash1. SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:33 PM 10676 (0x29B4)
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_HASH_FAIL). SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:33 PM 10676 (0x29B4)
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_FAIL). SMS_ISVUPDATES_SYNCAGENT 8/21/2021 10:56:33 PM 10676 (0x29B4)
it used to work well a week ago...
Also, it seems like Dell republishes the each BIOS update each month calling it "superseded" even if it is the same update. this causes us rework of existing deployments.
DELL REALLY NEEDS TO FIX THIS.
We did resync yesterday evening the DELL Third Party Drivers Update and we started noticing that problematic BIOS packages in the past, like the one mentioned previously by crammy (OptiPlex 7070 System BIOS 1.8.4) are marked as expired, when we try to publish them:
SyncUpdate: 'Dell OptiPlex 7070 System BIOS,1.8.4,1.8.4' (Update:'680d1ec7-7df6-4ed9-967f-11f5820ccb77') Vendor 'Dell' Product:'Bios' is synchronized to WSUS but is expired no publish actions are possible. SMS_ISVUPDATES_SYNCAGENT 8/28/2021 7:30:37 AM 15408 (0x3C30)
SyncUpdate: 680d1ec7-7df6-4ed9-967f-11f5820ccb77 - No action required for 'Dell OptiPlex 7070 System BIOS,1.8.4,1.8.4' (Update:'680d1ec7-7df6-4ed9-967f-11f5820ccb77') Vendor 'Dell' Product:'Bios'. SMS_ISVUPDATES_SYNCAGENT 8/28/2021 7:30:37 AM 15408 (0x3C30)
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_SUCCESS). SMS_ISVUPDATES_SYNCAGENT 8/28/2021 7:30:37 AM 15408 (0x3C30)
Or for OptiPlex 7060 System BIOS,1.13.0...
SyncUpdate: 'Dell OptiPlex 7060 System BIOS,1.13.0,1.13.0' (Update:'3bbc4e8b-231f-4c76-86ea-1372ace2a4f4') Vendor 'Dell' Product:'Bios' is synchronized to WSUS but is expired no publish actions are possible. SMS_ISVUPDATES_SYNCAGENT 8/28/2021 7:29:37 AM 1172 (0x0494)
SyncUpdate: 3bbc4e8b-231f-4c76-86ea-1372ace2a4f4 - No action required for 'Dell OptiPlex 7060 System BIOS,1.13.0,1.13.0' (Update:'3bbc4e8b-231f-4c76-86ea-1372ace2a4f4') Vendor 'Dell' Product:'Bios'. SMS_ISVUPDATES_SYNCAGENT 8/28/2021 7:29:37 AM 1172 (0x0494)
Maybe next week the repository will be healthy again, fingers crossed.