All future feature request should be created on the following website: Ideas Website. This change is to use a platform that supports up-voting and better tracking of feature request.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.Show posts Menu
HttpSendRequest failed HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED
ERROR: DownloadContentFiles() failed with hr=0x80070193
--- Digest verification failed on content for software update 'Google Chrome 72.0.3626.119 (x64) (UpdateId:'626b77a4-61e5-4e84-9870-3aa68abafd0e' Vendor:'Patch My PC' Product:'SCUP Updates')'.If you are using the SCCM 1806+ third-party updates feature directly in the SCCM console, you will see the following errors in the SMS_ISVUPDATES_SYNCAGENT.log which is located on the top-level software update point in the site system logs folder.
You will need to perform a sync of catalog manually. In the Third-Party Software Update Catalog node in your SCCM console, right-click the Patch My PC Catalog and choose Sync now. By default, SCCM will only automatically sync a third-party software update catalog every 7 days.
You can review the catalog sync progress in the SMS_ISVUPDATES_SYNCAGENT.log. located on the top-level software update point in the site system logs folder.
Once the catalog publishing sync is complete, you can perform a sync of your software update point to have any newly released third-party updates show up in the "All Software Updates" node of the SCCM console.
Once the sync is complete, you should see new updates for the product, and the previous updates that were failing should become superseded. The latest version of the update should be able to publish the update content successfully.
You will need to import the latest catalog manually from the console:
Once the newest catalog is imported, you should see the latest update(s) for the product that was previously failing to publish. Choose to publish the latest software updates(s).
Our publishing service will always download the most recent catalog before downloading any third-party update content. By downloading the newest metadata, it will ensure we are pulling the most recent updates with the current file digest before performing content publishing.
There are other benefits to switching to our publishing service including full automation. You can get more details about the benefits of our publishing service below.
If you receive the hash digest error after verifying you have imported the latest catalog and you are publishing the latest update available, it's probably because the vendor just posted a new software update that hasn't been made available in our catalog yet.
You can let us know you are getting a hash error when publishing the latest available update by using our technical support contact form. Generally, we release updates the same day a vendor makes releases the update so it will just automatically resolve itself when we update the catalog.
When attempting to download a published third-party software update, you receive the following error:
Failed to download content id <IDNumber>. Error: The cloud file provider exited unexpectedly.
In PatchDownloader.log, you will also see the following error in the log.
HttpSendRequest failed HTTP_STATUS_NOT_FOUND
ERROR: DownloadContentFiles() failed with hr=0x80070194
Error 0x80070194 translates to "The cloud file provider exited unexpectedly."
This error occurs when the published update content does not exist in the WSUSContent folder, therefore, the update is unable to be downloaded from IIS on the WSUS server to the deployment package in SCCM.
There are a variety of reason the update (.CAB) file for the published update(s) may not exist in the WSUSContent folder including:
SQL Query to determine if any Deployment Packages are referencing the WSUS content directories:
PackageId, Name, PkgSourcePath
Where PkgSourcePath like '%UpdateServicesPackages%' or PkgSourcePath like '%WsusContent%'
If you are using multiple software update points in a Shared WSUS confgurtaion, please review this guide to ensure that you shared the WSUSContent folder out on all software update points https://youtu.be/y7w7hBSHShc?t=838
Please review and video guide below to understand possible causes and resolutions for the errors listed below.
When attempting to install third-party software updates, you receive error code 0x800b0109.
In WUAHandler.log, you will also see the following error in the log.
Failed to download updates to the WUAgent datastore. Error = 0x800b0109
Error code 0x800b0109 translates to:
A certificate chain
This error occurs when a client is attempting to install third-party software update(s) that are signed using a WSUS signing certificate that isn't trusted on the client devices.
To resolve error code 0x800b0109, you need to distribute the WSUS signing certificate to the Trusted Root and Trusted Publishers certificate stores on your client devices.
You can distribute the certificate using the third-party software updates feature in SCCM 1806+ (Microsoft Docs), or you can deploy the certificate using group policy (PDF Guide).
We also have a detailed step-by-step video guide below that covers deploying the WSUS signing certificate using SCCM 1806+ or using group policy to resolve error 0x800b0109 on your clients.
Step 2 - Copy the download URL from the PatchMyPC.log for any updates receiving this hash error. Step 3 - Paste the download URL into a web browser on the same server running the publishing service and check if you receive an error that a web filter is blocking the download.
Step 4 - You will need to get exceptions created for any downloads receiving this hash error for "digest mismatch download filtered".
Please see Selectively Choose Products to Publish - Patch My PC Update Catalog for more details
To better support the upcoming third-party software update integration in Microsoft System Center Configuration Manager (SCCM), we are adding the ability to import our catalog per-product. The SCCM third-party software update catalogs feature will publish ALL updates in a catalog with metadata only. We want to give our customers the ability to add our catalog by-product if needed. This feature will allow you to selectively publish products to SCCM, and not have SCCM publish all 150+ Products.
In this video, we will demonstrate how to use Title filters in the automatic deployment rules in Microsoft Configuration Manager. This filtering can be helpful if there are specific products you need to exclude in your ADRs from our third-party software update catalog for SCCM.
Full List of Titles for Product in Our Update Catalog
Adobe Acrobat DC
Adobe Acrobat Reader DC
Adobe Digital Editions
Adobe Flash Player 32-bit/64-bit ActiveX
Adobe Flash Player 32-bit/64-bit Plugin
Adobe Flash Player 32-bit/64-bit PPAPI
Adobe Shockwave Player
Apple Application Support
Apple Mobile Device Support
Apple Software Update
Autodesk Design Review 2018
Blue Jeans Outlook Addin
Box For Office
Box Tools (Box Edit)
Citrix HDX RealTime Media Engine
ESET Endpoint Security
ESET File Security
ESET Remote Administrator Agent
Google Earth Pro
K-Lite Basic Codec Pack
K-Lite Mega Codec Pack
Lenovo System Update
Microsoft .NET Core Runtime
Microsoft .NET Core: Runtime & Hosting Bundle
Microsoft .NET Core SDK
Microsoft Azure Storage Explorer
Microsoft Mouse and Keyboard Center
Microsoft Power BI Desktop
Microsoft SQL Management Studio
Microsoft Visual Studio Code
Mozilla Firefox ESR
Mozilla Firefox to ESR Migration
Nitro Pro Enterprise
OCZ SSD Utility
Oracle Java 6/7 (x64) to Java 8 (x64) Migration
Oracle Java 7
Oracle Java 8
Oracle VM VirtualBox
PDF Split And Merge
Plex Media Player
R For Windows
RealVNC (VNC Server)
Remote Desktop Manager Enterprise
SketchUp Make 2016
SketchUp Pro 2016
SketchUp Make 2017
SketchUp Pro 2017
Telerik Progress TestStudio Ultimate
VLC Media Player
VMware Horizon Client
VMware Workstation Player
Zoom Outlook Plugin
We understand IT security is an extremely critical aspect to organizations. IT Security is probably more vital to your organization than the industry on average considering you are actively looking into a third-party patch management solution to help reduce vulnerabilities.
We often get asked how we validate the integrity of the third-party updates included in our catalog. This question is crucial for you to understand. In this post, we will describe in detail the procedures we take to ensure the quality and integrity of the patches we publish in our third-party software update catalog.
The first step in our process for creating an update is to download the update binary (EXE, MSI, or MSP) from the official vendor's download mirror. This update binary will be the file executed on client computers to update the product. The original hash of the binary and download URL is stored in our catalog metadata. The download URL is what will be used when downloading and publishing the update within your environment.
Whenever we add new updates to our catalog, the catalog metadata gets exported and saved into a CAB file. This catalog (.CAB) is imported into your environment and used to publish updates. To ensure the integrity of the catalog when downloaded and import to your environment, we dual code-sign the catalog file with our code-signing certificate. When the catalog gets downloaded in your environment, the import will only occur in our publishing service, SCCM 1806+, or SCUP if the catalog is code-signed from a trusted publisher.
We post all VirusTotal results for any third-party updates released in our RSS feed and email newsletter. These results will include the archived VirusTotal scan from our scan as well as a link to the latest VirusTotal scan for the binary.
We also maintain a complete repository of every update binary at the time of our scan on the VirusTotal Scan Reporting page.
Once the catalog is validated, only then will the catalog metadata be evaluated for processing. Since we don't control the servers used for content downloads, it's essential to ensure the file downloaded from the vendor's website is the exact same file used when initially creating the update that went through the VirusTotal scans. When an updated binary is downloaded, we will compare the hash of the downloaded binary with the hash from the catalog and only publish the update if they match.
The final layer of trust for third-party software updates before client-side installation is between your servers and clients. Whenever third-party updates are published to your WSUS environment, they are added into a CAB file that gets digitally signed using the code-signing certificate that you configure within your environment. Client devices will only install third-party patches that are signed using a trusted certificate that you have configured and deployed to your devices.
If you have any more detailed questions about our security testing, please reach out to our team using our contact form.
Starting December 28, 2018, we are moving to a supersedence model for software updates in our third-party software update catalog. Before this change, we would mark previous versions of software updates as expired.
With the Third-Party Software Update Catalogs feature in Configuration Manager 1806+, all third-party updates in a catalog are published. When we expired previous updates in our catalog, those previous versions were immediately marked expired when a new update is released. When an update is marked as expired, it can't be deployed in Configuration Manager. The immediate expiring of updates could cause issues where customers don't have enough time to fully deploy updates through all testing cycles for products where new updates are released frequently.
When using our publishing service, you can delay expiring previous versions of updates for up to 30 days to accommodate for this scenario.
By moving to a supersedence model, you will have complete control over how long you want to keep previous versions available for deployment that have been superseded.
You can control whether you want superseded updates to be immediately expired or delay expiring superseded updates for a certain number of months using the Supersedence Rules option on your software update point. In the example below, configuration manager won't expire superseded updates until they have been superseded for 1 month.
In today's catalog update in our lab, we can see the previous versions of applications are superseded and not expired. This change will allow the superseded application updates to continue being deployed for an additional month in our configuration.
If you are not expiring superseded immediately and using automatic deployment rules, you will want to ensure that you exclude superseded updates in your criteria to ensure your ADR's only deploy the latest updates.