Hey guys,
I've noticed the last updates coming through the Adobe Third-party update catalog in SCCM, specifically APSB24-57 en APSB-29 not being able to get deployed through our ADR's. I've noticed in the ADR's property filter's these updates do not show, where i would expect them to show up (as there are more than a few thousand pc's that need them):
Next to that, upon doing a 'Publish Third-Party Software Update Content" on (for example) APSB24-57 (Adobe Acrobat Reader - MUI Update 24.002.21005) i've noticed this in SCCM's SMS_ISVUPDATES_SYNCAGENT.LOG:
However! Doing exactly the same for the various versions in APSB24-07 works perfectly (among others):
Now... according to the 'known issues' in Enable third-party updates - Configuration Manager | Microsoft Learn there's a short mention of:
- The third-party software update synchronization service can't publish content to metadata-only updates that were added to WSUS by another application, tool, or script, such as SCUP. The Publish third-party software update content action fails on these updates. If you need to deploy third-party updates that this feature doesn't yet support, use your existing process in full for deploying those updates.
I'd like to state that i've never used any other tool for third-party update publishing. That would also not explain why all updates coming after APSB24-07 (-29 and -57) fail on the metadata. May i kindly suggest there is possibly some malformed XML within the SCUP-catalog for Adobe Reader's continous track which causes this.
I've also seen similar reports on Reddit: https://www.reddit.com/r/SCCM/comments/1c747ft/sccm_third_party_catalog_adobe_reader/ and https://www.reddit.com/r/SCCM/comments/1bhjum5/syncupdatecatalog_warning_catalog_is_old_format/
BTW: certificates and all other stuff seems perfectly fine. Again, only APSB24-29 and APSB24-57 seems to be impacted currently.
1
Reply
AdChoices