This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(102.4, 61%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Hello,
I've recently been having trouble with updates failing sporadically with error 0x80070005 Access denied. Running the updates manually will work, and sometimes logging on to the VM (Windows Server 2016 Datacenter build 1607) and running USOCLIENT STARTINSTALL will work also.
These and other workarounds have kept things going for a while but the problem has not subsided. So I've focused on update KB486129 .Net 4.8 for Windows 1607.
2022/05/18 05:36:31.0253626 448 2360 Shared Effective power state: AC
2022/05/18 05:36:31.0253661 448 2360 Agent Released network PDC reference for callId {263D9664-30DD-4759-B1EA-8B5A523DCC9A}; ActivationID: 70
2022/05/18 05:36:31.0254743 448 3068 ComApi *RESUMED* Download ClientId = UpdateOrchestrator
2022/05/18 05:36:31.0254751 448 3068 ComApi Download call complete (succeeded = 0, succeeded with errors = 0, failed = 1, unaccounted = 0)
2022/05/18 05:36:31.0254763 448 3068 ComApi Exit code = 0x00000000; Call error code = 0x80240022
2022/05/18 05:36:31.0254767 448 3068 ComApi * END * Download ClientId = UpdateOrchestrator
2022/05/18 05:36:31.0254774 448 3068 Agent WU client calls back to download call {263D9664-30DD-4759-B1EA-8B5A523DCC9A} with code Call complete and error 0x80070005
2022/05/18 05:36:31.0259610 448 2008 ComApi ISusInternal:: DisconnectCall failed, hr=8024000C
2022/05/18 05:36:31.0312324 448 2360 DownloadManager The update's sandbox is in use. Will download when it is no longer busy.
2022/05/18 05:36:31.0340846 448 5000 DownloadManager Generating download request for update {E704CD3A-DB85-4197-AA31-F62F6C07B1D2}.201
2022/05/18 05:36:31.5793450 448 5000 DownloadManager Calling into handler 0x3 to generate download request for update E704CD3A-DB85-4197-AA31-F62F6C07B1D2.201
2022/05/18 05:36:31.5796150 448 5000 Handler MSP download: file excel-x-none.cab already exists in sandbox directory (C:\Windows\SoftwareDistribution\Download\5e040ccb5b37cba3e7a992f17657d65c)
2022/05/18 05:36:32.2861818 448 5000 Handler MSP Download: file C:\Windows\SoftwareDistribution\Download\5e040ccb5b37cba3e7a992f17657d65c\excel-x-none.cab passed cert/hash validation.
2022/05/18 05:36:37.4054375 448 5000 DownloadManager Resetting shared sandbox
2022/05/18 05:36:37.4058473 448 5000 DownloadManager Download request generation failed with 0x80070005.
2022/05/18 05:36:37.4059096 448 5000 DownloadManager Error 0x80070005 occurred while downloading update; notifying dependent calls.
2022/05/18 05:36:37.4077520 448 2360 DownloadManager * END * Download Call Complete Call 3 for caller UpdateOrchestrator has completed; signaling completion.
2022/05/18 05:36:37.4096189 448 2360 Shared Effective power state: AC
2022/05/18 05:36:37.4096221 448 2360 Agent Released network PDC reference for callId {CC6BC872-29B6-4310-9288-8DCCAA1F723E}; ActivationID: 71
2022/05/18 05:36:37.4099067 448 3068 ComApi *RESUMED* Download ClientId = UpdateOrchestrator
2022/05/18 05:36:37.4099075 448 3068 ComApi Download call complete (succeeded = 0, succeeded with errors = 0, failed = 1, unaccounted = 0)
2022/05/18 05:36:37.4099426 448 3068 ComApi Exit code = 0x00000000; Call error code = 0x80240022
2022/05/18 05:36:37.4099430 448 3068 ComApi * END * Download ClientId = UpdateOrchestrator
2022/05/18 05:36:37.4099442 448 3068 Agent WU client calls back to download call {CC6BC872-29B6-4310-9288-8DCCAA1F723E} with code Call complete and error 0x80070005
2022/05/18 05:36:37.4104239 448 2008 ComApi ISusInternal:: DisconnectCall failed, hr=8024000C
I've think I've gone down a few incorrect routes looking into this so any advise would be much appreciated. On older machines its mentioned about registry permissions and Indexing Service but these both turned out to be fruitless. One article I found was mentioned that build 1607 wasn't working so they upgraded to version 1803, which isn't an option now. I'd have to make a case to upgrade to 1809 as its 300 Production VMs which will need updating.
Thanks.
Thank you for your quick response!
I'll apply policy change this to our WSUS testing group, I've also done a WSUS reset on those machines so hopefully will start to see some results tomorrow.
I will update here as soon as I know more.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 24%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERH%3C/text%3E%3C/svg%3E)
@MEvansDCC
Is there any updates of the case? Please keep us in touch if there are any updates or questions.
Wish you have a great weekend. Looking forward to your feedback next week :-)
Regards,
Rita
Nothing different this morning. But might be worth waiting till after the weekend.
If you don't mind, how did you identity that it was the bits service which was not operating properly? Do you know of any guides or notes on how to learn more about the WindowsUpdates.log?
I'd like to learn more about diagnosing these.
Have a great weekend too!
Thanks,
Matt
Hello Matt,
It is not quite certain whether this issue is due to BITS. This question can be a bit complicated. The connecting between the WSUS server and the affected devices is OK. Also the device attempted to download updates from the WSUS server. The logs show that there is no express payload for this update. The devices try to get the express payload from DO, but failed. Whether you check the following options in the WSUS console？
Perhaps we could try to enable the Download express installation files option on the WSUS console and then try to Not approved the updates on the WSUS console. Delete the affected updates on the content folder on the WSUS server. Then we could try to approve the required updates again.
Just one more questions. It seems that the devices tried to downloaded several updates, like SSU, Cumulative updates for .Net framework and for windows and Microsoft Excel 2016. Please help to confirm whether the SSUs updates and 2022-05 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5013952) update are downloaded and installed successfully.
Thanks for your understanding and cooperation.
Best regards,
Rita
Hi Rita,
Thanks, sorry for the delay I was unexpected absent.
The targeted machines have not installed the update as we'd hoped.
So I will try enabling Express Installation Files (as it is not enabled currently), set the update to No Approved and clear the updates off the WSUS server.
Just so I'm sure, deleting the affected update from the WSUS server can be done through the Server Cleanup Wizard, or is there a manual method?
As for SSU, Cumulative updates for .Net framework and for windows and Microsoft Excel 2016. updates, we do have some failures for those updates occasionally. But I was focusing on KB486129 initially as I thought it might be easier.
Kind Regards,
Matt
Hello Matt,
Thanks for your response.
Just so I'm sure, deleting the affected update from the WSUS server can be done through the Server Cleanup Wizard, or is there a manual method?
We could also use PowerShell scripts to handle it. But the Server Cleanup Wizard is more convenient. Here are reference links for your reference:
https://learn.microsoft.com/en-US/troubleshoot/mem/configmgr/wsus-maintenance-guide
https://learn.microsoft.com/en-us/powershell/module/updateservices/Invoke-WsusServerCleanup?view=windowsserver2016-ps
As for SSU, Cumulative updates for .Net framework and for windows and Microsoft Excel 2016. updates, we do have some failures for those updates occasionally. But I was focusing on KB486129 initially as I thought it might be easier.
Got it. Please try to follow the above steps and check whether it is helpful. Please keep us in touch if there are any feedback.
Have a great day.
Best regards,
Rita
205789-windowsupdate.log
Hello Rita,
I've been through the WSUS maintenance and the express installation doesn't seem to have made a difference since I approved the update again to the test group.
Please see attached the new WindowsUpdate.log. I can see an error:
2022/05/26 12:47:43.6294818 1116 6268 DownloadManager Failed to connect to the DO service; (hr = 80040154)
2022/05/26 12:47:43.6294822 1116 6268 DownloadManager GetDOManager() failed, hr=80246008, hrExtended=80040154
2022/05/26 12:47:43.6294830 1116 6268 DownloadManager Failed creating DO job with hr 80246008
2022/05/26 12:47:43.6324395 1116 6268 DownloadManager DO download failed with error 80246008[Extended: 80040154], falling back to BITS and retrying with new Download Job.
Still seems to say its using DO despite how I set the GPO to Bypass
Kind Regards,
Matt
Hello Matt,
As far as I know, the group policy you mentioned above is the one I used to bypass the DO instead to use BITS to download the approved updates from WSUS. The devices will try to use the BITS to download the approved updates instead by DO.
Best regards,
Rita
Hi Rita,
That is the one, I enabled it. However the windowsupdate.log I have attached seems to imply its still using DO instead of BIts.
I'm off next week so I apologise about this thread going quiet but I will update again as soon as I am back.
Thanks for all the help so far!
Kind Regards,
Matt
It is so weird. Please help to comfirm the connection between WSUS Server and the affected device. Please open IE browser on the affected devices and print the related URL as the following:
http://WSUS Server:8530/selfupdate/iuident.cab
You will get a iuident.cab file if the connection is OK.
I have enabled the SSL in my lab and the following screenshot just for your reference:
In addition, please open the PowerShell as an administrator and print the following commands to check the default update resouce of the device:
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services | select Name, IsDefaultAUService
Reference screenshot in my lab:
Best regards,
Rita
Thanks for waiting, and for the advise.
I tried accessing the URL from one of the client servers and it could not access the URL. "The DNS server returned: Name Error: The domain name does not exist."
Also I ran the command as you suggested and had the following results:
Entering the URL on the WSUS server itself works, to prove that its not user error on entering the URL.
However following this revelation, I've checked another client machine in the same collection and it could access the URL.
I'm now in the process of trying to see if there is a problem with some of the builds. I have a feeling there might be some VMs which need rebuilding, but would be good to know what the problem is exactly so I will have to do some cross checking against these client servers and the updates which failed and the URL which is no accessible.
Kind Regards,
Matt
Hi Rita,
I've tried the URL you suggested and found to my chagrin that some of the clients could access the URL and others could not.
I researched this a bit further and found this might be unrelated as I found clients which can access the URL to download the iuident.cab but still cannot download the update:
2022/06/07 10:41:46.3541207 1156 3740 DownloadManager Download request generation failed with 0x80070005.
2022/06/07 10:41:46.3541353 1156 3740 DownloadManager Error 0x80070005 occurred while downloading update; notifying dependent calls.
The above keeps appearing in the windows update logs.
As for the Powershell, the results, they are same on each client:
Name IsDefaultAUService
---- ------------------
Windows Store (DCat Prod) False
Windows Server Update Service True
Windows Update False
Kind Regards,
Matt
Hello Matt,
I want to confirm one more question. Have you just tried to add the .esd MIME Types In IIS WSUS Administartion site before? Please try to follow the below link to add the MIME Types and check whether it is helpful.
https://rdr-it.com/en/troubleshooting/wsus-fix-the-problem-of-downloading-windows-10-updates/
Note that the link isn't from MS, just for your refernece.
Best regards,
Rita
Hi Rita,
I added in the .esd MIME type into IIS as you suggested yesterday. But I've not seen anything change over night yet.
I have noticed on a few of the clients that are not installing the update KB4486129 that I can install it if I open Windows Settings - Update & Security and click Retry.
So this is odd, as must be an inconsistency in our GPO as some clients are more locked down (something else I'll look into).
That aside, it is odd the updates fail to install overnight during their specified installation and reboot times, but if I click Retry it will install successfully.
One client I've done this on this morning is waiting till the scheduled reboot time of 23:00 before finishing.
I've attached the log of this client here, though I can't discern where in the log it is actually installing the update for .Net 4.8 and Security Update for 2016 successfully.
Kind Regards,
Matt Evans209775-windowsupdate.log
@MEvansDCC
Thanks for your posting on Q&A.
The phenomenon only occurred on the Windows Server 2016 Version 1607 servers. Right? Have you enabled the SSL in your WSUS Server? Would you mind sharing the whole windowsupdate.log for me to research further?
Thanks for your understanding and cooperation.
Best regards,
Rita
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.
Thanks for the reply @Rita Hu -MSFT !
Yes it does seems to just be on our Windows Server 2016 1607 servers.
We don't have SSL enabled in WSUS. I've attached a copy of the Windows Update log which was generated yesterday: 203625-windowsupdate.log
Thanks again for looking into this.
@MEvansDCC
Thanks for your response.
I have reviewed the log files in detail. It seems that the device tried to updates but the BITs Service isn't running normally. Then the device try to request the task from DO(Delivery Optimization). But it failed again. I recommended to apply the following group policy to disable the DO(Delivery Optimization) in the affected devices.
Browse to the following location:
Computer Configuration\Administrative Templates\Windows Components\Delivery Optimization
Then please run the below link to reset Windows Update components on the affected devices and check whether it is helpful.
https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-resources
Hope the above will be helpful :-)
Best regards,
Rita
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.