locked
Issues with WSUS not seeing clients RRS feed

  • Question

  • 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.

    Wednesday, July 29, 2015 8:27 PM

Answers

  • 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    • Proposed as answer by Steven_Lee0510 Thursday, July 30, 2015 9:59 AM
    • Marked as answer by Frank Shen5 Tuesday, August 11, 2015 5:53 AM
    Wednesday, July 29, 2015 9:20 PM
  • 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    • Marked as answer by PaulGreene Friday, August 21, 2015 3:14 AM
    Tuesday, August 18, 2015 9:18 PM

All replies

  • 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    • Proposed as answer by Steven_Lee0510 Thursday, July 30, 2015 9:59 AM
    • Marked as answer by Frank Shen5 Tuesday, August 11, 2015 5:53 AM
    Wednesday, July 29, 2015 9:20 PM
  • 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"

    

    Thursday, July 30, 2015 4:29 PM
  • "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?


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, July 30, 2015 9:28 PM
  • 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"

    Thursday, July 30, 2015 10:22 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

    
    Friday, July 31, 2015 5:02 PM
  • 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)

    Friday, July 31, 2015 5:17 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
    Friday, July 31, 2015 5:25 PM
  • following a suggestion the browser made when run locally, I checked to see if directory browsing was enabled or not in IIS manager on the WSUS server and it was disabled. I enabled it and it does give me a blank page now
    Friday, July 31, 2015 5:50 PM
  • restart IIS and WSUS services and see if that helps now
    Friday, July 31, 2015 6:33 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


    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.

    Friday, July 31, 2015 7:43 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, July 31, 2015 10:41 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Oh geez, I recall running into this - Win7 and Server2k8 machines weren't able to get to WSUS (throwing a WU error) until the patch was installed on the WSUS server. KB2734608 to be exact.

    Update for Windows Server Update Services 3.0 SP2 for x64-based Systems (KB2734608)

    Saturday, August 1, 2015 3:19 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 3, 2015 8:02 PM
    Monday, August 3, 2015 7:30 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 3, 2015 8:02 PM
    Monday, August 3, 2015 7:48 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


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, August 4, 2015 9:34 PM
  •   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,

    François

    Wednesday, August 5, 2015 8:35 PM
  •   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.

    0x80072EE6 =
    The URL does not use a recognized protocol

    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.



    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, August 5, 2015 9:44 PM
  • 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


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Wednesday, August 5, 2015 10:06 PM
  •   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,

    François.

    Friday, August 7, 2015 1:42 PM
  • In the GPO, the url to the WSUS server must begin with http://

    Rolf Lidvall, Swedish Radio (Ltd)

    Friday, August 7, 2015 3:08 PM
  • 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?

    
    Friday, August 7, 2015 5:51 PM
  • 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)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Friday, August 7, 2015 11:31 PM
  • 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)
    Monday, August 10, 2015 6:59 PM
  • Actually, this update is already installed anyway, back in January (kb2938066)
    Monday, August 10, 2015 7:56 PM
  • 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)

    https://technet.microsoft.com/en-us/library/dd939795(v=ws.10).aspx

    https://technet.microsoft.com/en-us/library/dd939856(v=ws.10).aspx

    These links are from the WSUS 3.0SP2 Operations guide. The sqlcmd etc parameters need to be modified to suit WS2012/WS2012R2 (because the WID is accessed differently on the modern OS). There is a link to a gallery script, and there are comments there for the necessary changes to suit WID on modern OS.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Monday, August 10, 2015 9:02 PM
  • 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)

    Wednesday, August 12, 2015 2:51 AM
  • 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)


    sqlcmd isn't installed by default. The link to the Gallery script includes guidance and a link to download the "Feature Pack for SQL Server" which will get you the SQL CLI tools: 

    https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

    Or you can download and install SQL Server Management Studio (SSMS) and use the GUI for the task.

    The number of updates on the server, depends upon the products and classifications you have selected, and how/if you are managing your approvals/declines.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    • Edited by DonPick Wednesday, August 12, 2015 9:32 AM
    Wednesday, August 12, 2015 9:30 AM
  • 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

    Monday, August 17, 2015 3:10 PM
  • 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?

    Monday, August 17, 2015 6:48 PM
  • 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)

    

    Tuesday, August 18, 2015 3:47 PM
  • 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?

    Tuesday, August 18, 2015 6:14 PM
  • (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)

    

    You may need to request that your forum identity be "verified" before you can post certain content-types. You can request that by posting a comment in the thread "Verify Your Account" https://social.technet.microsoft.com/Forums/en-US/home?forum=reportabug

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, August 18, 2015 9:15 PM
  • 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.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    • Marked as answer by PaulGreene Friday, August 21, 2015 3:14 AM
    Tuesday, August 18, 2015 9:18 PM
  • 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!

    Friday, August 21, 2015 3:14 AM