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 from there and will find out what are the limitation Third-party software update has and known issues.
If you have ever installed SCUP 2011 in your environment and integrated with SCCM then the new feature “SCCM Third-Party Software updates” is not useful for you, you would have question why?
Microsoft says if you have installed/configured SCUP and published updates in your environment then still you have to use SCUP, you cant use Third-party Software Update and can’t publish them from SCCM.
Once you have added the catalog in SCCM using the method explained here and initiate 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 checking the log file SMS_ISVUPDATES_SYNCAGENT.log you will be able to 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 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 that were 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 of SUP/WSUS from your environment and reinstall again them to clean up the metadata and updates which were published.
- Find out the update ID and cleanup them from database (only supported by Microsoft premeier 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 catalog for Adobe product (Adobe DC catalog). I was able to import the updates in update publisher, but I was not able to 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 error failed to create directory while publishing the updates from SCUP. I didn’t have any clue why there is error says was unable to create directory.
After some analysis, I tried to find where UpdateServicesPackages directory is located or its created or not, then I found UpdateServicesPackages folder was created under. E:\WSUS\WSUSContent
The easiest way to find the directory is use 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 share.
- 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 WSUSContent folder of 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 then next action is to create UpdateServicesPackages share in correct 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 then netshare will be like following and your UpdateservicesPackages is in correct path.
NOTE! – So always remember if you install SCUP/update publisher then UpdateServicesPackages should be in WSUS directory.
Failed to sign package Error 2147954429
This 2147954429 is most common error if you use proxy in your environment. The actual WSUS API uses timestamping operation to http://timestamp.digicert.com which uses default proxy configured at the SYSTEM level.
NOTE! – WSUS won’t use the proxy configured in WSUS and thats why while publishing updates it return the above error.
To resolve that SCUP publishing related proxy error, we need to configure the proxy at system level, run the following commands.
- Download PSEXEC.exe
- Open command prompt as Administrator
- launch Internet Explorer as system using 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 you 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 length) is used by default with SCUP 2011.
This certificate is not valid and not accepted; then you need to recreate the certificate once again. Open SCUP with the administrator and go to Option and create the certificate from there.
Once you have recreated the certificate, then you are all set, and you can now publish the updates in your environment.
Now you can see, update is published successfully, I have downloaded the update and deployed it in my environment. follow instruction given here for deployment of updates SCCM Third-Party Software Updates Setup Step by Step Guide.