I recently inherited a task of fixing a non-functioning WSUS server running on Windows 2012. Theoretically, there should be about 15 servers checking in, but only 2 domain controllers have appeared so far.

Some of the clients cannot ping the WSUS server, so its possible there's some network communication issues. I've been playing with one that can ping it though to see if I can find something wrong with the WSUS configuration itself.

I'm going through this reference -> cc708627 in the TechNet library (the forum won't let me post the complete URL)

This URL to test the source update tree fails

If I go to the URL for WSUS server address plus port #; I get a "403 - Forbidden: Access is Denied" error

The Update Files configuration option is set to "Download update files to this server only when updates are approved"

Not sure where to go from here.

Paul G.

http://technet.microsoft.com/en-us/library/cc708627 is targeted at older versions of WSUS. Older WSUS runs on port 80 by default, port 8530 if you set that.
You're running WS2012 (or perhaps WS2012R2), which runs on port 8530 by default, so make sure you are checking for the webservices on the correct port for your installation. You can check your current configuration on the WSUS, in the IIS settings.

When clients communicate with WSUS, there is no relationship to communication between WSUS and MSFT (each is a separate set of communication).
i.e. Client -> WSUS is one conversation, and, WSUS -> MSFT is a different conversation.
So, your WSUS could be happily contacting MSFT for data, even if the clients can't properly contact your WSUS.

On the client, check windowsupdate.log. This is the primary source of diagnostic information on a client.
On the WSUS, there are logfiles at c:\program files\update services\, but these are mainly for WSUS > MSFT comms.
You can check the IIS logfiles on the WSUS to see what client > WSUS comms are going on.

If your clients are 32bit, the WSUS Client Diagnostic Tool might be helpful. This tool doesn't work on 64bit clients. The Solarwinds client diag tool works for 64bit clients.

When you check the windowsupdate.log on clients, it's often useful to take a checkpoint of the file, at the point where the WU service started, because a bunch of useful info is echoed into the log at service startup.

