Cannot Publish Third Party Updates in SCCM

[colinc22239829]

Using SCCM 2010 and enabled Third Party Updates.  Added custom catalog: https://armmf.adobe.com/arm-manifests/win/SCUP/ReaderCatalog-DC.cab    

When I sync the customer catalog I get this error in the SMS_ISVUPDATES_SYNCAGENT.LOG file:

SyncUpdateCatalog: **** Warning: Catalog is old format, no content certificates are included and updates will not be deployable until certificates are trusted. ****

I have seen several posts concerning the catalogs but can't find a definitive asnwer on which catalog to use.  Is there a new catalog I can use for my updates?

[colinc22239829]

I was able to overcome the catalog error by adding the Adobe cert to Trusted Publishers.  Now when I try to publish one of the updates I get this error in the SMS_ISVUPDATES_SYNCAGENT log:

SyncUpdate: Exception HRESULT: -2147467259

I've searched on this error and cannot find any useful information.  Has anyone experienced this?

[SuJoshi]

Kindly confirm if you are facing issues in updating Acrobat Reader only or other creative cloud applications.

[colinc22239829]

Sorry for the delay in my response.  We are only using third party updates for Reader.

[Kok31469230gz9s]

Hi, I am facing the same error when syncing Adobe catalogs after publishing the updates.

SyncUpdateCatalog: **** Warning: Catalog is old format, no content certificates are included and updates will not be deployable until certificates are trusted. ****

 I am not sure whether the root cause is due to the wsus content folder or not, because I actually synced the catalog to get the updates to appear in my SCCM software updates list. Next I tried to published those updates that are meta-data only and according to the Microsoft tutorial I should re-sync the catalog again at this point to refresh the published software update and verify their icon to turn from blue to green, and the re-sync is where I encounter the error in the SMS_ISVUPDATES_SYNCAGENT.log, unlike your case where you encountered it after newly added the catalog and trying to perform an initial sync. On the other hand, I verified that my WSUS content folder structure is "D:\Updates\WsusContent" and there is no another WsusContent folder under it. The UpdateServicesPackages folder is at the same level as "D:\Updates\WsusContent", which means "D:\Updates\UpdateServicesPackages", and the binary cabs were downloaded to the UpdateServicesPackages folder first and later on stored into D:\Updates\WsusContent as well as per verification at file system and logs. So I would like to clarify on how did you check the cert part? I don't know where to check the cert settings for Adobe catalog at SCCM console and how to perform your action of adding the Adobe cert to trusted publisher store if I am going to give that a try. Appreciate your reply.

[colinc22239829 · Accepted solution]

Problem was with Reader updates only but has been resolved by adding a new subfolder to the WSUSCONTENT folder

[USAFAnderson]

@colinc22239829 - what do you mean it's resolved by adding a new subfolder to WSUSCONTENT? how does adding a new subfolder resolve a no content certificate being included? i mean i'm willing to try whatever, but some further input on your method, ie. did you give this subfolder a certain name, or did you have to direct downloads to this folder; would be greatly appreciated. 

[colinc22239829]

It turns out that I was slightly mislead by Microsoft and I was remiss in not documenting this a little better.  I had set the WSUSCONTENT folder to drive:\Updates\WSUSCONTENT.  SCCM creates a WSUSCONTENT folder in the default content folder so the result was a folder named drive:\Updates\WSUSCONTENT\WSUSCONTENT.  Third party updates require a folder in the content folder by the name of "UpdateServicesPackages" where the CAB file is stored during the Publish procedure (the actual update is downloaded to the WSUSCONTENT folder.)  The additional WSUSCONTENT folder was causing SCCM to become confued.  I completely renamed the content location to drive:\WSUS using the WSUSUTIL,EXE MOVECONTENT command from an elevation command prompt on my SCCM server.  The result is a WSUS folder with two subfolders: WSUSCONTENT and UPDATESERVICESPACKAGES.  As soon as I made this change I was able to publish, download and deploy Reader updates with no problems.  I have only had to publish 2 udpates but the process is now working flawlessly.  Once I had my content folders straightened out I went to Software Updates and selected Publish on the needed update.  Vefified the update publised in the SMS_ISVUPDATES_SYNCAGENT log.  Then I ran a manual update sync from the SCCM console.  At that point the icon for the update changes from blue to green.  You can then download and deploy the update like normal.