Recently configured WSUS on Server 2012 RC for a lab environment in preparation for RTM and ran into a configuration problem. Clients were failing to download updates and reporting error 0x80244017. After ensuring my RC installation was updated with KB 2627818 and that the clients had KB 2720211, I double checked that clients could access the WSUS site: https://wsusserver:8531/ClientWebService/client.asmx (you’ll receive a YSOD .NET error if you load that in a web browser, it’s normal). The C:\Windows\WindowsUpdate.log file contained the following error information:
WARNING: Download job failed because of proxy auth or server auth.
Error 0x80244017 occurred while downloading update; notifying dependent calls.
After some brief troubleshooting, I came across a post that suggested it was an authentication problem, but anonymous authentication had been configured in IIS appropriately. I compared NTFS permissions of the WSUS folder with a working installation in our production environment, and found that the local Users group did not have permissions. After granting the Users group Read permissions, clients were able to successfully download updates.
Thanks for this. I was spinning my wheels looking at possible network and firewall issues.
— Will
This.
A thousand times this.
Especially when you have your WSUSContent on a Network Share you have to consider this.
Thank you good sir.
This worked, Thanks! I added the Users group (Read & Execute) to the C:\WSUS\WSUSContent folder on SBS2011. Strange thing is the WSUS parent folder had the Users group, I am not sure why this wasn’t inherited and it used to work for about a year. Perhaps some update or other changed the perms on the share or something.
Thanks for this. I have a little addition for all those who use a NAS or something similar to save their WSUS-Data on it:
I use a Synology NAS with DSM 4.1, integrated into the domain. In this NAS, you cannot add any local users from other machines. Granting the Domain-Users access does not help either.
– What you have to do is the following: Grant the local Guest-Account of the NAS read permission. You then should be able to load Updates on all your servers!
Cheers,
I changed the folder security of my network drive wsuscontent to include “Everyone” but not working again.
To make it worked I go in IIS on the WSUS Server, under the folder “Content” I setup “Connect as” with a Domain Admin account and now it’s working perfectly.
Thanks that worked 🙂
Hello,
I’m not sur you’ll see this, but but can you give me more detail about where it is ? I don’t find where is the “connect as” setting.
Thanks
Thanks very much for this. I added “authenticated users” to the share list, and that seemed to do the job for me. This was very odd though, as in our new pre-production network, half the servers were downloading updates, half were not – all using the same account details.
Thank you so much! In my case the local User Group has false security Settings.
In our case, in ISS, under WSUS administration -> Content -> Authentication ->”Windows Authentication” was disabled, clean install of server 2012 Data Center Edition… Also other issue was adding NT Service\All Services, needed to be run as a service on the server. Permissions on the shared folder was a similar one.
-Lazaro Sanchez
Thank you so much – I ran into this problem before but I forgot the solution.
This happens most of the time if the drive on which WSUS is installed has been stripped off the “Users” security settings.
Normally this should also been seen as a warning in the event log.
I had the same issue after moving the WsusContent from localdisk to a Network share.
I did all of above but it did not Work before i changed to “Connect as” to a domain admin and den restarted IIS services.
Thanks!
KUDOS to TommyG!!
Changing the “Connect As” to domain admin on the Content folder in IIS worked for me!!
Had to add read+execute permissions to WsusContent folder for IUSR (used for IIS anonymous logon) and everything is working fine now.
Jeez, didn’t even consider our normal security policy of disabling regular user access for server drives was causing this issue, I’d been looking into it all week. Would it of been so hard for MS to implement a WU error that simply says “access denied” during download?
Thanks for putting this out there.
On Server 2008R2 I must ‘Enabled’ the ‘Windows Authentication (HTTP 401 Challenge) in IIS Web Site -> Content -> Authentication to fix my 0x80244017 Problem.
(I don’t find the ‘Connection As’ option on Server 2008 R2)
After working on this problem and trying various steps for two days I came across your post. As soon as I added the permissions I was able to download and install updates from my computer. … Thank You
It was a folder permission issue for me as well. Thanks for this! Helped!!!
ty that was a long time i search on this
What local folder on C: did you chance permissons on?
C:\Windows\winsxs
guys. i am getting same error code however there is no WSUS in this scenario..”There were some problems installing updates, but we’ll try again later. If you keep seeing this and want to search the web or contact support for information, this may help: (0x80244017)”
any suggestions..
I just built out a new WSUS server on 2016 and was bumping into this problem. In IIS, under Authentication for the Content folder, Anonymous is set to use IUSR. I had to grant that account read access to the WsusContent folder and that fixed this for me.
Thank you sir!
Did not change any permission, just re applied the existing ones as these were still correct; and it worked right after!
Pingback: Resolved: WSUS Update Fails with Error Code 0x80244018 - Resolved Problem