I'm setting up and ADR for our third party updates. Some download okay, some error out with "HttpSendRequest failed HTTP_STATUS_NOT_FOUND" in the PachDownloader.log file. In RuleEngine.og I see
"Failed to download the update from internet. Error = 404". The URL is correct and works when copied to IE and tested. What's weird is if I copy the WSUS url to IE launched at SYSTEM, the .cab file doesn't download. I don't think this a PatchMyPC error or problem, but was hoping someone might have a simple solution before I engage Premier Support.
Thanks,
Jim
Hi Jim, are seeing any error messages from your publishing service report. This may be similar: https://patchmypc.com/publishing-error-2147954402-2147954429-2147954407
If not, submit a support ticket with us and lets dig into it for you.
There are no related errors in the PatchMyPC.log file. Prior to attempting the ADR, everything has been working. In fact, if I select one of the updates that fails the ADR, right-click and download, it works. So this seems to be related to using ADRs. I attached a screenshot of the PatchDownloader.log file to better explain what I'm seeing.
Jim
Hey Jim,
Are you using a Proxy?
Quote from: JimWebbNCH on November 01, 2019, 01:11:08 PM
There are no related errors in the PatchMyPC.log file. Prior to attempting the ADR, everything has been working. In fact, if I select one of the updates that fails the ADR, right-click and download, it works. So this seems to be related to using ADRs. I attached a screenshot of the PatchDownloader.log file to better explain what I'm seeing.
Jim
Yes. Our organization does use a proxy and I did have it enabled in the ConfigMgr settings on the site system role for the server that hosts WSUS. I've since disabled the proxy setting "Use a proxy server when synchronizing information from the Internet" and I also unchecked the two check boxes regarding the proxy on the SUP role too. When I disabled the proxy, the error did change from from a proxy related error to the error I'm getting now.
Thanks for any help!
Jim
Did you test by unchecking the use proxy for ADR content downloads?
Can you check if the CAB files exist in the WSUSContent folder? Downloads Fail - Error: The cloud file provider exited unexpectedly. Error 0X87D20417 or 0x80070194 - https://patchmypc.com/third-party-updates-fail-to-download-error-the-cloud-file-provider-exited-unexpectedly-error-0x80070194-or-0x87d20417
Quote from: JimWebbNCH on November 04, 2019, 06:32:54 AM
Yes. Our organization does use a proxy and I did have it enabled in the ConfigMgr settings on the site system role for the server that hosts WSUS. I've since disabled the proxy setting "Use a proxy server when synchronizing information from the Internet" and I also unchecked the two check boxes regarding the proxy on the SUP role too. When I disabled the proxy, the error did change from from a proxy related error to the error I'm getting now.
Thanks for any help!
Jim
If I open the URL in IE the files do exist. I also verified in the file system as well. What doesn't work is if I try the URL from an IE browser launched as SYSTEM, and of course the ADR.
Jim
Did you review the video in the KB here to see if that helps https://patchmypc.com/third-party-updates-fail-to-download-error-the-cloud-file-provider-exited-unexpectedly-error-0x80070194-or-0x87d20417
Hello,
I reviewed the video and even tried the movecontent trick but I'm still getting the same error. When I try the URL from the logs in a browser, the CAB file downloads. But it still fails under the ADR.
Jim
Hi Jim, did you select to republish the update and also choose to supersede the update then sync the publisher.
I'm working on that now. I have a lot of products published so I need to figure out which ones are failing so I can republish those. The logs list the updates by update ID so I've had to translate that into the actual name of the update. I should have more info next week.
Thanks.
Jim
Do the same updates the fail to download via ADR fail to download from the SCCM console manually?
Quote from: JimWebbNCH on November 08, 2019, 02:11:03 PM
I'm working on that now. I have a lot of products published so I need to figure out which ones are failing so I can republish those. The logs list the updates by update ID so I've had to translate that into the actual name of the update. I should have more info next week.
Thanks.
Jim
Nope. No updates fail when manually selecting and downloading in the console. They only fail when the ADR runs. The cab files are present on the WSUS server, and are available to download when the URL is pasted in a browser.
Jim
Your issue is that ADRs tries to use the proxy and your proxy cannot resolve your wsus content website. Please up-vote this user voice we created for SCCM
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/38885431-add-option-to-bypass-proxy-for-local-address-for-a
The current work around for adr's to work is to allow your proxy to resolve and download content from the wsus server.
Quote from: JimWebbNCH on November 08, 2019, 02:18:12 PM
Nope. No updates fail when manually selecting and downloading in the console. They only fail when the ADR runs. The cab files are present on the WSUS server, and are available to download when the URL is pasted in a browser.
Jim
Is there a way to configure PachMyPC to use the FQDN of the server instead of the short name when publishing patches? Also, what about requiring the use of SSL? I'd like to be able to try the FQDN of the server using https.
https://servername.domainname.com:8531
I'll add a vote to the uservoice.
Jim
Hey Jim,
We don't actually set the download URL that reflects in ConfigMgr. That's based on what you entered when you created the software update point site system role.
It may be easiest to edit the host file on the proxy so hosting can resolve as a workaround.
UPDATE: Actually just chatted with the ConfigMgr PG. The download URL comes from the WSUS API and that is set to use the hostname. If you wanted support to do FQDN, it would actually be something that needs to go over to the ConfigMgr UserVoice portal.
Justin
Quote from: JimWebbNCH on November 11, 2019, 01:38:25 PM
Is there a way to configure PachMyPC to use the FQDN of the server instead of the short name when publishing patches? Also, what about requiring the use of SSL? I'd like to be able to try the FQDN of the server using https.
https://servername.domainname.com:8531
I'll add a vote to the uservoice.
Jim