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.
I spoke to a colleague who does OpenManage Enterprise support exclusively. He was kind enough to look over this thread for us. The issue is going to have to be addressed by the Client support group. The Client OpenManage team will have to address this, as we have no avenues to reach the group that owns the resources in question.
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.
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...
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.
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.