Updates fail to download. WindowsUpdate.log file shows hr = 8024401b

BatchPatch Forums Home Forums BatchPatch Support Forum Updates fail to download. WindowsUpdate.log file shows hr = 8024401b

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #9134
    doug
    Moderator

    If BatchPatch reports that updates are failing to download, and in the WindowsUpdate.log file (C:WindowsWindowsUpdate.log) on the target computer reports 8024401b, then you’re dealing with a proxy authentication issue.

    0x8024401BL WU_E_PT_HTTP_STATUS_PROXY_AUTH_REQ Same as HTTP status 407 – proxy authentication is required

    The simplest way to solve this problem is to whitelist the Microsoft Update / Windows Update domains so that connections to these domains are made directly instead of through your proxy.

    More information is available here: https://support.microsoft.com/kb/885819

    The domains to whitelist are:

    http://download.windowsupdate.com

    http://*.download.windowsupdate.com

    http://download.microsoft.com

    https://*.update.microsoft.com

    http://*.update.microsoft.com

    https://update.microsoft.com

    http://update.microsoft.com

    http://*.windowsupdate.com

    http://*.windowsupdate.microsoft.com

    http://windowsupdate.microsoft.com

    https://*.windowsupdate.microsoft.com

    http://ntservicepack.microsoft.com

    http://wustat.windows.com

    If you are using a wpad.dat file to configure your computers’ proxy settings, you can use the following syntax in the wpad.dat file to whitelist the Microsoft domains:

    if ( shExpMatch ( url, “*.download.windowsupdate.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.download.microsoft.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.update.microsoft.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.windowsupdate.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.download.windowsupdate.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.windowsupdate.microsoft.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.ntservicepack.microsoft.com/*”) ) { return “DIRECT”; }

    if ( shExpMatch ( url, “*.wustat.windows.com/*”) ) { return “DIRECT”; }

    #11479
    atesser
    Participant

    I’m really grateful that you proactively start topics which might affect your user base; thank you. I have a question which pertains to this error:

    All of my systems are configured to check in with a WSUS server on our network. I’m trying to figure out why the proxy would even come in to play in this scenario. Is there a reason that a system which is configured to connect to a local WSUS server would still need access to the internet via our proxy?

    #11480
    doug
    Moderator

    I’m not sure. I think it’s the case that the Windows Update Agent still attempts to make some calls to Microsoft, even though update searching and downloading will come from your local WSUS. To be sure, you can/should confirm this behavior in the WindowsUpdate.log.

    My best guess as to what happens is that under normal circumstances with no proxy in the picture, if the Windows Update Agent attempts to reach out to Microsoft’s servers (as part of it’s normal processing even though it will search for and download updates on your local WSUS) but fails to reach those Microsoft servers, it just fails gracefully and moves on to the next step since the update searching and downloading will be from the local WSUS and not from Microsoft’s public servers. However, perhaps in the case where a proxy is involved, when the Windows Update Agent reaches out to Microsoft’s server, instead of failing gracefully/silently and moving on to the next step, instead it hits the proxy authentication issue and throws an exception and stops processing.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.