9,785 pts.
Yes this is one of the roughly 4 standard answers which include things like reinstalling the wsus 3.0 client (or optionally installing the wsus 2.0 client and having it autoupdate itself).
No - it and the other solutions didn’t work or did not work consistently (i.e. for more than one system). This method worked on one out of 15 failing machines.
We did notice one machine that was failing worked when we changed its IP address.
To add to the confusion we are not sure if it is the server or the client.
Changing IP address made updates happen. Reverting to the previous address stopped them again. No other changes to machine. Both IP addresses should be valid. Most odd.
Well we’ve made some progress in the what, if not why or how. Note we don’t run the ADS at our site, being a department in a division, although we do have administrative access and delegation.
We have now worked out that the clients fail when members of the domain. We do know that the domain supplies an auto-proxy configuration. Which we [believe we] do not participate in and have autoconfiguration of the proxy (for IE anyway) turned off. Note that yes we can access the selfupdate and simpleauth pages through IE without any authentication or use of a proxy. We also noted that some of our machines are reported on the WSUS MMC control as using the proxy they have set up.
So… we now know the following (and it is consistent and repeatable):
member of domain with odd IP = NO updates
member of domain with good IP = NO updates
member of workgroup with *any* IP = updates
Which is kind of nice as it implies not a serious internal problem with the clients or the WSUS server.
The WSUS client diag says no proxy & proxycfg says winhttp has direct access, and the IP addresses that both work and fail are in the same subnet so any filtering by their proxy (if it is being used) is more sophisticated than either we or they know.
So - can we verify or check proxy usage any other way?
Pter
I am adding this to the discussion as it isn’t an answer but a fix for us.
We set the proxy via proxycfg, and anything will do for the proxy name, but importantly put in a bypass for the local network. e.g.
proxycfg -p noproxyatall “*.our.domain,123.210.*,127.0.0.1,<local>”
This has overridden whatever is being pushed onto us from the domain and updates are now happening. So there’s obviously nothing wrong with client OR server. However as to why this fixes it and no proxy was reported by proxycfg when we set it to -d, which you’d expect if one was being set, we don’t yet know. But at least we can get on without worrying about updates.
