Windows Update Error 0x80070005 on Windows 10, Server 2019

Question

I have a strange occurrence maybe someone can help me with. I've been pulling my hair out on this one for months and can't seem to find a solution.

A bit of background:

Enterprise environment that is OFFLINE, WSUS server is updated manually and push out updates down from a central WSUS over a WAN to multiple separate domains (also offline) that push all updates further down to individual servers and workstations. Don't ask why it's offline, as I'd love for it to be online, and it's not really important to the problem (I think).

This works on 90% of machines/ domains. I have two domains with around 200 workstations and 20 servers each where almost all computers are experiencing an error (specifically 0x80070005) installing the cumulative updates each month. Mostly the windows 10 clients, but on one of the domains it's also all of my Server 2019 boxes experiencing the issue as well. Some older Server 2012 R2 boxes experience no issues at these sites thus far.

All Windows 10 Machines are currently running 21H2, for reference, updates are loaded monthly, so most machines/servers are completely up-to-date, either by manual install or otherwise (manual install of msp files does work, as noted below).

Now, what I've done as far as troubleshooting:

-Stopped wuauserv and deleted/replaced c:\Windows\SoftwareDistrubution folder

-Stopped cryptSvc service and also replaced catroot2 folder

-Ran SFC and DISM (though because this crosses multiple computers and multiple servers I didn't think it was file corruption, but I've tried a great many things at this point)

-Ran troubleshooters for both BITS and WindowsUpdate

-Turned off virus scanner temporarily to remove it as a factor (no effect, same outcome)

-Firewall turned off (no effect, same outcome)

Grabbed logs, this are the pertinent parts:

2022/10/27 03:03:27.1841494 6720 9164 Misc FAILED [80070005] Failed to move file from \?\C:\WINDOWS\SoftwareDistribution\Download\091e4c73930bbf3ec46f3f913eede42a\Windows10.0-KB5018410-x64.cab to \?\C:\WINDOWS\SoftwareDistribution\Download\c9f02d14c9b6e742ef1fe0e4462e9144\Windows10.0-KB5018410-x64.cab

2022/10/27 03:03:27.1841540 6720 9164 Misc FAILED [80070005] Method failed [SusMoveOrCopyDirectoryContentsHelperRecursive:1673]

2022/10/27 03:03:27.1841851 6720 9164 Misc FAILED [80070005] Method failed [SusMoveOrCopyDirectoryContentsHelper:1754]

2022/10/27 03:03:27.1846394 6720 9164 DownloadManager Resetting shared sandbox

2022/10/27 03:03:27.1854964 6720 9164 DownloadManager FAILED [80070005] GDR

2022/10/27 03:03:27.2612272 6720 3000 Handler Loaded state: cCompleteIterations: 0, pt: Unknown, nNextRequestID: 0.

2022/10/27 03:03:27.2674763 6720 9164 DownloadManager FAILED [80070005] Error occurred while downloading update 076417E6-4FFA-4F8A-8CA0-5964A175DE47.200; notifying dependent calls.

As I completely deleted the SoftwareDistribution folder and it was replaced with a new version when the service started back up, I can't imagine folder permissions are at play here, so I'm at a loss. Now for the real reason I'm pulling my hair out:

1. MSP files for the same updates work every time (manual update), this has been my stopgap solution for these sites for the last few months.
2. These updates DO INSTALL typically over enough failed attempts, but usually it takes 40 or so tries of manually looking for updates, which initially led me to think BITS, but these all have the same group policies governing them and there is (seemingly) no difference between workstations at domains that are functioning and updating properly, and workstations/servers that are giving the error. Any assistance would be greatly appreciated.

Answer 1

Hi, @Spencer_SJ

Thank you for posting in Microsoft Q&A forum.

You may check if this helps:
https://www.bugsfighter.com/how-to-fix-windows-update-error-0x80070005/

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

From an Administrative Command Prompt on an affected client, run the following:
gpresult /h gpo.htm
and share the result with your favourite method or pastebin it so that we can see it.

I feel dual scan is in the mix

https://www.ajtek.ca/wsus/dual-scan-making-sense-of-why-so-many-admins-have-issues/

GPResult will tell us

Answer 3

Adam, your guide did mostly get me on the right track, and I did end up removing large portions of the legacy policies. I was not tracking the delivery optimization side of the house at all, and delved into that deeply before noticing there was an issue with it (possibly due to my unique network infrastructure). Oddly the "do not allow update deferral policies to cause scans against windows update" did still need to be in place for some of the clients to see updates after I found the primary culprit, so while I did see that prior to the October 2022 admx updates it had been listed as a legacy policy, it seems like a few clients still needed it to be in place, that was after additionally setting the "Specify Source Service" new policy that should get rid of the need for the deferral policy.

So that others can potentially benefit if they're in the similar position I was in, (it ended up being a combination of a couple of things). Here was my fix.

1. Delivery optimization ended up being a problem on my site, I may turn it back on in the future after running a few tests to see why it was failing. (for reference, I set it to option 0 (http only, no peering)
2. Additionally the virus scanner on-access scanning was causing issues after all, I was looking for a singular problem and wasn't anticipating two issues that were compounding into a larger issue. I wrote an exception for the on-access scanning to ignore the SoftwareDistribution folder for this issue.

Once both issues were addressed, downloads worked fine, with the notable exception of a few clients that still seemed to be having a dual scan issue until, as I mentioned, I re-enabled the "do not allow update deferral policies to cause scans against windows update" policy for now. I will reassess it again at some future timeframe. Thanks again for the assistance