none
WSUS Server does not show up in Windows Update services - 80072EFE error as well RRS feed

  • Question

  • Server 2008 R2 X64.

    Things were running smoothly, this particular server also manages the updates, all other computers are getting their updates currently.  I had an issue with Windows updates throwing an error when trying to install, error 80072EFE shows up.  So, I deleted this server from WSUS, did wuauclt.exe /detect now and days later the server is still not showing up in WSUS.  Here is the log file after the command listed earlier:

    2012-08-23    15:16:04:378     812    bb8    AU    Triggering AU detection through DetectNow API
    2012-08-23    15:16:04:378     812    bb8    AU    Triggering Online detection (non-interactive)
    2012-08-23    15:16:04:378     812    654    AU    #############
    2012-08-23    15:16:04:378     812    654    AU    ## START ##  AU: Search for updates
    2012-08-23    15:16:04:378     812    654    AU    #########
    2012-08-23    15:16:04:378     812    654    AU    <<## SUBMITTED ## AU: Search for updates [CallId = {BD303B02-2552-4A26-AA46-0D67F970AAEA}]
    2012-08-23    15:16:04:378     812    afc    Agent    *************
    2012-08-23    15:16:04:378     812    afc    Agent    ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2012-08-23    15:16:04:378     812    afc    Agent    *********
    2012-08-23    15:16:04:378     812    afc    Agent      * Online = Yes; Ignore download priority = No
    2012-08-23    15:16:04:378     812    afc    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"
    2012-08-23    15:16:04:378     812    afc    Agent      * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2012-08-23    15:16:04:378     812    afc    Agent      * Search Scope = {Machine}
    2012-08-23    15:16:04:378     812    afc    Setup    Checking for agent SelfUpdate
    2012-08-23    15:16:04:378     812    afc    Setup    Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    2012-08-23    15:16:04:378     812    afc    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2012-08-23    15:16:04:378     812    afc    Misc     Microsoft signed: Yes
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: Send failed with hr = 80072efe.
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: SendRequest failed with hr = 80072efe. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <https://server.domain.local/selfupdate/wuident.cab>. error 0x80072efe
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efe
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efe
    2012-08-23    15:16:07:015     812    afc    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efe
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: Send failed with hr = 80072efe.
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: SendRequest failed with hr = 80072efe. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <https://server.domain.local/selfupdate/wuident.cab>. error 0x80072efe
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efe
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efe
    2012-08-23    15:16:09:339     812    afc    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efe

    I suppose it's two issues, but I think they are part of the same problem.  As I stated before, this server was getting updates from WSUS up until the 7-20-12.  Nothing else is on this box except some anti virus (VIPRE Business console) Network Inventory Advisor, and a system to download linux updates for our filepro servers.  Any ideas? I'm stumped! 


    Computer Systems Specialist

    Thursday, August 23, 2012 7:26 PM

