Automatic Deployment Rule (ADR) Error 0X87D20417 or 0x80070194

There are a few reasons you may see an automatic deployment rule fail with error code 0X87D20417/0x80070194 or a third-party update fail to download to a deployment package in the ConfigMgr console with error The cloud file provider exited unexpectedly. These two scenarios are a result of the same root cause which is discussed below.

Topics covered in this article:

Root Cause
- Root Cause of Error 0x80070194 and 0X87D20417
Scenarios:
- Scenario 1: Automatic Deployment Rule Fails with Error 0X87D20417
- Scenario 2: In-Console Download Error: The cloud file provider exited unexpectedly.
Troubleshooting:

Root Cause of Error 0x80070194 and 0X87D20417

These errors generally occur when the third-party update (.CAB) fie published to the WSUSContent folder is deleted, or the Content virtual directory in IIS is not configured properly.

There are various reasons the update (.CAB) file for the published update(s) may not exist in the WSUSContent folder, including:

Custom WSUS cleanup scripts removing content from the WSUSContent directory
The WSUSContent folder is misconfigured in IIS
The WSUSContent folder is pointing to a UNC network share and the appropriate configurations and permissions weren’t configured
The Deployment Package source path does not have the needed NTFS or SMB permissions configured

Scenario 1: Automatic Deployment Rule Fails with Error 0X87D20417 or 0x80070194

Depending on the Configuration Manager build, you will see an ADR failure code of 0X87D20417 or 0x80070194.

Example of ADR with Last Error Code of 0x80070194

Example of ADR with Last Error Code of 0X87D20417

In PatchDownloader.log (For ADR), you will likely see one of the following errors in the log:

HttpSendRequest failed HTTP_STATUS_NOT_FOUND or HttpSendRequest failed 502

ERROR: DownloadContentFiles() failed with hr=0x80070194 or ERROR: DownloadUpdateContent() failed with hr=0x800701f6

Failed to create directory \\hostname\folder\<guid>.1\<guid>_1.cab, error 5

CreateLinkToExistingFile() failed for ContentID <id>. hRes = 0x80070005

ERROR: DownloadUpdateContent() failed with hr=0x80070005

In ruleengine.log, you may also see one of the following errors in the log:

Failed to download the update content with ID <id> from internet. Error = 5

Failed to download ContentID <id> for UpdateID <id>. Error code = 5

Scenario 2: In-Console Download Error: The cloud file provider exited unexpectedly.

When downloading a third-party update in the ConfigMgr console to a deployment package you receive the following error “Error: The cloud file provider exited unexpectedly.“

In PatchDownloader.log (For Console Downloads), 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.“

Troubleshooting Step 1: Does the (.CAB Update Files) Exist in the WSUSContent Folder

The first step you need to do is confirm the updates being downloaded exist in the WSUSContent folder. Here’s a diagram that should help understand the data flow for the download of third-party updates.

Determine the full download URL based on the PatchDownloader.log. Once the download URL is determined, you can check if the folder and CAB file actually exist in the WSUSContent folder.

Note: To match a missing .cab file to an Update in ConfigMgr or WSUS, please review the following article https://patchmypc.com/associating-missing-cab-file-in-wsus-to-an-update

If the CAB file doesn’t exist, you will be unable to download and deploy that specific update(s) where the CAB file is deleted. The possible resolutions for this scenario are:

Republish the update(s) as a new update and supersede the existing update
Restore the CAB file is there is a backup of the WSUSContent folder that contains the CAB file

Common Reasons WSUSContent Folders or CAB Files are Deleted

If the two-character folders in the WSUSContent folder are deleted, we found the most common reason for this is when a deployment package in ConfigMgr uses the same path of the WSUSContent. This configuration will cause ConfigMgr to delete all folders, including published third-party updates periodically. Please review our article Incorrectly configured deployment package to use the WSUSContent folder.

If only the updates (.CAB files) are missing from the two-character sub-folders in WSUSContent and using a shared WSUS database with multiple WSUS servers, it may be a common certificate misconfiguration causing the .CAB deletion. Please review Update CAB Files Deleted from WSUSContent when Using Shared SUSDB if (.CAB) update files are automatically deleted right after publishing.

Troubleshooting Step 2: Check if the WSUS Signing Certificate is Trusted on Site Server

Another common reason ADRs may fail is the WSUS signing certificate hasn’t properly been install on the site server. If you have this issue, you will see the following errors.

If failing to download when using ADRs, you should check the PatchDownloader.log (For ADR). You will likely see the following errors:

Authentication of file C:\Users\<username>\AppData\Local\Temp\CAB85AE.tmp failed, error 0x800b0004

ERROR: DownloadUpdateContent() failed with hr=0x80073633

If failing to download when using ADRs, you the RuleEngine.log will likely see the following error:

Failed to download the update content with ID 16777699 from internet. Error = 13875

0x800b0004 = The subject is not trusted for the specified action.
0x80073633 = Invalid certificate signature
13875 = Invalid certificate signature

To check if the WSUS signing certificate is installed, perform the following actions:

1. Download the specific update CAB file failing to download using a web browser or copy directly from the WSUSContent folder. You can get the update download URL or folder/file path to the WSUSContent folder based on the PatchDownloader.log

2. Copy the .CAB file to the machine running the ConfigMgr console if failing to download via console or to the site server if using an ADR. On properties of the file, review the Certification Path tab, and review if there are any trust errors.

If the certificate shows any trust errors, you will need to deploy this certificate to all machines or manually install it to Trusted Root and Trusted Publishers on the affected machine if for testing only.

Troubleshooting Step 3: Verify the Content Virtual Directory is Correct

