none
Windows Server 2008 machines failing with 0x8024400a and not reporting in WSUS

    Question

  • I am a new systems engineer at a company with around 100 servers, mostly W2k8 environment. We have a WSUS server, version 3.2.7600.226, that runs on W2k8 R2 with IIS 7. I have been reconfiguring WSUS and ran into a major issue where half of the servers are not reporting with WSUS. The others report and update fine. I am receiving a 0x8024400a error on each of the troublesome machines. From deep research, I have found this error to be a parsing issue with IIS 6 on W2k3 machines, which was resolved with a hotfix, but that is not the fix for me. Here are the steps I have taken:

    On WSUS server:

    1. Disabled compression in IIS for WSUS.

    On client:

    1. Stopped WU and BIT services.

    2. Deleted SusClientId's in registry.

    3. Re-registered wuweb.dll, wuwebv.dll, wups.dll, wups2.dll, wucltux.dll, wuaueng.dll, wuapi.dl, wuapi.dll

    4. Reinstalled Windows Update agent per http://support.microsoft.com/kb/949104

    5. Removed contents from C:\Windows\SoftwareDistribution directory.

    6. Restarted WU and BIT services.

    7. Ran wuauclt.exe /detectnow /resetauthorization.

    After some time, the SusIDs reset on the client, which indicates to me that it's talking to WSUS. They never report to WSUS, however, and checking for new updates on the client reports this WindowsUpdate.log:

    2012-05-09    14:01:12:863     896    1070    PT    WARNING: SyncUpdates failure, error = 0x8024400A, soap client error = 10, soap error code = 0, HTTP status code = 200
    2012-05-09    14:01:12:863     896    1070    PT    WARNING: PTError: 0x8024400a
    2012-05-09    14:01:12:863     896    1070    PT    WARNING: SyncUpdates_WithRecovery failed.: 0x8024400a
    2012-05-09    14:01:12:863     896    1070    PT    WARNING: Sync of Updates: 0x8024400a
    2012-05-09    14:01:12:863     896    1070    PT    WARNING: SyncServerUpdatesInternal failed: 0x8024400a
    2012-05-09    14:01:12:863     896    1070    Agent      * WARNING: Failed to synchronize, error = 0x8024400A
    2012-05-09    14:01:12:863     896    1070    Agent      * WARNING: Exit code = 0x8024400A
    2012-05-09    14:01:12:863     896    1070    Agent    *********
    2012-05-09    14:01:12:863     896    1070    Agent    **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2012-05-09    14:01:12:863     896    1070    Agent    *************
    2012-05-09    14:01:12:863     896    1070    Agent    WARNING: WU client failed Searching for update with error 0x8024400a
    2012-05-09    14:01:12:863     896    cc0    AU    >>##  RESUMED  ## AU: Search for updates [CallId = {68597DA3-168D-4FB6-9ACD-D1667E84A0EF}]
    2012-05-09    14:01:12:863     896    cc0    AU      # WARNING: Search callback failed, result = 0x8024400A
    2012-05-09    14:01:12:863     896    cc0    AU      # WARNING: Failed to find updates with error code 8024400A
    2012-05-09    14:01:12:863     896    cc0    AU    #########
    2012-05-09    14:01:12:863     896    cc0    AU    ##  END  ##  AU: Search for updates [CallId = {68597DA3-168D-4FB6-9ACD-D1667E84A0EF}]
    2012-05-09    14:01:12:863     896    cc0    AU    #############
    2012-05-09    14:01:12:863     896    cc0    AU    Successfully wrote event for AU health state:1
    2012-05-09    14:01:12:863     896    cc0    AU    AU setting next detection timeout to 2012-05-10 00:01:12
    2012-05-09    14:01:12:863     896    cc0    AU    Setting AU scheduled install time to 2012-05-10 08:00:00
    2012-05-09    14:01:12:863     896    cc0    AU    Successfully wrote event for AU health state:1
    2012-05-09    14:01:12:863     896    cc0    AU    Successfully wrote event for AU health state:1
    2012-05-09    14:01:12:956     896    1070    Report    Uploading 1 events using cached cookie, reporting URL = http://wsusservername:8050/ReportingWebService/ReportingWebService.asmx
    2012-05-09    14:01:20:710     896    1070    Report    Reporter successfully uploaded 1 events.
    2012-05-09    14:01:20:710     896    1070    Report    REPORT EVENT: {42E09A35-4275-4C1C-96DB-201B52E41056}    2012-05-09 14:01:12:863-0500    1    148    101    {00000000-0000-0000-0000-000000000000}    0    8024400a    AutomaticUpdates    Failure    Software Synchronization    Windows Update Client failed to detect with error 0x8024400a.
    2012-05-09    14:01:20:741     896    1070    Report    CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2012-05-09    14:01:20:741     896    1070    Report    WER Report sent: 7.5.7601.17514 0x8024400a 00000000-0000-0000-0000-000000000000 Scan 101 Managed
    2012-05-09    14:01:20:741     896    1070    Report    CWERReporter finishing event handling. (00000000)

    I'm out of ideas and turn here for assistance. Please let me know if you need further info from me. Thank you in advance.

    Wednesday, May 09, 2012 8:42 PM

