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
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.
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.
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.
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).
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.
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)
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.
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
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.
Once you have recreated the certificate, you are all set, and you can now publish the updates in your environment.
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.