SCCM Third-Party Software Updates SCUP Troubleshooting Part-2

Microsoft has added the outstanding feature “Third Party Software Updates” in SCCM, but still, you have some dependency on SCUP, or you say it as Update Publisher. This post will provide complete information about SCCM third-party software updates feature and its limitations for existing SCUP customers.

[Related Post 1. SCCM Third-Party Software Updates Setup Step by Step Guide Post 1, 2. List of Free SCCM Catalogs for Third-Party Software Updates, and 3. SCCM Third-Party Updates Step by Step Troubleshooting Process Guide ]

Subscribe to this Blog via Email

[jetpack_subscription_form show_only_email_and_button=”true” custom_background_button_color=”#fcb900″ custom_text_button_color=”undefined” submit_button_text=”Subscribe” submit_button_classes=”wp-block-button__link has-text-color has-background has-luminous-vivid-amber-background-button-color” show_subscribers_total=”true” ]

Introduction

Anoop has written an excellent blog on how to configure Third-Party Software Updates in your environment. I will continue and find out the limitations of Third-party software updates and known issues.

Patch My PC

If you have ever installed SCUP 2011 in your environment and integrated it with SCCM, then the new feature “SCCM Third-Party Software updates” is not useful for you. You would have to question why?

Microsoft says if you have installed/configured SCUP and published updates in your environment, you still have to use SCUP. You cant use Third-party Software Updates and can’t post them from SCCM.

Problem Statement

Once you have added the catalog in SCCM using the method explained here and initiated a sync, once you have synchronized with WSUS successfully, you will see those updates in your SCCM console.

And when you try to publish them and check the log file SMS_ISVUPDATES_SYNCAGENT.log you will see the following error.

Adaptiva
STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_FAIL). SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:51:36 AM 17084 (0x42BC) Launcher : Work item SyncUpdate has completed queued time was 00:00:00.0650023 run time was 00:00:00.0690054 SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:51:36 AM 17084 (0x42BC) SyncUpdate: 43b53f17-0fac-4976-a005-c6ce840e8e91 - Completed. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:51:36 AM 17084 (0x42BC) PollingWorkMonitor: There are 2 jobs that are pending in the jobs table. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 13448 (0x3488) PollingWorkMonitor: Starting job 11 for subject 49018fe2-3bd5-4f40-be88-ee2f997da55a. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 13448 (0x3488) Creating a new SyncUpdate work item for update 49018fe2-3bd5-4f40-be88-ee2f997da55a, jobid is 11 SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 13448 (0x3488) Launcher : About to start work item: SyncUpdate. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 13448 (0x3488) PollingWorkMonitor: Removing duplicate pending job 12 for subject 49018fe2-3bd5-4f40-be88-ee2f997da55a. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 13448 (0x3488) SyncUpdate: 49018fe2-3bd5-4f40-be88-ee2f997da55a - No synchronization record for update with id 49018fe2-3bd5-4f40-be88-ee2f997da55a was found, only updates synchronized by Configuration Manager can have update content published to WSUS by Configuration Manager. SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 12736 (0x31C0) STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_NO_METADATA). SMS_ISVUPDATES_SYNCAGENT 6/3/2019 4:56:36 AM 12736 (0x31C0) STATMSG: (SRVMSG_SMS_ISVUPDATES_SYNCAGENT_UPDATECONTENT_FAIL). 
SCCM Third-Party Software Updates
SMS_ISVUPDATES_SYNCAGENT.log – SCCM Third-Party Software updates 1
SCCM Third-Party Software Updates
SMS_ISVUPDAES_SYSN – SCCM Third-Party Software Updates 2

Known Issues with SCCM Third-Party Software Updates

In the above log files and component status message, you have seen the error. While publishing, we got an error. You can check the message ID 11524 in SCCM third-party patching known issues in Microsoft documentation (it’s a bug).

According to Microsoft, The third-party software update synchronization service can’t publish content to metadata-only updates added to WSUS by another application, tool, or script, such as SCUP.

The Publish third-party software update content action fails for the third-party updates. If you need to deploy third-party updates, use your existing process in full for deploying those updates.