Answers

  • Hi,

    I am inclined to refer to this issue as a duplicate SusClientID.I encountered this issue like this before. The necessary procedure is documented in KB903262.
    For more reference: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

    As you said,after some time, the SusIDs reset on the client, which indicates to me that it's talking to WSUS.Did you test for patch deployment?Make sure that clients are reaching the detection cycle.

    Another possible issue I also found is that you set (http://wsusservername:8050). The official documents indicate it should be 8530(If 80 is used.) Pls don't use any other ports to see whether it works.



    Best regards,

    Clarence

    Forum Support
    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 Subscriber Support, contacttnmff@microsoft.com.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.





    Thursday, May 10, 2012 7:22 AM
    Moderator

All replies

  • Hi,

    I am inclined to refer to this issue as a duplicate SusClientID.I encountered this issue like this before. The necessary procedure is documented in KB903262.
    For more reference: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

    As you said,after some time, the SusIDs reset on the client, which indicates to me that it's talking to WSUS.Did you test for patch deployment?Make sure that clients are reaching the detection cycle.

    Another possible issue I also found is that you set (http://wsusservername:8050). The official documents indicate it should be 8530(If 80 is used.) Pls don't use any other ports to see whether it works.



    Best regards,

    Clarence

    Forum Support
    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 Subscriber Support, contacttnmff@microsoft.com.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.





    Thursday, May 10, 2012 7:22 AM
    Moderator
  • I am receiving a 0x8024400a error on each of the troublesome machines.

    Typically the 0x8024400a error is rarely encountered, but it means:

    SOAP client failed to parse the response from the server.

    Either the data coming back is defective, or the client cannot deal with it. Fundamentally the server should be returning well-formed *XML*, but if the server is returning *HTML* this will be problematic.

    Where this issue has been encountered previously, it has been traced to one of two root causes:

    1. Installation defects of WSUS on Win2003/IIS6. Remediation: Uninstall/reinstall WSUS in accordance with published documentation.
    2. Corrupted client-side datastore: Remediations: Stop service; delete SoftwareDistribution folder; start service, =or= Reinstall Windows Update Agent.

    Inasmuch as this issue is occurring on several machines, that tends to rule out a client-side datastore issue, and you should focus your efforts on the WSUS server.

    We don't have any empirical data for this error on Win2008 systems, and only one other (unresolved) issue posted in this forum -- but I would focus on the installation and configuration of the Web Server role as the starting place. Review the WSUS Deployment Guide and confirm that the Web Server role is installed in exactly the configuration specified. Also, are there any other web-based apps or services installed on the WSUS server? Sometimes these can cause conflicts (by reconfiguring the Web Server role, or changing access rights).


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

    Thursday, May 10, 2012 10:29 PM
    Moderator
  • Hey,

    I got excactly the same error. Windows 2008 R2 Server and two Win7-32 Bit Clients. I tried all the solutions K_Mart posted before but got just the same WindowsUpdate.log. 168 Clients are done without a problem, just two now with this error.  Any other solutions?

    Greetings

    Friday, May 11, 2012 10:49 AM
  • I believe I found  my issue and it was indeed port related. I changed the port to 8530, updated the GPO and all the servers are now checking in. I still don't understand why only some of them were troublesome but it's resolved and that's all that matters! Thanks, Clarence. I was banging my head on my desk for a few days over this. :)
    Friday, May 11, 2012 3:59 PM
  • Check your WSUS port setting and make sure it's the default 8530. That was my issue.
    Friday, May 11, 2012 4:00 PM
  • I believe I found  my issue and it was indeed port related. I changed the port to 8530, updated the GPO and all the servers are now checking in. I still don't understand why only some of them were troublesome but it's resolved and that's all that matters! Thanks, Clarence. I was banging my head on my desk for a few days over this. :)

    Wow! This is significant. Setting the wrong port on the URL should return an HTTP 404 error!

    This one goes in the significant notes book.

    Thank you for taking the time to post back your resolution. Now it makes me wonder how many 0x8024400A errors we "over analyzed" when it was just a bad port configuration. :-//


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

    Tuesday, May 15, 2012 1:23 AM
    Moderator
  • we changed our port to 80, and 169 clients are reporting perfectly. I know I wrote 168 some posts before but during the last week while I wasn't at work one of the two clients just started reporting without doing anything before. Don't know why..

    So just 1 client to go...

    Just tried something: I changed the WSUS for this one, just told him to report to the old one we used before. It worked! The old WSUS was port 8530, the new one 80.

    Monday, May 21, 2012 10:16 AM