All replies

  • 2012-08-23    15:16:07:015     812    afc    Misc    WARNING: Send failed with hr = 80072efe.

    0x80072EFE -2147012866 ERROR_INTERNET_CONNECTION_ABORTED  The connection with the server has been terminated.

    <https://server.domain.local/selfupdate/wuident.cab>.

    Fundamentally something dropped your connection. I note that the connection is via SSL. You've noted that this client is the WSUS server. Is this the only machine demonstrating this issue? Is this machine FULLY patched?

    2012-08-23    15:16:04:378     812    bb8    AU    Triggering AU detection through DetectNow API

    How did you invoke this detection?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, August 24, 2012 12:53 AM
    Moderator
  • As far as I can tell, Lawrence, this is the only machine having this issue.  I manually fully patched the machine via Windows Update online hoping it would help.  I invoked the detection by going to command prompt and triggering wuauclt.exe /detectnow.  Is it possible I'm missing something in the trusted sites?  The server is not behind our proxy server as well.

    Computer Systems Specialist

    Friday, August 24, 2012 2:32 PM
  • I do have these optional updates available as of today, however I'm thinking they don't pertain to this issue.


    Computer Systems Specialist

    Friday, August 24, 2012 2:35 PM
  • Is it possible I'm missing something in the trusted sites?

    It's more likely that the issue has something to do with the SSL configuration of the server.

    The selfupdate files should not be getting requested via https!

    https://server.domain.local/selfupdate/wuident.cab

    How was this machine configured to be a WSUS client?

    If all the other systems are working correctly, what is the URL they have configured for the WSUS server?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, August 24, 2012 5:17 PM
    Moderator
  • Interesting!  How may i find the URL that the clients are connecting to?  I had some difficulty finding information on that earlier as well.

    Computer Systems Specialist

    Friday, August 24, 2012 6:04 PM
  • Interesting!  How may i find the URL that the clients are connecting to?

    Several ways actually.

    • Inspect the WindowsUpdate.log at service startup -- all of the key configuration values are written to the logfile at service start.
    • Inspect the WindowsUpdate.log during any detection event -- the WSUS URL is peppered all over dozens of types of log entries.
    • Inspect the registry value "WUServer" in HKML\Software\Policies\Microsoft\Windows\WindowsUpdate.
    • Look in the GPO(s) that are defined to configure the clients.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, August 24, 2012 10:07 PM
    Moderator
  • Ok... so the updates are pointing to https://server.domain.local.  And they do come through ok for the other clients.  This ring true for the two areas I checked, the registry of a couple of clients, as well as the update location in GPO for servers and workstations.  *Scratching head*

    Computer Systems Specialist

    Monday, August 27, 2012 2:15 PM
  • Any ideas folks?  I'm at a loss here.

    Computer Systems Specialist

    Thursday, August 30, 2012 3:18 PM
  • Any ideas folks?  I'm at a loss here.

    Computer Systems Specialist

    Well, fundamentally, as noted, something is interfering with the network pathway and the responses from the WSUS server are not getting back to the client.

    Is this client configured to use a proxy server? Should it be configured to use a proxy server? Is there a proxy server anywhere on the network? Is the client and the WSUS server on the same subnet?

    If it's not a network issue, then we're left with a server performance issue which is discussed here weekly.

    • How many updates are synchronized on the WSUS server?
    • How many updates are approved on the WSUS server?
    • How many groups are configured on the WSUS server?
    • How many clients are registered with the WSUS server?
    • When's the last time you ran the Server Cleanup Wizard?
    • When's the last time you removed approvals from superseded updates?
    • When's the last time you ran the DB Maintenance script?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin


    Friday, August 31, 2012 1:03 AM
    Moderator
  • This client is not configured to use a proxy server, it should not be because the client is the WSUS server itself.  It should get updates from itself.  There is a proxy server on the network that all of our pc's and laptops run through on a different subnet.  Still confused that the WSUS server did get it's updates from WSUS, and all of a sudden stopped working.  I still don't see the server even showing up in the Update Services GUI.

      - There are 30532 updates on the server.

      - 26868 updates are approved.

      - One group is configured

      - 381 computers are registered (the client in question was deleted to see if it would come back via AD list)

      - Never ran the server cleanup wizard.  It is about a month old (brand new hardware).

      - I have never removed approvals from superseded updates, will look up how to do this and fix that.

      - I have never run the DB Maintenance script.  Do tell?

    Thanks for your help Lawrence, I've learned a lot thus far.


    Computer Systems Specialist

    Tuesday, September 4, 2012 1:45 PM
  • Ok, I did get the DB Maint script to run.  I'll see if the computer in question shows up on the list tomorrow.  I did a server cleanup, however that hung halfway through.  Will try that again tomorrow as well.

    Computer Systems Specialist

    Tuesday, September 4, 2012 7:03 PM
  • The server did not show up in WSUS today.

    Computer Systems Specialist


    • Edited by zbomb33 Wednesday, September 5, 2012 12:18 PM
    Wednesday, September 5, 2012 12:06 PM
  • This client is not configured to use a proxy server, it should not be because the client is the WSUS server itself.  It should get updates from itself.

    The fact that the machine is both client and server has no real bearing on whether it's configured, right or wrong, to use or not use a proxy server.
    There is a proxy server on the network that all of our pc's and laptops run through on a different subnet.
    So then, would you please visually confirm that this machine is NOT configured to use any proxy devices? Although based on the below information, I doubt this is the issue.
    Still confused that the WSUS server did get it's updates from WSUS, and all of a sudden stopped working.
    It's not really confusing at all. Something changed that impacts how the WUAgent on this machine communicates with the WSUS service. The key is to find that "What" that changed.
    I still don't see the server even showing up in the Update Services GUI.
    Of course not. We know unequivocally that it's not talking to the WSUS server. The objective here is to determine WHY this is not happening.
    There are 30532 updates on the server.
    Ouch!
    26868 updates are approved.
    Ouch! Ouch! Ouch!
    Never ran the server cleanup wizard. It is about a month old (brand new hardware).
    Was this a FRESH install of WSUS, or was it replicated from an older installation that had been in service for some time?
    I have never removed approvals from superseded updates, will look up how to do this and fix that.
    Yes. This is, no doubt, the root cause of your problem.
    I have never run the DB Maintenance script.
    After cleaning up the approvals and running the Server Cleanup Wizard, then you'll also want to defrag the filesystem and run the DB Maintenance script.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, September 6, 2012 1:29 AM
    Moderator
  • This machine does not have proxy setup nor is it using it.

    I am down to 27944 updates total after a server cleanup.  It is still on the order of 127gb though!

    This was a fresh install, however I tried to migrate the info from the old server initially.  This did not work so well, so I ended up having the WSUS data download from WU over the course of a weekend.

    This could be rather time consuming, but I will go through and manually look at the superseded updates.

    One other item to note, I can patch the server by going to Windows Update directly.  However, if I check for updates via the link in the start menu, I get the error code of 80072efe.  Not sure if this gives any more clues, but thought I would mention it.


    Computer Systems Specialist

    Thursday, September 6, 2012 1:04 PM
  • I am down to 27944 updates total after a server cleanup.

    My first guess is that you erroneously configured the Update Classification "Drivers". Since this was a fresh install, and if "Drivers" is selected, I suggest you rebuild the server from scratch, don't select "Drivers", but do select every other classification -- and be very selective in the product categories you select.

    The second part of that process is being very judicious in the updates you select for approval. A typical WSUS server servicing servers (2003, 2008, 2008R2) and desktops (XP, 7), plus a couple versions of Office and most server applications -- will generate around 5,000 updates, and the typical number of updates that would be approved is in the 10% range of total number of updates.

    It is the large number of updates plus the large number of approvals that is causing the timeout errors. This is well documented behavior in this forum and a quick search on the keyword 'timeout' will pull up dozens of threads on the topic over the past year or so.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, September 6, 2012 2:43 PM
    Moderator
  • I was afraid you were going to say that.  5,000 or so updates is right around what we had on the old server. There is a LOT of stuff on this server, is there anyway to undo the damage that has been done without doing a fresh install?  It's at least a weeks worth of work to install and configure :(

    Computer Systems Specialist

    Thursday, September 6, 2012 5:24 PM
  • is there anyway to undo the damage that has been done without doing a fresh install?  It's at least a weeks worth of work to install and configure

    I'm not quite sure I'm grasping the week's worth of work to install and configure....

    But, yes, there are a couple of ways you could clean this up that we've talked about in this forum as this conversation comes up -- but none of them are pretty.

    • The first thing you could definitely do, at a minimum, is find all of those driver updates and decline them. However, given that the machine is already producing timeouts, this isn't going to be easy. First you'll want to create a custom view for just "Drivers", and then you'll need to select small amounts, at first, small enough that the Decline operation can complete without experiencing a timeout.However, given that you have 30k updates and 26k are approved, it stands to reason that most of those approvals are actually those driver updates that probably should have never been approved to begin with (or synchronized, for that matter). It's entirely possible that by declining the updates you can resolve the timeout issue -- for a while. But the presence of those updates in the table, even though declined, are still going to have an impact on queries that join/filter on the updates table.
    • The second thing you could do is write a program to call the update delete method via the WSUS API. (There may also be delete utilities already available on the web for exactly this purpose, but I'm not personally aware of any I can point directly at.)
    • There are also third party products designed to enhance WSUS and provide additional functionality -- such as deleting updates. SolarWinds Patch Manager is one such product. (Note: I am a product manager for SolarWinds.)

    And then... now that I'm actually thinking outside of the box.. (I been doin a lot of that this week; some interesting things have come out of this) ... here's a creative options that might work -- but I've never tested it -- heck, I just thought of it 10.7seconds ago....

    Unselect "Drivers" in the Update Classifications of the current server.

    Create a replica server of this upstream server and synchronize. Inspect whether the Drivers updates were synchronized. It's possible that since Drivers have been turned off at the upstream server, that a brand new replica will not synchronize the Drivers updates, since it also replicates Products and Classifications. It's also possible it will ignore Products and Classifications and just synchronize everything. If it synchronizes everything then the experiment was a failure and the above options are all you got.

    If it doesn't synchronize Drivers, then you just hit the motherlode. Let the sync and content transfer finish, then trash the original upstream server completely. Reinstall your permanent server as a replica of this new temporary replica, and replicate again, and now you should have a server on the original system sans Drivers, approvals for Drivers, and the installation files that were downloaded for those approved Driver updates. Reconfigure the perm server as an upstream server and sync with Microsoft.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin




    Friday, September 7, 2012 11:49 PM
    Moderator
  • Sorry I didn't get back to you Lawrence, I was pushed onto another project.  The reason I didn't want to reload the server is because we have multiple applications on it that require lengthy setup.

    I did go through and decline the driver updates, at least things look better, but I see your point with the table size still being the same.

    Your last idea there makes a TON of sense to me, I think after I figure out why updates aren't applying to the server, I'll definitely give that a shot.  I will report back with my findings.

    Thanks!


    Computer Systems Specialist

    Thursday, October 11, 2012 7:43 PM
  • The reason I didn't want to reload the server is because we have multiple applications on it that require lengthy setup.

    And now we all understand the value of one APP - one SERVER. :-)

    Your last idea there makes a TON of sense to me, I think after I figure out why updates aren't applying to the server, I'll definitely give that a shot.

    Unfortunately, compliments of another thread on a similar conversation, we have learned that this process will not work. Even if you deselect the Drivers classification, the updates will still replicate, they'll just be hidden from the console because they're not 'selected'. (And this brings back memories of a conversation I had with a WSUS Program Mgr way back when that updates were always synchronized, just not displayed according to the product/classification settings. That is to say, calling them "Synchronization Settings" is misleading, because actually they are "Console Filter Settings".


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Saturday, October 13, 2012 1:43 AM
    Moderator