Hello There
asked on
WSUS - Workstations not updating
Hello.
I have a few devices on WSUS (WS2008 R2) in following state (see attachment). Some of them are turned off so I understand why they haven't installed updates yet or why I see an older date in Last Status Report column. But some of them are connected and available over a network. Nothing has changed since I used commands wuauclt /detectnow, /reportnow or /resetauthorization (repeatedly).
I connected to these devices remotely and perform these commands but nothing happened.
I also made a batch file and run it on all domain devices:
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow
wuauclt /reportnow
Didn't work either.
Also I've waited a couple of days for any change. Nothing happened.
I appreciate any help.
wsus.PNG
I have a few devices on WSUS (WS2008 R2) in following state (see attachment). Some of them are turned off so I understand why they haven't installed updates yet or why I see an older date in Last Status Report column. But some of them are connected and available over a network. Nothing has changed since I used commands wuauclt /detectnow, /reportnow or /resetauthorization (repeatedly).
I connected to these devices remotely and perform these commands but nothing happened.
I also made a batch file and run it on all domain devices:
net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow
wuauclt /reportnow
Didn't work either.
Also I've waited a couple of days for any change. Nothing happened.
I appreciate any help.
wsus.PNG
ASKER
Sorry. I don't see any pattern.
how is the gpo configured? it is supposed to install on a certain day and time?
ASKER
It's set up to check for updates every 22 hours (default I guess) and updates are supposed to be installed daily at 9 am.
I don't see where you point to. GPO settings are fine. They are working on hundreds of computers.
I don't see where you point to. GPO settings are fine. They are working on hundreds of computers.
ASKER
Anybody?
I've been going through this myself. Script I have been using is:
and so far, it's worked on all but one client that I've tried it on.
The reasons for a client not reporting appear to be many, and this script attacks a number of those in that:
1. It deletes the registry keys so they get re-created.
2. It flushes the software distribution folder, which gets rid of any corrupt files.
3. It forces a re-authorization.
Run the script, then give the station 30 minutes or so to see if it appears in WSUS.
Jim.
net stop wuauserv
net stop bits
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v AccountDomainSid /f
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v PingID /f
REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v SusClientId /f
RD /s /q %windir%\SoftwareDistribution
net start wuauserv
net start bits
wuauclt /resetauthorization /detectnowand so far, it's worked on all but one client that I've tried it on.
The reasons for a client not reporting appear to be many, and this script attacks a number of those in that:
1. It deletes the registry keys so they get re-created.
2. It flushes the software distribution folder, which gets rid of any corrupt files.
3. It forces a re-authorization.
Run the script, then give the station 30 minutes or so to see if it appears in WSUS.
Jim.
ASKER
Thank you. I will come back with a feedback.
ASKER
I ran this script three times and nothing changed.
Sorry for the delay in getting back....I wanted to check on a few other things I had done.
As I mentioned, there seems to be a lot of different reasons why this can fail. While the script I posted seems to hit most, it most certainly does not cover all. That's why when you search the internet, you find a lot of different things with some saying "that did it for me" and others "did not work here".
In any case, here are the other things I did besides using the script I posted:
1. I started running the Adamj Clean-WSUS script.
I used to do this manually, but started using this script and it works well. Basically it gets rid of all the junk in WSUS. It's important to do this because if things like drivers are included, then the number of updates processed can cause a client to exceed defaults in IIS for the app pool that WSUS uses, and the operation will time out (I did increase the setting before I did the script and you still might want to do that as well, but the script should be enough).
That script can be found here:
https://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
2. I setup a GPO to populate two update settings for the clients:
Set the intranet statistics server:
Set the alternate download server:
I set these the same as the WSUS server
http://wsusServerName:portnumber
For me, the port number was 8530. To check the servers a client is pointed to, do this at a CMD prompt on the client:
reg query HKLM\SOFTWARE\Policies\Mic
and it will list the servers.
3. Made sure I could contact the WSUS server from the client. From a browser:
http://wsusServerName:portNumber
Port is usually 8530. You should get a "403 - Forbidden: Access is denied."
Then try:
http://wsusServerName:portnumber/selfupdate/wuident.cab
You should get a prompt for a file download.
4. On a couple stations, I had to manually kick-off an update telling it to check on-line for updates rather than using the WSUS server. After getting caught up on updates, the station would start to report.
I had over a dozen stations on one network not reporting and these steps took care of all.
But if none of that helps, then I would check the windowsupdate.log file for clues as to what might be happening.
Jim.
As I mentioned, there seems to be a lot of different reasons why this can fail. While the script I posted seems to hit most, it most certainly does not cover all. That's why when you search the internet, you find a lot of different things with some saying "that did it for me" and others "did not work here".
In any case, here are the other things I did besides using the script I posted:
1. I started running the Adamj Clean-WSUS script.
I used to do this manually, but started using this script and it works well. Basically it gets rid of all the junk in WSUS. It's important to do this because if things like drivers are included, then the number of updates processed can cause a client to exceed defaults in IIS for the app pool that WSUS uses, and the operation will time out (I did increase the setting before I did the script and you still might want to do that as well, but the script should be enough).
That script can be found here:
https://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
2. I setup a GPO to populate two update settings for the clients:
Set the intranet statistics server:
Set the alternate download server:
I set these the same as the WSUS server
http://wsusServerName:portnumber
For me, the port number was 8530. To check the servers a client is pointed to, do this at a CMD prompt on the client:
reg query HKLM\SOFTWARE\Policies\Mic
and it will list the servers.
3. Made sure I could contact the WSUS server from the client. From a browser:
http://wsusServerName:portNumber
Port is usually 8530. You should get a "403 - Forbidden: Access is denied."
Then try:
http://wsusServerName:portnumber/selfupdate/wuident.cab
You should get a prompt for a file download.
4. On a couple stations, I had to manually kick-off an update telling it to check on-line for updates rather than using the WSUS server. After getting caught up on updates, the station would start to report.
I had over a dozen stations on one network not reporting and these steps took care of all.
But if none of that helps, then I would check the windowsupdate.log file for clues as to what might be happening.
Jim.
ASKER
I will be back with a feedback after Christmas.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Interesting.
Since we talked here, I've now got two stations that are stuck and non-reporting. I've tracked it down to the client web services reporting an error of Text/HTML being returned rather than Text/XML with an error code of 0x80240439. I can't tell though if that is just because the WSUS is returning an HTML error for some reason or what. Interestingly enough, I can manually browse the WSUS site from the client, and don't get any errors. Client will also work fine going to Microsoft for updates, but not the internal site, so it appears that something is wrong with the internal site.
Not sure what it's trying to do and I'm trying to track that down now (haven't looked at the IIS logs as yet).
I've also got a side issue though with one of the stations with an un-related piece of software which is now returning the same error when trying to perform an update, so it may still be something with these stations. I'll report back here if I find the cause.
Bottom line: there are many, many things that can cause a workstation to not update.
Glad to hear you found a solution though!
Jim.
Since we talked here, I've now got two stations that are stuck and non-reporting. I've tracked it down to the client web services reporting an error of Text/HTML being returned rather than Text/XML with an error code of 0x80240439. I can't tell though if that is just because the WSUS is returning an HTML error for some reason or what. Interestingly enough, I can manually browse the WSUS site from the client, and don't get any errors. Client will also work fine going to Microsoft for updates, but not the internal site, so it appears that something is wrong with the internal site.
Not sure what it's trying to do and I'm trying to track that down now (haven't looked at the IIS logs as yet).
I've also got a side issue though with one of the stations with an un-related piece of software which is now returning the same error when trying to perform an update, so it may still be something with these stations. I'll report back here if I find the cause.
Bottom line: there are many, many things that can cause a workstation to not update.
Glad to hear you found a solution though!
Jim.
I've heard recently that the amount of updates to check can cause clients hanging and/or not reporting, because some pool memory is getting exhausted, so reducing the amount of updates presented to the client is something you should try. Declining old superseded updates is one way to do that (but you shouldn't do that for recent updates, unless they are not required for installation anymore).
ASKER
...
if the similar systems do exist and they have the same issue, you may work out a pattern to determine the symptom then hopefully determine the reason.