locked
WSUS errors, Event ID: 364 and 10032. Updates not being pushed out to workstations/servers RRS feed

  • Question

  • WSUS system has been working fine for years, then about 3 months ago, workstations and servers stopped getting updates. They check in, but do not download released/applied updates.

    Been getting these errors in the even log.  File name varies. I've tried removing updates to be applied, deleting the downloads, etc, but new ones keep popping up.  Below are the 2 errors that keep occurring.

    Log Name:      Application
    Source:        Windows Server Update Services
    Date:          1/23/2020 9:13:44 PM
    Event ID:      364
    Task Category: 2
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ServerXXX.domainx.com
    Description:
    Content file download failed. Reason: File cert verification failure. Source File: /c/msdownload/update/software/secu/2019/10/windows6.1-kb4519976-x64_61f61f41acfac051d4d3446d1fda80dd70c2bf99.psf

    Log Name:      Application
    Source:        Windows Server Update Services
    Date:          1/23/2020 9:06:52 PM
    Event ID:      10032
    Task Category: 7
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ServerXXX.domainx.com
    Description:The server is failing to download some updates.

    Friday, January 24, 2020 4:40 PM

All replies

  • 1. Check the trust chain of the cert which signs the update. Its root cert should be Microsoft Root Certificate Authority 2010 or 2011, check if it is expired. It should be updated with the OS updates. Is your WSUS server patched to the latest? You also could export them from another working device then import them to your WSUS server.
     
    2. Another possible reason is that your server may not support the Sha-2 signature yet. Refer to the following link and install the update for your OS then check again.
    https://support.microsoft.com/en-sg/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus
     
    Saturday, January 25, 2020 11:00 AM
  • Reviewing the certificates, I don't see the ones you refer to have expired. Perhaps I'm not looking at the correct certificate, I looked under "Trusted Root Certification Authorities"  The 2010 certificate expires in 2035 and the 2011 expires in 2036.

    I reviewed the link you sent and download patch KB4474419, installed and rebooted.  The same 10032 error appeared in the error logs and my workstations still do not recognize the released patches and download, even though WSUS shows the workstation checking in.

    Any other thoughts?


    • Edited by R Manske Monday, January 27, 2020 11:05 PM
    Monday, January 27, 2020 11:05 PM
  • Hi R.Manske,
       

    Note that your WSUS server may be located on Windows Server 2008 R2 SP1, please consider checking from the perspective of SHA-2 code signing support first:
       

    1. Ensure that all Windows 7 SP1 and Windows Server 2008 R2 SP1 WSUS clients have KB4474419 and KB4490628 installed to introduce SHA-2 code signing support.
    2. Ensure that the WSUS server has KB4484071 installed to support the delivery of SHA-2 signed updates.
        

    Also note that for products based on Windows Server 2008 R2 Service Pack 1, support for this product has ended on January 14, 2020, please consider updating your product.
    Hope the above can help you.
       

    Regards,
    Yic

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 28, 2020 1:39 AM
  • Both KB4474419 and KB4490628 are installed to the workstations.

    I applied KB4484071 to the WSUS server.  Same results, workstations check in but do not download and apply the patches.

    What else can I check?

    Wednesday, January 29, 2020 7:45 PM
  • Hi,
      

    This problem may be caused by two potential root causes, please refer to the following steps to verify separately:
      

    1. Certificate chain issues
      The problem caused by the current root certificate or local publishing certificate not being installed correctly. If the computer can connect directly to the Windows Update site environment, it will receive updated certificate trust lists (CTL) every day.
      If not, please refer to the methods mentioned in the following two articles for obtaining:
      - "Configure a file or web server to download the CTL files"
      - "An automatic updater of untrusted certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2"
        
    2. File issues
      File corruption during transfer, or file was corrupt on WSUS USS. Please try the following steps to fix it:
      1) Reject approved updates.
      2) Close any open WSUS consoles.
      3) Go to Administrative Tools – Services and STOP the Update Services service.
      4) In Windows Explorer browse to the WSUSContent folder (typically D:\WSUS\WSUSContent or C:\WSUS\WSUSContent)
      5) Delete ALL the files and folders in the WSUSContent folder.
      6) Go to Administrative Tools – Services and START the Update Services service.
      7) Open a command prompt and navigate to the folder: C:\Program Files\Update Services\Tools.
      8) Run the command WSUSUtil.exe RESET

      You can check the SoftwareDistribution.log(C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log), When you start the reset process, you should see a line towards the bottom of the log which looks like this:
      WsusService.13  ExecutionContext.runTryCode  State Machine Reset Agent Starting
        
      After waiting for some time, check the log again and search for the text "State Machine Reset Agent Finished":
      - WsusService.13  ExecutionContext.runTryCode  State Machine Reset Agent Finished
          

    Hope the above can help you.
      

    Regards,
    Yic

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 30, 2020 1:23 AM