Microsoft SCCM & SCOM OpenManage Integrations

Last reply by 08-30-2021 Solved
Start a Discussion
2 Bronze
2 Bronze
4760

Dell Catalog issues Hash does not match

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.

Replies (21)
2507

Hello,

 

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. 

#Iwork4Dell
2505

I think I am still confused on where OpenManage plays a role in Dell 3rd party publishing catalogs for SCCM. 

1418

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.

Dell4.PNG

1405

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.

Thanks!

2 Bronze
2 Bronze
1374

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...

2 Bronze
2 Bronze
1350

We have this same problem as well. Has anyone been able to fix it? We've tried everything. Some drivers download successfully, most fail with the hash error.

1337

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.

2 Bronze
2 Bronze
1287

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.

2 Bronze
2 Bronze
1286

We are seeing this HASH issue in our environment for previously published patches.  Can confirm this on the OptiPlex_7070_1.8.4.exe BIOS update.

2 Bronze
2 Bronze
1230

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.

Latest Solutions
Top Contributor