Dell Catalog issues Hash does not match

Hi Diego,

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

Hello @Mike762,

Please, can you let us know what version of OMIMSSC are you using? Also what version of SCOM do you have?

Do you have some screenshoots of the error? Is something you can provide? I want to talk with some internal escalation teams to see if they can provide some feedback and I would like to have as much information as possible.

Regards.

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.

Sorry, forgot to attach those screenshots on the last message.

I could send you screen shots, but its line for line what I pasted in the post.

Not sure where I would find OMIMSSC version, but my dell integration suite for system center is 5.2.0.29.

SCCM is version 2010.

Hi Chris,

Yes you are correct it's the client update and Client Openmanage forum does look like a better fit for this, however checking the previous post the doesn't seem to be any responses from Dell staff.

I agree with Mike762 and believe this is a problem with the catalog and need's looking at from Dell's side.

Give the above (and that I've got a support call going around in circles) can you advise how we can get this looked at by the team responsible for this product please?

So based on the details everyone has provided I am almost certainly you're not using OM Integrations at all. The product you're referencing is Dell Command Integration, which is a client product and not supported with enterprise servers. The error you both see is from Dell Command Update, which is also a client product for client systems. Now while System Center may be part of it, the issue looks to be with the client catalog itself. 

So if this is on a Poweredge Server, then it is an incorrect tool issue. 

If it is on a client system (laptop/desktop) then you are far more likely to get accurate assistance in the Client Openmanage forum.  

Let us know.

When I saw something similar in the Enterprise world, it was resolved on the following release. So I would start with making sure you're on the most recent versions, as it may have already been released. 

I can look into it, but being Enterprise we are not really familiar with all the client groups.

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

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

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.

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. 

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

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