locked
Client Error 8024400E when trying to sync to WSUS 3.1 (SP1) RRS feed

  • Question

  • Hi,
    I recently have found that one of my clients (Windows 2003 Server SP2, which is a member server) has stopped reporting in to the WSUS server.  I checked the windowsupdate.log and found that the dreaded 8024400E error has occured.

    So far I have:-

    i)    Renamed the softwareupdates folder (after stopping and starting the update service) - No fix
    ii)    Deleted the HKLM registry key and run the resetauthorization switch on wuauclt. - No Fix
    iii)    Downgraded the WU agent to version 2 and then let it update manually. - No Fix.

    I am now at a loss as to how to fix this.  Anyone got any ideas as I would rather not rebuild this machine to make this work.

    PS.  It will connect to the Internet correctly and download and patch the machine, so that portion of the system works.

    Nathan.
    Thursday, June 19, 2008 11:18 AM

Answers

  • I contacted Microsoft about this issue last week. And this is the solution they came with:

    Perform the following steps:

    a. First make sure the update is declined.
    If the update is not yet declined, right click on the update and decline it.

    b. Next, approve the update.
    Right click on the update and select the ‘Approve…’ option in the context menu. In the ‘Approve Updates’ dialog that opens, just click ‘OK’. Dismiss the ‘Approval Progress’ dialog that appears.

    c. Next, decline the update.
    Right click on the update and select the ‘Approve…’ option in the context menu. In the ‘Approve Updates’ dialog that opens, just click ‘OK’. Dismiss the ‘Approval Progress’ dialog that appears.

    I tried it, and now the server starts reporting.

    Monday, June 23, 2008 9:00 AM
  • The issue discussed in this thread . . . from 2008!!! . . . directly relates to a specific known flaw in the original Office 2003 Service Pack 1 update package, which is thoroughly documented in KB954960 and this WSUS Support Team Blog Post (June 2008), and is essentially a dead issue, except for any legacy WSUS servers that have been in existence since before August, 2008 that were not properly patched with KB954960 and/or not yet updated to Service Pack 2 (released August 2009).

    Changing security permissions on the %TEMP% folders, specifically granting Everyone permissions is not an appropriate fix for anything, and I highly suspect that your particular instance of an 0x8024400E error has absolutely nothign to do with the issue encountered in the summer of 2008, or the specific fix identifed in this thread.

    I would encourage you to remove the Everyone permissions from your %TEMP% folder, properly verify the server prerequisites for your WSUS installation(s), as documented in the WSUS Deployment Guide, and if everything is configured correctly, then start a NEW thread, document your exact scenario(s) and observations, and we can work on an appropriate identification of your problem and the correct solution(s).

    Removing access restrictions is **NEVER** an appropriate solution to a software problem. In fact, it becomes an open invitation to yet more problems down the road.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by ninja1701d Thursday, September 15, 2011 8:28 AM
    Monday, April 18, 2011 4:39 PM

All replies

  •  Just letting you know, I have the same problem over here. Please let me know if you have a solution. I tried several thing:

    - Installing the Windows Update Agent manually
    - Stop "Automatic Updates" service, delete the content of c:\windows\softwaredistribution, delete SusID from registry, start "Automatic Updates"

    Problem still exist, unfortunatly.
    Monday, June 23, 2008 8:22 AM
  • I contacted Microsoft about this issue last week. And this is the solution they came with:

    Perform the following steps:

    a. First make sure the update is declined.
    If the update is not yet declined, right click on the update and decline it.

    b. Next, approve the update.
    Right click on the update and select the ‘Approve…’ option in the context menu. In the ‘Approve Updates’ dialog that opens, just click ‘OK’. Dismiss the ‘Approval Progress’ dialog that appears.

    c. Next, decline the update.
    Right click on the update and select the ‘Approve…’ option in the context menu. In the ‘Approve Updates’ dialog that opens, just click ‘OK’. Dismiss the ‘Approval Progress’ dialog that appears.

    I tried it, and now the server starts reporting.

    Monday, June 23, 2008 9:00 AM
  • Hi,

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

    If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish.

    In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

    Thanks!
    --------------------
    Regards,
    Eric Zhang

    Wednesday, June 25, 2008 9:35 AM
  • Here is what has worked for me 100% of the time.

     

    Apply 'Everyone' full control to the C:\windows\temp folder and voila


    This is driven because the WSUS server won't start on 2003, 2008, 2008 R2

    Get's an online error and the clients get the

    8024400E error.


    D-B-S
    Monday, April 18, 2011 1:39 PM
  • The issue discussed in this thread . . . from 2008!!! . . . directly relates to a specific known flaw in the original Office 2003 Service Pack 1 update package, which is thoroughly documented in KB954960 and this WSUS Support Team Blog Post (June 2008), and is essentially a dead issue, except for any legacy WSUS servers that have been in existence since before August, 2008 that were not properly patched with KB954960 and/or not yet updated to Service Pack 2 (released August 2009).

    Changing security permissions on the %TEMP% folders, specifically granting Everyone permissions is not an appropriate fix for anything, and I highly suspect that your particular instance of an 0x8024400E error has absolutely nothign to do with the issue encountered in the summer of 2008, or the specific fix identifed in this thread.

    I would encourage you to remove the Everyone permissions from your %TEMP% folder, properly verify the server prerequisites for your WSUS installation(s), as documented in the WSUS Deployment Guide, and if everything is configured correctly, then start a NEW thread, document your exact scenario(s) and observations, and we can work on an appropriate identification of your problem and the correct solution(s).

    Removing access restrictions is **NEVER** an appropriate solution to a software problem. In fact, it becomes an open invitation to yet more problems down the road.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    • Marked as answer by ninja1701d Thursday, September 15, 2011 8:28 AM
    Monday, April 18, 2011 4:39 PM