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.
Same, I noticed they expired a whole bunch of update packages and reintroduced the exact same packages with new hashes when checking sync.
I really, REALLY wish Dell had a solution that we could easily contact them regarding this.
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.
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 18.104.22.168.
SCCM is version 2010.
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.
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?
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 <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.
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.