none
Client Updates Failing - WindowsUpdate.log 0x80244004

    Question

  • Hi guys, I have an issue with one of my secondary site servers, it is failing to install updates via the SUP;

    WindowsUpdate.log shows:

    2013-02-13 20:42:04:786  912 ac0 PT WARNING: GetConfig failure, error = 0x80244004, soap client error = 4, soap error code = 0, HTTP status code = 200
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: PTError: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: GetConfig_WithRecovery failed: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: RefreshConfig failed: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: RefreshPTState failed: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: Sync of Updates: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 PT WARNING: SyncServerUpdatesInternal failed: 0x80244004
    2013-02-13 20:42:04:786  912 ac0 Agent   * WARNING: Failed to synchronize, error = 0x80244004
    2013-02-13 20:42:04:786  912 ac0 Agent   * WARNING: Exit code = 0x80244004

    WUAHandler.log shows:

    Scan results will include superseded updates only when they are superseded by service packs and definition updates. WUAHandler 13/02/2013 20:50:32 5304 (0x14B8)
    Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler 13/02/2013 20:50:32 5304 (0x14B8)
    Async searching of updates using WUAgent started. WUAHandler 13/02/2013 20:50:32 5304 (0x14B8)
    Async searching completed. WUAHandler 13/02/2013 20:50:32 1484 (0x05CC)
    OnSearchComplete - Failed to end search job. Error = 0x80244004. WUAHandler 13/02/2013 20:50:32 5304 (0x14B8)
    Scan failed with error = 0x80244004. WUAHandler 13/02/2013 20:50:32 5304 (0x14B8)

    Other machines in the hierarchy are using the SUP without issue as we move them into the SCCM environment. Note that this server was managed by another WSUS server for its own updates.

    I have performed the following actions on the server itself:

    • Reset SoftwareDistribution folder
    • Confirmed that there is no proxy settings via netsh winhttp show proxy
    • Enforced no proxy setting using bitsadmin for local system/network service
    • Tried re-installing the agent using /wuforce switch
    • Reset WSUS authorisation (/resetauthorization)

    If you have any suggestions let me know...

    Thanks,

    Chris


    MCTS 70-640 | MCTS 70-642 | Prince2 Practitioner| ITIL Foundation v3 | http://www.cb-net.co.uk

    Wednesday, February 13, 2013 8:59 PM

Answers

  • So as it turns out it was a legacy ISA web filter solution that was causing this issue; I ran a WireShark trace and saw there were the following errors every time I ran an update scan/tried to install a detected update:

    502 Proxy Error. The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port.

    I found that there is a legacy 'wpad' entry in DNS that machines are picking up and auto-configuring themselves with; despite ensuring that netsh winhttp proxy was set to direct, and using the bitsadmin tool I have disabled the proxy configuration.

    We still need the DNS entry so the solution was to enable HTTPS on 8531 (ISA specific as it will only allow HTTPS traffic on port 443 by default) and create a rule to permit the access.

    All of the affected clients (~75% of all COnfigMgr clients) sprang to life the following day.


    MCTS 70-640 | MCTS 70-642 | Prince2 Practitioner| ITIL Foundation v3 | http://www.cb-net.co.uk

    Friday, March 1, 2013 10:33 AM

All replies

  • So as it turns out it was a legacy ISA web filter solution that was causing this issue; I ran a WireShark trace and saw there were the following errors every time I ran an update scan/tried to install a detected update:

    502 Proxy Error. The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port.

    I found that there is a legacy 'wpad' entry in DNS that machines are picking up and auto-configuring themselves with; despite ensuring that netsh winhttp proxy was set to direct, and using the bitsadmin tool I have disabled the proxy configuration.

    We still need the DNS entry so the solution was to enable HTTPS on 8531 (ISA specific as it will only allow HTTPS traffic on port 443 by default) and create a rule to permit the access.

    All of the affected clients (~75% of all COnfigMgr clients) sprang to life the following day.


    MCTS 70-640 | MCTS 70-642 | Prince2 Practitioner| ITIL Foundation v3 | http://www.cb-net.co.uk

    Friday, March 1, 2013 10:33 AM
  • I know this is an old article, but I just wanted to add a huge "Thank you!" for this article.  While not related to an ISA web filter I was searching all over the place regarding the specific error (0x80244004) I was seeing in the WindowsUpdate.log file along with the "FATAL: SOAP/WinHttp - SendRequest: SSL Cert security check failed. error 0x80072ef3" message and I was banging my head against a wall until I ran across this article.  For me it turned out that we did indeed have a proxy setting configured to point to a WebSense appliance (only noticed this in the WindowsUpdate.log) and found via "netsh winhttp show proxy".  I was able to set a bypass for the address of the SCCM SUP server and the affected clients started checking in.
    Wednesday, March 7, 2018 11:22 PM