What you can do, is to stop the AU service on the client, rename the windowsupdate.log, then restart the AU service, which creates a fresh logfile at service startup. Check that the logfile is showing the correct/expected configuration (e.g. that it's configured correctly for your WSUS, and not pointing off to some other server or incorrect config). Walk through the logfile looking for errors, warnings, etc.
It's helpful to compare a problem logfile, with a "known good" logfile, unless you are very familiar with what "normal" logfiles look like in the environment you're working in.

The WSUS server appears to be communicating with MS Update service just fine; in the event logs, there are no errors and it appears to have daily communication.

I followed your suggestion about restarting Windows Update service on the client and starting a new log; this forum doesn't seem to let me copy and paste parts of the log file into this message. There are several lines with WARNING or FATAL in it; here's a few sample lines:

"WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80240037"

"WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered"

"WARNING: WinHTTP: SendRequestUsingProxy failed for <http://IP-address:8530/selfupdate/wuident.cab", error 0x80072ee2

"WARNING: WinHTTP: SendRequestTo ServerForeFileInformation MakeRequest failed, error 0x80072ee2

"FATAL: DownloadCab failed, err = 0x80072ee2"

"FATAL: SelfUpdate check failed, err = 0x80072ee2

The logs on the WSUS server aren't that useful; there's just two that repeat themselves several times a day:

"Client computers are installing updates with a higher than 25 percent failure rate"

"Many client computers have not reported back to the server in the last 30 days. 2 have been detected so far"



"WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80240037"

"WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered"

Those are very normal, and can be ignored. (basically saying that it hasn't determined if you are on a metered connection or not, so it assumes NOT)

"WARNING: WinHTTP: SendRequestUsingProxy failed for <http://IP-address:8530/selfupdate/wuident.cab", error 0x80072ee2

"WARNING: WinHTTP: SendRequestTo ServerForeFileInformation MakeRequest failed, error 0x80072ee2

"FATAL: DownloadCab failed, err = 0x80072ee2"

"FATAL: SelfUpdate check failed, err = 0x80072ee2

80072EE2 is the issue. But it basically translates into "the webservice is busy", which is not the whole story.

Can you access the webservice URLs successfully if you plonk them into a web browser on the client machine?

How are clients being configured to contact the WSUS server? Were they set up manually, or via GPO?

Open the WSUS console on the server, and verify the port information (80/8530)

WSUS requires a IIS http site functioning on the same port. I will assume this is ok if there are clients/DC's working on WSUS.

Verify the GPO settings that are configuring these systems to use the WSUS server, and that it is enabled on the OU the clients are in. Make sure that both the update server and report server point to the address of the WSUS server, in full, ie. http://servername:port under "Specify intranet microsoft update server address"

If I go to "//<wsus.server.IP.address>:8530" I get a "403 Forbidden: Access is denied" error

If I go to "//<wsus.server.ip.address>:8530/selfupdate/wuident.cab" I do get an option to download the wuident.cab file, and can successfully download it

Not sure how it was done originally. There is a GPO in Active Directory that specifies the WSUS ip address and port number as the WUServer and WUStatus server

One of the options set is "DisableWindowsUpdateAccess", set to yes. Does that only block access to the MS update site, or could that possibly be interfering with access to the local WSUS server too?

One odd thing is that most of the servers involved are Win 2012, but there are 3 Win2008 servers that don't seem to be able to receive group policies from AD (not sure if related or separate issue)

http://<wsus.server.IP.address>:8530 should work, you should just get a blank page but not a 403 or anything

DisableWindowsUpdateAccess is driven from the GPO "Turn off access to all Windows Update features" which blocks the endpoint from going directly to the internet for Windows Updates in the event that your WSUS server is unreachable (as a fallback). this is not the cause of your issue

it sounds like you need to straighten out your GPOs and your IIS permissions if the root site for WSUS is throwing access errors in the browser

can you get to http://<wsus.server.IP.address>:8530 locally from the WSUS server itself?

i'll be honest with you, it doesn't sound like this solution is working well right now except for a few servers, I would just blow away WSUS, clean up and re-install it again

• Edited by armin19 13 hours 35 minutes ago

http://<wsus.server.IP.address>:8530 should work, you should just get a blank page but not a 403 or anything

DisableWindowsUpdateAccess is driven from the GPO "Turn off access to all Windows Update features" which blocks the endpoint from going directly to the internet for Windows Updates in the event that your WSUS server is unreachable (as a fallback). this is not the cause of your issue

it sounds like you need to straighten out your GPOs and your IIS permissions if the root site for WSUS is throwing access errors in the browser

can you get to http://<wsus.server.IP.address>:8530 locally from the WSUS server itself?

i'll be honest with you, it doesn't sound like this solution is working well right now except for a few servers, I would just blow away WSUS, clean up and re-install it again

I also get a 403 trying to access my working WSUS server by the root address. I don't think this will have any effect on the issue at hand.

I do tend to agree, that it will be faster and less stressful to blow it away and start from scratch, although it will take a couple days for all the clients to report in and sync everything back up, but will definitely be worth it in the end to clean up disk space and get it running properly and smoothly as opposed to patched up and kinda working.

http://<wsus.server.IP.address>:8530 should work, you should just get a blank page but not a 403 or anything

DisableWindowsUpdateAccess is driven from the GPO "Turn off access to all Windows Update features" which blocks the endpoint from going directly to the internet for Windows Updates in the event that your WSUS server is unreachable (as a fallback). this is not the cause of your issue

it sounds like you need to straighten out your GPOs and your IIS permissions if the root site for WSUS is throwing access errors in the browser

can you get to http://<wsus.server.IP.address>:8530 locally from the WSUS server itself?

i'll be honest with you, it doesn't sound like this solution is working well right now except for a few servers, I would just blow away WSUS, clean up and re-install it again

• Edited by armin19 Friday, July 31, 2015 5:25 PM

http://<wsus.server.IP.address>:8530 should work, you should just get a blank page but not a 403 or anything

DisableWindowsUpdateAccess is driven from the GPO "Turn off access to all Windows Update features" which blocks the endpoint from going directly to the internet for Windows Updates in the event that your WSUS server is unreachable (as a fallback). this is not the cause of your issue

it sounds like you need to straighten out your GPOs and your IIS permissions if the root site for WSUS is throwing access errors in the browser

can you get to http://<wsus.server.IP.address>:8530 locally from the WSUS server itself?

i'll be honest with you, it doesn't sound like this solution is working well right now except for a few servers, I would just blow away WSUS, clean up and re-install it again

• Edited by armin19 Friday, July 31, 2015 5:25 PM

If I go to "//<wsus.server.IP.address>:8530" I get a "403 Forbidden: Access is denied" error

If I go to "//<wsus.server.ip.address>:8530/selfupdate/wuident.cab" I do get an option to download the wuident.cab file, and can successfully download it



Those are both positive signs - that's how it should respond when you perform those tests.

Did you try the Solarwinds Client Diag tool? (Or are you unable/unwilling to do that? It's understandable if so, it just means more manual testing by you ;)

Is the WSUS server WS2012 or WS2012R2? There are some WSUS patches, which may (or not) be applicable, depending upon the server version.

If some "clients" have been updating from windowsupdate, those could have newer WUAgents (via selfupdate @ windowsupdate), and mismatched WUAgent versions, against a not-patched WSUS, can get confusing. You can check the WUAgent versions by checking windowsupdate.log on the client machines.

You can check the WSUS version (patch level) by looking in the opening/main status screen of WSUS.

If I go to "//<wsus.server.IP.address>:8530" I get a "403 Forbidden: Access is denied" error

If I go to "//<wsus.server.ip.address>:8530/selfupdate/wuident.cab" I do get an option to download the wuident.cab file, and can successfully download it



Those are both positive signs - that's how it should respond when you perform those tests.

Did you try the Solarwinds Client Diag tool? (Or are you unable/unwilling to do that? It's understandable if so, it just means more manual testing by you ;)

Is the WSUS server WS2012 or WS2012R2? There are some WSUS patches, which may (or not) be applicable, depending upon the server version.

If some "clients" have been updating from windowsupdate, those could have newer WUAgents (via selfupdate @ windowsupdate), and mismatched WUAgent versions, against a not-patched WSUS, can get confusing. You can check the WUAgent versions by checking windowsupdate.log on the client machines.

You can check the WSUS version (patch level) by looking in the opening/main status screen of

(to DonPick)

The WSUS server is 2012 R2 Standard. The WSUS version (from the Help | About screen) is 6.3.9600.16384

The client that I've been testing from has a WU Client version of 7.9.9600.17404 (from the windowsupdate.log file) This server is 2012 R2 standard as well.

On a different client server, running win 2008 r2, the wu client version is 7.6.7600.320 (this server doesn't appear to be able to communicate with the WSUS server at all)

I'd be happy to try Solar Winds but don't have access to it. In this environment adding additional software is a major pain to get approval for - I'd be happy to try any manual checks.

Paul

• Edited by PaulGreene Monday, August 03, 2015 8:02 PM

(to DonPick)

The WSUS server is 2012 R2 Standard. The WSUS version (from the Help | About screen) is 6.3.9600.16384

The client that I've been testing from has a WU Client version of 7.9.9600.17404 (from the windowsupdate.log file) This server is 2012 R2 standard as well.

On a different client server, running win 2008 r2, the wu client version is 7.6.7600.320 (this server doesn't appear to be able to communicate with the WSUS server at all)

I'd be happy to try Solar Winds but don't have access to it. In this environment adding additional software is a major pain to get approval for - I'd be happy to try any manual checks.

Paul

• Edited by PaulGreene Monday, August 03, 2015 8:02 PM

(to Kronical_420)

That link appears to be non-applicable - my server is 2012 and that link/patch applies to 2003 and 2008.

• Edited by PaulGreene Monday, August 03, 2015 8:02 PM

(to Kronical_420)

That link appears to be non-applicable - my server is 2012 and that link/patch applies to 2003 and 2008.

• Edited by PaulGreene Monday, August 03, 2015 8:02 PM

The WSUS server is 2012 R2 Standard. The WSUS version (from the Help | About screen) is 6.3.9600.16384

The client that I've been testing from has a WU Client version of 7.9.9600.17404 (from the windowsupdate.log file) This server is 2012 R2 standard as well.

On a different client server, running win 2008 r2, the wu client version is 7.6.7600.320 (this server doesn't appear to be able to communicate with the WSUS server at all)

I'd be happy to try Solar Winds but don't have access to it. In this environment adding additional software is a major pain to get approval for - I'd be happy to try any manual checks.

Don't rely on the WSUS-Help-About - it's historically unreliable. Instead, in the WSUS console, in the left pane, select the server. In the right pane, pie charts and stuff show up, and so does the "reliable" WSUS version number.

https://support.microsoft.com/en-au/kb/2938066 may be needed. This is the latest cumulative rollup for all WSUS versions. It incorporates the patch mentioned by Kronical, plus more. Research this carefully. This will update the selfupdate content, causing all clients to update their WUAgent. (but if your problem is out-of-sync versions, it's probably exactly what is needed to resolve that)

If your issue is actually communication or incorrect networking settings, this KB isn't going to fix that.
Also a couple of tips here:
https://technet.microsoft.com/en-us/library/dd939824(v=ws.10).aspx

  Hello,

It seems that I have the same error. I have installed WSUS on 2012 R2 x64.

Just before this install, I create a simple web site on IIS on port 80 and a FTP site. So WSUS is second website.

On client side, I have the error 80072EE6. On Client side, when I open the web page http://mywsusurl:8530/, I have the error "403 - Forbidden: Access is denied. You do not have permission to view this directory or page using the credentials that you supplied."

But the url http://mywsusurl:8530/selfupdate/wuident.cab works on client. So is it a problem with IIS authorization ? Or it's another problem with Client (or server) ?

In local, on WSUS server, the url http://mywsusurl:8530/ works, it just display a 403.14 because I'm not allow to view the directory "HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.".


I check the Version of WSUS server and it's 6.3.9600.16384 (in server dashboard, like ask by DonPick). So it's version 3.0 SP2 or just 3.0 ?

I tried to look at link given by DonPick, but I didn't really sure what to do. Which patch I should applied ?

I also tried to view at folder permission, and it seems that "network service" isn't present in WSUS folders. But "All application packages" is present. And I'm not able to change this permission, even in administrator.

Any ideas is welcome,

regards,

Franois

  Hello,

It seems that I have the same error. I have installed WSUS on 2012 R2 x64.

Just before this install, I create a simple web site on IIS on port 80 and a FTP site. So WSUS is second website.

On client side, I have the error 80072EE6. On Client side, when I open the web page http://mywsusurl:8530/, I have the error "403 - Forbidden: Access is denied. You do not have permission to view this directory or page using the credentials that you supplied."

But the url http://mywsusurl:8530/selfupdate/wuident.cab works on client. So is it a problem with IIS authorization ? Or it's another problem with Client (or server) ?

In local, on WSUS server, the url http://mywsusurl:8530/ works, it just display a 403.14 because I'm not allow to view the directory "HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.".


I check the Version of WSUS server and it's 6.3.9600.16384 (in server dashboard, like ask by DonPick). So it's version 3.0 SP2 or just 3.0 ?

I tried to look at link given by DonPick, but I didn't really sure what to do. Which patch I should applied ?

I also tried to view at folder permission, and it seems that "network service" isn't present in WSUS folders. But "All application packages" is present. And I'm not able to change this permission, even in administrator.

Source: Winhttp
-----

Check the client configuration (examine the windowsupdate.log) and look for the WUServer:
Are you correctly configuring the client settings for the WUServer item?
It should be like: WUServer = http://mywsusurl:8530

Note, it is "normal" that http://mywsusurl:8530, from a client, will not return anything useful. This item is merely a simple test of IIS is listening/bound, it is not expected to display any kind of useful web page.

I check the Version of WSUS server and it's 6.3.9600.16384 (in server dashboard, like ask by DonPick). So it's version 3.0 SP2 or just 3.0 ?

It is neither of those. WSUS 3.0 is only to be found on WS2008R2 and older.
WS2012 = WSUS 6.x

  Hello Don,

Here the windowsupdate.log file :

2015-08-07 15:37:00:729 1092 2980 AU Triggering AU detection through DetectNow API
2015-08-07 15:37:00:729 1092 2980 AU Triggering Online detection (interactive)
2015-08-07 15:37:00:729 1092 1a18 AU #############
2015-08-07 15:37:00:729 1092 1a18 AU ## START ##  AU: Search for updates
2015-08-07 15:37:00:729 1092 1a18 AU #########
2015-08-07 15:37:00:731 1092 1a18 AU <<## SUBMITTED ## AU: Search for updates [CallId = {547B6972-5CB7-4B1B-8D07-DC918BF7F18D}]
2015-08-07 15:37:00:731 1092 920 Agent *************
2015-08-07 15:37:00:731 1092 920 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
2015-08-07 15:37:00:731 1092 920 Agent *********
2015-08-07 15:37:00:731 1092 920 Agent  * Online = Yes; Ignore download priority = No
2015-08-07 15:37:00:731 1092 920 Agent  * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
2015-08-07 15:37:00:731 1092 920 Agent  * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2015-08-07 15:37:00:731 1092 920 Agent  * Search Scope = {Machine}
2015-08-07 15:37:00:731 1092 920 Setup Checking for agent SelfUpdate
2015-08-07 15:37:00:731 1092 920 Setup Client version: Core: 7.6.7601.18917  Aux: 7.6.7601.18917
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: WinHttpCrackUrl failed. error 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: Initialize failed with 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: Library download error. Error 0x80072ee6. Will retry. Retry Counter:0
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: WinHttpCrackUrl failed. error 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: Initialize failed with 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: Library download error. Error 0x80072ee6. Will retry. Retry Counter:1
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: WinHttpCrackUrl failed. error 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: Initialize failed with 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: Library download error. Error 0x80072ee6. Will retry. Retry Counter:2
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: WinHttpCrackUrl failed. error 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: WinHttp: Initialize failed with 0x80072ee6
2015-08-07 15:37:00:732 1092 920 Misc WARNING: DownloadFileInternal failed for mywsusurl:8530/selfupdate/wuident.cab: error 0x80072ee6

The strange thing, it's that url "mywsusurl:8530/selfupdate/wuident.cab" works great when openning in Chrome and IE (on Windows 7). But Windows Update isn't able to do it.

There is something to configure in local to authorize access to it ? I tried to disable Firewall on my computer and WSUS server, but the problem is exactly the same.

regards,

Franois.

The help about info is actually the same as what's in the WSUS admin console so the WSUS version number is actually 6.3.9600.16384.

One of the notes for that patch make me nervous though - it says "WSUS must be in a healthy working state for this update to work. If WSUS is configured to synchronize updates from Microsoft Update, make sure that WSUS can synchronize updates. Additionally, clients must be able to communicate with the WSUS server."

This WSUS server isn't healthy! It does seem to synchronize with MS Update just fine, but none of the clients are able to communicate with the WSUS. Would applying that patch cause things to go haywire?

One of the notes for that patch make me nervous though - it says "WSUS must be in a healthy working state for this update to work. If WSUS is configured to synchronize updates from Microsoft Update, make sure that WSUS can synchronize updates. Additionally, clients must be able to communicate with the WSUS server."

This WSUS server isn't healthy! It does seem to synchronize with MS Update just fine, but none of the clients are able to communicate with the WSUS. Would applying that patch cause things to go haywire?



Update to WSUS itself, will typically replace some of the binaries for WSUS, and, often run a T-SQL script on the SUSDB to make some changes to the db. As an example, if the db is not "healthy", the T-SQL script may encounter an unhandled error during execution, and script execution may abort, leaving the db locked in single-user mode, or some other condition.

If you have been performing WSUS maintenance tasks, like managing your declines (so that there aren't massive numbers of unapproved/undeclined updates), been running the SCW, reindexing the db, etc, and, those tasks have been free of errors/crashes, and the Windows logs and IIS are not unhealthy, you should be fine.

Make a backup of the SUSDB beforehand, so you can restore that if something does go wrong.

Or, if you don't care a great deal about the groups/approvals/client-history in the DB, the potential for reinstalling WSUS probably wouldn't bother you very much. (in the event WSUS crashes, at any time, for any reason)

I never did any maintenance on the WSUS database, and I'm pretty sure my predecessor didn't either. Do you have a link to a good document that describes what you're supposed to do in this maintenance? (it doesn't use MS SQL, so I'm guessing it must be using the internal WSUS database)

I don't find the sqlcmd anywhere on the server, running a find from the root of c:\. I do have the "show hidden" option checked in Windows Explorer. I tried looking on both our production server and a test environment I setup at home to troubleshoot this problem. ??

On the production server, I do notice under "All Updates" that there are 12,787 updates on the server. Is that number abnormally high, or is it normal? (the servers this is supposed to service are Windows 2012 and Windows 2008)

I don't find the sqlcmd anywhere on the server, running a find from the root of c:\. I do have the "show hidden" option checked in Windows Explorer. I tried looking on both our production server and a test environment I setup at home to troubleshoot this problem. ??

On the production server, I do notice under "All Updates" that there are 12,787 updates on the server. Is that number abnormally high, or is it normal? (the servers this is supposed to service are Windows 2012 and Windows 2008)

Sorry this is dragging on so long, but I have not made any progress at all on resolving this problem. I did install the sqlcmd utility on my test server but the script failed to run correctly.

Just to reiterate, this is what's not working correctly:

two domain controllers have checked into the WSUS server, and I get an accurate report on missing patches in Windows update on the domain controller, but I can't install patches using the WSUS server - I manually download the patches and apply them. In the WSUS console, even though the two domain controllers were in the list of computers that have registered to the WSUS server, one of them is reported has never having checked in, even though it reports accurately how many patches this server is missing in Windows update on the domain controller. The other domain controller hadn't checked in since May 15, but after I got it up to date with patches, it does report its status in the WSUS console now.

No other server has checked into the WSUS server, even though they have a WSUS GPO policy that points them to the correct IP address. The wuauclt /detectnow, /reportnow, /resetauthorization switches don't seem to do anything.

When I look through the Windows update log, I can see that many servers are trying to go directly to the Microsoft update site, even though they have the registry key set to point them to the local WSUS server, and DisableWindowsUpdate is set. Windows update seems to be ignoring any registry settings that point them to the correct WSUS server.

When I manually type in the URL for the wuident.cab test, all them can reach that URL, as long as I use the port number in the URL (without the port number it fails).

I'm about to go bald because of pulling my hair out.

Paul

if you run rsop.msc on a few of the endpoints, do you see any conflicting GPOs for WU?

have you considered re-installing WSUS as initially suggested since it hasn't really been working anyway?

This WSUS server was reinstalled already because the previous one wasn't working correctly. I'm starting to believe the problem isn't with the configuration of the WSUS server itself, and if that's the case, reinstalling again isn't going to fix the actual problem.

On one server, the errors coming up in windowsupdate.log are:

******************

Got WSUS SelfUpdate URL: "http://192.168.1.96:8530/selfupdate"

WARNING: Proxy List Used :<192.168.2.248:8080> Bypass List used: <<local>> Auth Schemes used:<None>

WARNING: Send request failed, hr:0x80072ee2   (lots of subsequent 0x80072ee2 errors, which are supposed to be "ERROR_INTERNET_TIMEOUT" error)

*******************

Which would seem to indicate proxy related errors. I've found a lot of posts of people with similar symptoms (windows update ignores GPO policies, systems don't check in to WSUS server, etc) that were resolved after dealing with an underlying proxy config problem.

(btw, why can't I copy and paste into this forum?? I can see that many other people post their log files, but it won't let me post mine; it would be easier for everybody concerned if I could post more complete log files here, and not have to hand type it in)



There's several articles about getting WSUS to use a proxy to synchronize with Microsoft to get updates, but I can't find any about how to configure clients to get to a WSUS server through a proxy. I found some proxy server requirements, as follows:

- proxy server has to support HTTP 1.1 range requests

- make sure HTTP inspection server doesn't inspect traffic if it is tunneled

Is there any other important proxy configuration items that need to be set?

(btw, why can't I copy and paste into this forum?? I can see that many other people post their log files, but it won't let me post mine; it would be easier for everybody concerned if I could post more complete log files here, and not have to hand type it in)



There's several articles about getting WSUS to use a proxy to synchronize with Microsoft to get updates, but I can't find any about how to configure clients to get to a WSUS server through a proxy. I found some proxy server requirements, as follows:

- proxy server has to support HTTP 1.1 range requests

- make sure HTTP inspection server doesn't inspect traffic if it is tunneled

Is there any other important proxy configuration items that need to be set?

Does your implementation actually demand a proxy between clients and WSUS? (if not, you must remove that setting from the clients).

If your implementation does demand a proxy, that may require you to configure the proxy settings using netsh, since WUAgent and BITS operate in the system-context not in a user-context.

I ran "netsh winhttp show proxy" and found that most of the servers that were having issues had a proxy setting configured. Running "netsh winhttp reset proxy" stopped them from trying to go through the proxy, and a couple of new systems registered with the WSUS server that hadn't been able to register before.  This is the first thing that could be called 'progress' so I'm breaking out the champagne with a still cautionary note.  :-)

There's still some issues, but that might warrant a different thread.

Thanks!