Solution

You have only two (2) options to resolve that issue.

  • Uninstall SUP/WSUS from your environment and reinstall them again to clean up the metadata and updates which were published.
  • Please find the updated ID and cleanup them from the database (only supported by Microsoft premier support).

In my scenario, I installed SCUP 2011 4 years back in my lab, and after that, I never used SCUP 2011 for any SCCM third-Party software updates.

I didn’t have any other options than to reuse SCUP in my Lab environment and wait for Microsoft to start supporting publishing updates even though SCUP or any other tools already publish them.

Troubleshooting SCUP SCCM Third-party Software Updates

All the following troubleshooting scenarios are related to SCUP Integrated SCCM third-party patching.

Failed to sign package Error 2147942403

I added a catalog for Adobe products (Adobe DC catalog). I was able to import the updates into the updated publisher, but I could not publish the updates. While publishing, I got an error.

--- Calling update server API for publishing update 'Adobe Acrobat DC Update 19.010.20064 (UpdateId:'34775f80-aded-417d-b908-bcf36e9b913e' Vendor:'Adobe' Product:'Adobe Acrobat')', timestamp enabled, server is http://timestamp.digicert.com. NormalPublishItem 7/3/2019 5:28:23 AM 9464 (0x24F8) 2019-07-03 03:28:23.273 UTC Info UpdatesPublisher.28 ThreadEntry ThreadPoolWorkQueue.Dispatch DEBUG_TRACE_REDIRECT 7/3/2019 5:28:23 AM 9464 (0x24F8) 2019-07-03 03:28:23.273 UTC Info UpdatesPublisher.28 ThreadEntry ThreadPoolWorkQueue.Dispatch TRACE_REDIRECT 7/3/2019 5:28:23 AM 9464 (0x24F8) 2019-07-03 03:28:23.275 UTC Error UpdatesPublisher.28 Publisher.PublishPackage PublishPackage(): Operation Failed with Error: CreateDirectory failed    at Microsoft.UpdateServices.Internal.BaseApi.Publisher.PublishPackage(String sourcePath, String additionalSourcePath, String packageDirectoryName, Boolean dualSign, String httpTimeStamp)    at Microsoft.UpdatesPublisher.BaseServices.WSUS.Publish.PublishItem.PublishPackage(PublishReportItem reportItem, IPublisher publisher, String contentFolder)    at Microsoft.UpdatesPublisher.BaseServices.WSUS.Publish.NormalPublishItem.Publish(PublishReportItem reportItem, CancellationToken token)    at Microsoft.UpdatesPublisher.BaseServices.WSUS.Publish.PublishItem.PublishUpdateAndDependencies(PublishReport report, CancellationToken token)    at Microsoft.UpdatesPublisher.BaseServices.WSUS.Publish.PublishOperation.Start(CancellationToken token)    at Microsoft.UpdatesPublisher.UI.PublishWizard.PublishProgressPageViewModel.DoWork(CancellationToken token)    at System.Threading.Tasks.Task`1.InnerInvoke()    at System.Threading.Tasks.Task.Execute()    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)    at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)    at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)    at System.Threading.ThreadPoolWorkQueue.Dispatch() DEBUG_TRACE_REDIRECT 7/3/2019 5:28:23 AM 9464 (0x24F8) 2019-07-03 03:28:23.275 UTC Error UpdatesPublisher.28 Publisher.PublishPackage PublishPackage(): Operation Failed with Error: CreateDirectory failed    at Microsoft.UpdateServices.Internal.BaseApi.Publisher.PublishPackage(String sourcePath, String additionalSourcePath, String packageDirectoryName, Boolean dualSign, String httpTimeStamp)   Microsoft.UpdatesPublisher.BaseServices.WSUS.Publish.PublishItem.PublishPackage(PublishReportItem reportItem, IPublisher publisher, String contentFolder) NormalPublishItem 7/3/2019 5:28:23 AM 9464 (0x24F8) 
SCCM Third-Party Software Updates
updatepublisher.log – SCCM Third-Party Software Updates 3

In the above log file, you can see an error that failed to create a directory while publishing the updates from SCUP. I didn’t have any clue why there was an error says was unable to make a directory.

