locked
Clients Unable to Update from WSUS - 80072EE2 RRS feed

  • Question

  • We are running WSUS 3.0 SP2 on Windows Server 2008 R2. This is patched with the latest updates that were released in July. The hardening update (KB2938066) has been installed on this server since September 2014. The following issue appears to have started within the recent months.

     

    We are finding clients are unable to update from WSUS due to error code 80072EE2. However, some clients appear to be patching without issue. We've not been able to establish a pattern for this. What we do see, is that clients which require a large amount of updates (e.g. a fresh install from Windows 7 SP1 ISO) are essentially guaranteed to fail. It is worth noting that these clients have the April servicing stack update installed, and also the July Windows 7 update rollup, which should include the latest Windows Update agent.

     

    The server cleanup wizard has been run successfully a number of times followed by database re-indexing using the usual best practice script. We can confirm there is no fragmentation in the WSUS DB at this time. The DB is running on a SQL Server.

     

    Looking at server manager for the WSUS server role, we do see Error 12032 11 times every 24 hours.

    • The Server Synchronization Web Service is not working.

     

    Using adsutil.vbs as per https://technet.microsoft.com/en-us/library/dd939903(v=ws.10).aspx (i.e. adsutil.vbs enum W3SVC/1/ROOT/ServerSyncWebService) reveals that the virtual directory appears to be configured properly. This WSUS server is essentially standalone and is feeding nor being fed by other WSUS servers, so to our knowledge, even if this aspect of WSUS wasn't 100% healthy, it may not matter.

     

    Within the SoftwareDistribution.log file we do see entries like the below quite frequently:

    Warning        w3wp.26        DBConnection.OnReceivingInfoMessage        Invalid event dropped. EventInstanceID=BLABLABLA, ComputerID=BLABLABLA. Invalid EventID.

     

    The logs within C:\Logs\W3SVC1 highlight no errors, just HTTP what reads as normal traffic between WSUS and the clients.

    We are also seeing the following ASP.NET 2.0.50727.0 Event 1309 :

     

    Event code: 3001

    Event message: The request has been aborted.

    Event time: 04/08/2016 06:08:16

    Event time (UTC): 04/08/2016 05:08:16

    Event ID: 2cb6f85972754588b603f67106908d85

    Event sequence: 752

    Event occurrence: 1

    Event detail code: 0

     

    Application information:

        Application domain: /LM/W3SVC/1/ROOT/ClientWebService-1-131147607756847886

        Trust level: Full

        Application Virtual Path: /ClientWebService

        Application Path: C:\Program Files\Update Services\WebServices\ClientWebService\

        Machine name: PRIVATE

     

    Process information:

        Process ID: 1988

        Process name: w3wp.exe

        Account name: NT AUTHORITY\NETWORK SERVICE

     

    Exception information:

        Exception type: HttpException

        Exception message: Request timed out.

     

    Request information:

        Request URL: http://revmoedforprivacy.com/ClientWebService/client.asmx

        Request path: /ClientWebService/client.asmx

        User host address: <removed for privacy>

        User: 

        Is authenticated: False

        Authentication Type: 

        Thread account name: NT AUTHORITY\NETWORK SERVICE

     

    Thread information:

        Thread ID: 19

        Thread account name: NT AUTHORITY\NETWORK SERVICE

        Is impersonating: False

        Stack trace: 

     

    Wondered if anyone had any insight or suggestions? I'm wondering if we should increase the memory on the WSUS application pool.


    Update #1: From within Task Manager, I enabled the column 'Command Line' within the Processes tab and found the w3wp.exe running the WSUS app pool. I then observed that within about 10 minutes it hits the memory limit assigned to the app pool, and then the process gets terminated. This appears to be due to the Application Pool Recycling Conditions settings. It is set to recycle when the memory usage matches max memory limit assigned to the pool. I'm going to increase the memory and see if this improves the situation.

    • Edited by Kirk Watts Thursday, August 4, 2016 1:01 PM Updated with new findings
    Thursday, August 4, 2016 11:24 AM

Answers

  • Hi Anne,

    We've increased the RAM on the VM which hosts our WSUS service. Following this, we've increased the memory for the application pool to 4GB. Things appear to be much more stable now. Clients that were previously not updating, have now started to pull down updates. Fingers crossed, that should be the end of this issue. Hopefully this information will help out somebody else in the future.

    Kirk

    • Marked as answer by Kirk Watts Friday, August 5, 2016 9:37 AM
    Friday, August 5, 2016 9:37 AM

All replies

  • Hi Kirk Watts,

    We are still doing research about this issue and monitoring your update.

    We'll post back as soon as we got any process.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Friday, August 5, 2016 9:32 AM
  • Hi Anne,

    We've increased the RAM on the VM which hosts our WSUS service. Following this, we've increased the memory for the application pool to 4GB. Things appear to be much more stable now. Clients that were previously not updating, have now started to pull down updates. Fingers crossed, that should be the end of this issue. Hopefully this information will help out somebody else in the future.

    Kirk

    • Marked as answer by Kirk Watts Friday, August 5, 2016 9:37 AM
    Friday, August 5, 2016 9:37 AM
  • Hi Kirk Watt,

    Glad to hear it! And thanks for sharing the solution with us.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Friday, August 5, 2016 9:44 AM