If you validated the CAB file existed in step 1, the next step is to validate the Content virtual directory in the WSUS Administration website is correct.

There is a bug in the WSUS setup process that can remove the leading \\ when using a UNC path for the WSUSContent folder.

To check the Physical Path for the Content virtual directory: Right-click Content > Manage Virtual Directory > Advanced Settings…

Here’s an example of the WSUS bug where the leading \\ are removed from the virtual directory Physical Path. Because the directory is invalid in the Content virtual directory updates will fail to download with error 0x80070194 or 0X87D20417.

If you are affected by this scenario, simply update the path to include the leading \\ as shown below and click OK

Troubleshooting Step 4: Is WSUSContent a UNC Share with the Default IUSR Authentication

We also see customers where a UNC path is being used, and the authentication identity hasn’t been changed to use the Application pool identity for the Content virtual directory. Perform the following actions to review and resolve this issue if applicable:

Click the Content virtual directory > Double Click Authentication in the IIS Group

Right-Click the Anonymous Authentication and Click Edit

Here you can review the Anonymous user identity used for authenticating to the WSUSContent directory. By default, the authentication is set to use the specific user: IUSR. IUSR is a local user-specific to the WSUS server and will not have access to a authenticate to any remote UNC share.

In the Edit Anonymous Authentication Credentials dialog for the Anonymous Authentication ensure it is set to use the Application pool identity

Note: This step would only be applicable if the WSUSContent folder uses a UNC path for the Physical Path in the Content virtual directory.

Troubleshooting Step 5: ADR’s may Fail for Third-Party Updates if a Proxy is Enabled

If all the previous settings are correct, another common reason ADR’s will fail to download third-party updates is due to a proxy being enabled.

First, review if the checkbox Use a proxy server when downloading content by using automatic deployment rules is enabled in the Software update point Properties

A proxy of often required to download Microsoft updates directly from the internet for ADRs. However, in some scenarios where the PatchDownloader component will use the proxy for the downloads from the internal WSUS server.

If the proxy server cannot resolve the internal WSUS server using DNS or a firewall blocking the proxy from downloading content from internal servers, it will cause third-party updates to fail to download.

In PatchDownloader.log (For ADR), you will probably see a https error 502. Here’s an example of what you may see in PatchDownloader.log if the proxy server can’t resolve the WSUS server name.

HttpSendRequest failed 502
ERROR: DownloadUpdateContent() failed with hr=0x800701f6

In the image below, you can see details in the PatchDownload.log that shows a proxy in use during the download of the software update.

If you are affected by the proxy issue, we have a knowledge base article with workarounds at Updates Fail to Download in ADR with Error HttpSendRequest failed 502 / 0x800701f6.

Note: The specific HTTP error code can vary depending on how the proxy returns the download error, but the most common we have seen is 502 errors.

Troubleshooting Step 6: Is a Deployment Package Using the WSUSContent Folder?

One issue that can cause files and folders to be deleted from the WSUS Content folder is when a software update deployment package is using the WSUS Content folder as the package source location.

Here’s an example of a deployment package incorrectly using the WSUS Content folder(s) as the package source path.

When a deployment package is configured to use the WSUS Content folder as the package source, Configuration Manager will automatically delete all files and folders not related to the deployment package, including the published third-party update CAB files.

You can quickly check if any deployment packages are using the WSUS Content folder by performing the steps below:

In the ConfigMgr console, navigate to Software Library > Software Updates > Deployment Packages

Right-click the columns and add Pkg Source Path

In the search box, enter the word wsus and click the search button. In our example below, we can see two deployment packages using the WSUS content folder(s) as the package source path.

Your deployment package source path for Patch My PC updates should be a new dedicated folder that isn’t pointing to the WSUS Content folders at all. Here’s an example of a valid path and invalid paths.

If you had the WSUS Content pointing to the WSUS Content folders and the update CAB files where deleted, the workaround is the republish the third-party updates affected. Please see the following knowledge base article: When and How to Republish Patch My PC Third-Party Updates

Troubleshooting Step 7: Verify SMB and NTFS Permissions on Deployment Package Source Path

This troubleshooting step mostly pertains to when you see “access denied” type error messages or codes in PatchDownloader.log or ruleengine.log, while also seeing the error code 0X87D20417 for your ADR in the SCCM console. The error codes you will likely see in the mentioned log files can be 5 or 0x80070005.

This particular issue revolves around trying to initiate the download for updates in to a Deployment Package.

The likely root cause in this scenario is going to be insufficient permissions on the Deployment Package’s source path. For ADRs to download updates to a Deployment Package, the SYSTEM account of the site server needs to be able to read and write to the source path.

The solution is to review the SMB and NTFS permissions of the source path used for the Deployment Package. We have a seperate KB article dedicated to this topic: Failed to download content id <id>. Error: Access is Denied.

Troubleshooting Step 8: Recreate Automatic Deployment Rule and select “Download software updates from the Internet”

This troubleshooting step mostly pertains to when you see

Failed to download the update content with ID XXXXXX from UNC content source. Error = 3

in ruleengine.log, while also seeing the error code 0X87D20417 for your ADR in the SCCM console.

This particular issue occurs when you select “Download software updates from a location on my network” during Automatic Deployment Rule creation.

The solution is to recreate the Automatic Deployment Rule and select “Download Software updates from the internet” on the Download location section.

Video Version of Troubleshooting

Please review and video guide below to understand possible causes and resolutions for the errors listed below.

ERROR: DownloadContentFiles() failed with hr=0x80070194
HttpSendRequest failed HTTP_STATUS_NOT_FOUND

Knowledge Base

We’re here to help if needed