After some analysis, I tried to find where the UpdateServicesPackages directory was located or not. Then, I found the UpdateServicesPackages folder was created. E:\WSUS\WSUSContent

The easiest way to find the directory is to use the following command and see where the directory is located.

  • Run CMD as an administrator on the WSUS server 
  • C:\>net share
  • There you will see WSUSContent and UpdateServicesPackages pointing to different network shares.
  • UpdateServicesPackages = E:\wsus\WsusContent\UpdateServicesPackages
  • WsusContent = E:\wsus\WsusContent

With the above commands, you can see the folders are not in the correct place. The folder UpdateServicesPackages should not be under the WSUSContent folder of the WSUS folder (as per my understanding), then I decided to delete the UpdateServicesPackages folder.

To delete that, run the following command

  • net share UpdateservicesPackages /delete
  • C:\>net share UpdateservicesPackages /delete UpdateservicesPackages was deleted successfully.

Once the share is deleted, the next action is to create UpdateServicesPackages incorrect share location. You can run the following command to create:

  • net share UpdateservicesPackages =<Path to UpdateservicesPackages> /everyone,full
  • C:\>net Share UpdateservicesPackages=E:\WSUS /grant:everyone,full UpdateservicesPackages was shared successfully.
  • Once that is completed, the net share will be like the following, and your UpdateservicesPackages is incorrect.
SCCM Third-Party Software Updates
SCCM Third-Party Software Updates 4

NOTE! – So always remember, if you install SCUP/update publisher, then UpdateServicesPackages should be in the WSUS directory.

Failed to sign package Error 2147954429

This 2147954429 is the most common error if you use a proxy in your environment. The actual WSUS API uses timestamping operation to http://timestamp.digicert.com, which uses a default proxy configured at the SYSTEM level.

NOTE! WSUS won’t use the proxy configured in WSUS, and that’s why it returns the above error while publishing updates.

To resolve that SCUP publishing-related proxy error, we need to configure the proxy at a system level and run the following commands.

  • Download PSEXEC.exe
  • Open command prompt as Administrator
  • launch Internet Explorer as a system using a command line,
    • psexec.exe -a-i “C:\program files\internet explorer\ieexplorer.exe
  • In Internet Explorer–> Settings–>Connectionss–>Lan Settings–>Enable proxy which you are using in your environment

Verification of File Signature Failed for File

SCCM Third-Party Software Updates
SCCM Third-Party Software Updates 5

If you have installed SCUP 4.5 or earlier and created a certificate with SCUP 4.5, and your SCUP is upgraded to 2011 later, the certificate created with SCUP 4.5 (which would be 512 bits in length) is used by default SCUP 2011.

If this certificate is not valid and not accepted, you need to recreate the certificate once again. Open SCUP with the administrator, go to Option, and create the certificate.

SCCM Third-Party Software Updates SCUP Certificate
SCCM Third-Party Software Updates 6

Once you have recreated the certificate, you are all set, and you can now publish the updates in your environment.

SCCM Third-Party Software Updates
SCCM Third-Party Software Updates 7

Results

SCCM Third-Party Software Updates
SCCM Third-Party Software Updates 8

Resources

Now you can see that the update has been published successfully. I have downloaded the update and deployed it in my environment. Follow instructions for deployment updates SCCM Third-Party Software Updates Setup Step by Step Guide.

2 thoughts on “SCCM Third-Party Software Updates SCUP Troubleshooting Part-2”

  1. I’m struggling a bit with the “content” part of the 3rd party updates – because from what I can tell the content is stored not once, not twice but *3* times when you enable a 3rd party update (and that’s before you actually deploy them!). For example, I enabled the 3rd party update “Dell OpenManage Inventory Agent” – I see a folder within the “UpdateServicesPackages” folder with a CAB file for the update, and within that folder another folder with the MSI for the update, then a folder under WSusContent with another copy of the CAB file. That’s 3 copies of content before I even downloaded the content to a deployment package in SCCM. Is this correct? I’ve only published ONE 3rd party update in my environment – is this going to happen for every 3rd party update?

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.