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(233.6, 78%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGJ%3C/text%3E%3C/svg%3E)
Greetings all,
I have been trying to nail down why my windows updates are failing on my client machines.
We did an AD Rename (rendom) at the end of the year and ever since we've not had the windows updates work. Everything else appears to be working fine. I have tried a wide variety of things, including this week by building a new server and placing a new WSUS install upon it.
The problem is that the "downloading - 0%" never moves beyond 0% eventually, after a long wait, the updates will fail. The client machines have detected the new WSUS server and have correctly identified which updates need to be applied so this shows that the WSUS server is being responsive and the clients are getting to it.
The client machines are Server 2019 and I have used the Get-Windowsupdatelog cmdlet to examine the logs on one of the affected machines. I am finding the log fairly impenetrable however. I can see some "FAILED" but I can't see anything that points to anything specific.
This is happening across all machines since the AD rename and I'm at a loss as to what, exactly, is wrong and thus also stymied trying to find a solution.
I can tell from the log that the client machine is reaching the new server.
One of the sets of messages is this:
"StatusCode for transaction returned from WinHttpQueryHeaders is 401"
"FAILED [800710DD] Send request"
"FAILED [800710DD] WinHttp: SendRequestToServerForFileInformation (retrying with default proxy)"
(there is no proxy)
A 401 is Unauthorized, which I suspect is pointing to the root of the problem. I suspect, but cannot find, that the service is attempting to use an invalid credential/identification. In an AD rename, the SIDs don't actually change, but the names (NBT and domain both) do change. So if formerly the login was AAA\Name1, the new name might be BBB\Name1.
I have disjoined and rejoined machines to the AD, no change. I've reset the WSUS parameters I usually reset when I do a clone, no change.
Stuck and looking for advice.
-g
Confirm your permissions for WSUS
https://www.ajtek.ca/wsus/wsus-permissions-wsuscontent-registry-and-iis/
Also, it could be a bad SPN record that needs updating due to the renaming of the domain?
Greetings Adam - love your script...
I looked at the article and I don't have permissions so I'll update that but I need to ask. In your example there for the folder (e.g. <%windir%>\WSUS\WSUSContent) was it the WSUS folder or the WSUSContent folder which should have the permissions set. If the WSUS, should the settings be propagated downward? Also, network service is good for all server variations or only 2003? Which would be preferable if either could be used? Read it rather innocuous so I guess I could set both and make them both read.
Regarding the SPN, we've had no other issues with SPN / Kerberos at all so I'd think not. Do you have anything specific you'd suggest looking at for the SPN possibility?
I'm going to get it a try adding both as read and I'll report back.
Woot! Adding <localmachine>\Users to the WSUS folder did the trick!
I tried to edit the comment to fix some typos and further note that Network Service already had Full Control on the WSUSContent folder. I simply added <localmachine>\Users to the WSUS folder which propagated to WSUSContent.
Update, I went back to the old WSUS server and added the <localmachine>\Users to the WSUSContent folder directly and then ran in another client and that worked. So, the answer of which folder needed to be updated was "WSUSContent" and adding Users as read to it.
Thanks Adam!