locked
Code 8024402C Windows Update ran into a problem RRS feed

  • Question

  • Hi,

    I have SCCM 1906 and WSUS 10.0.12393.2007 on same Win 2016 server.

    A Win2012R2 as a client could update 2 months ago, recently, get "Code 8024402C Windows Update ran into a problem" after I click Check for updates. If I choose "Check online for updates from Windows Update", no any problem, the Windows Update can search some update for the server itself.

    Both Win server have same date and time.

    on Win 2012R2, has Error Event ID 25: Windows Update failed to check for updates with error 0x8024402C. But, on SCCM server, can't see the Error.

    Another Win 2016 as a client no the issue.

    Following a solution, I replace  HKEY_LOCAL_MACHINE\software\polices\microsoft\windows\windowsupdate\au\usewuserver 1 with 0. got same issue. After rebooting the 2012R2 client, I found the usewuserver back to 1.

    How can I fix the issue?



    yxh

    Monday, October 14, 2019 4:54 AM

Answers

  • Hi,

    it seems that in the first policy the WSUS server's name is PS-00 instead of PS-000.


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    • Marked as answer by george yu Friday, October 18, 2019 2:42 PM
    Friday, October 18, 2019 9:10 AM

All replies

  • 0x8024402C - proxy or firewall settings are configured incorrectly

    Check the below KB article

    https://support.microsoft.com/en-in/help/900936/error-code-0x8024402c-when-you-try-to-install-updates-on-windows-updat
    Monday, October 14, 2019 6:59 AM
  • Hi Kalyan,

    Your URL may solve directly update from Internet, my 2012R2 can do it successfully, I already mentioned that above:

    "If I choose "Check online for updates from Windows Update", no any problem, the Windows Update can search some update for the server itself. "

    My problem is that the update through SCCM & WSUS has issue.

    Thank you anyway!


    yxh

    Monday, October 14, 2019 2:28 PM
  • The URL that Kaylan posted isn't meant to give you an explicit solution for your issue but instead to describe your issue as one of network connectivity. Whether you are using ConfigMgr and WSUS or going directly to Windows Update, the Windows Update Agent on the local system is what is controlling the process and it doesn't care which one you are using, it is simply throwing a connectivity related error code because it can't connect to the intended destination.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, October 14, 2019 2:45 PM
  • hello,

    do you have a proxy configured for WINHTTP Service? If yes, you can have problems with updating from WSUS or SCCM.

    Try this command: netsh winhttp show proxy

    If you get a host name or IP address and port instead of "direct access", Windows Update might try to connect to WSUS via the configured proxy, which fails if (as I presume) the server is in your internal network and not in Internet.

    To reset the proxy use: netsh winhttp reset proxy

    Be sure that no other service or application uses WINHTTP service to connect to the Internet before doing this.


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Monday, October 14, 2019 3:04 PM
  • Hi Stefano,

    on 2012R2, following you, put netsh winhttp show proxy on CMD, got:

    Direct access <no proxy server>.

    on the SCCM server 2016, got same result.

    I doubt if the Client software on the 2012R2 has issue, right?

    thank,


    yxh

    Monday, October 14, 2019 3:35 PM
  • Hi,

    The description for the result code 0x8024402C is "ERROR_WINHTTP_NAME_NOT_RESOLVED" - the proxy server or target server name cannot be resolved.

    If the error is correct, this could mean that the machine has the DNS not configured correctly in the network configuration, or that the DNS is not reachable or not functioning. Try "nslookup wsusservername.domain" on the machine to find out if DNS works, and if it can resolve the WSUS server by name. Or, you can configure WSUS using the IP address instead of name (not advisable).


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Tuesday, October 15, 2019 9:22 AM
  • Hi Stefano,

    I checked the DNS on SCCM server, 2016 and 2012R2 by the command you gave above.

    DNS is correct and SCCM server IP and domain name can be resolved correctly on 2012R2:

     

    by the way, I have 2 subnets, and 2012R2 is a DC and DNS server.


    yxh



    • Edited by george yu Tuesday, October 15, 2019 7:26 PM
    Tuesday, October 15, 2019 2:53 PM
  • nslookup is not a valid method test name resolution as name resolution is much more that simply checking whether a record exists in DNS.

    You need to actually perform a test name resolution operation on the client where the issue is being experienced. The fastest and easiest way to do this is to perform a ping of the desired name on the the system having the issue of the name in question.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, October 15, 2019 3:45 PM
  • Hi Jason,

    Ping on the 2012R2 to the SCCM server name and its domain name, event both IPs, no problem!

    thanks,

    george


    yxh

    Tuesday, October 15, 2019 4:59 PM
  • Is the WSUS instance that the server is using hosted on the site server or another site system? If separate, than pining the site server doesn't matter but you instead need to ping the site stem hosting the WSUS instance.

    Have you reviewed the WindowsUpdate.log on this system having issue though?

    Also, just to address some points in your original post:

    Following a solution, I replace  HKEY_LOCAL_MACHINE\software\polices\microsoft\windows\windowsupdate\au\usewuserver 1 with 0. got same issue. After rebooting the 2012R2 client, I found the usewuserver back to 1.

    This is not a solution. All this does is tell the system not to use WSUS which would effectively break update functionality on the system. The local group policy configured by the ConfigMgr agent is correctly setting the value back to 1 as it should be.

    But, on SCCM server, can't see the Error.

    Why would you see an error on the site? The issue is on the client itself.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, October 15, 2019 7:39 PM
  • Hi Jason,

    Thank you so much for your time and help!

    The WSUS and SCCM are on the same 2016 server. So, I always mentioned SCCM instead of WSUS above.

    I checked the WindowsUpdate.log on 2012R2 which has the issue.

    after Clicked "Check for update", the log had records below:

     2019-10-15 19:25:14:109 916 13cc AU Triggering AU detection through DetectNow API
    2019-10-15 19:25:14:109 916 13cc AU Triggering Online detection (interactive)
    2019-10-15 19:25:14:109 916 13cc AU Adding timer: 
    2019-10-15 19:25:14:109 916 13cc AU     Timer: 31DA7559-FE27-4810-8FF6-987195B1FD98, Expires 2019-10-16 01:25:14, not idle-only, not network-only
    2019-10-15 19:25:14:140 916 f0c AU #############
    2019-10-15 19:25:14:140 916 f0c AU ## START ##  AU: Search for updates
    2019-10-15 19:25:14:140 916 f0c AU #########
    2019-10-15 19:25:14:140 916 f0c SLS Retrieving SLS response from server using ETAG "16IMgThQPatW3gLvl1IedEpqN3G7onUum7nRv4bGmwI=_1440"...
    2019-10-15 19:25:14:140 916 f0c SLS Making request with URL HTTPS://sls.update.microsoft.com/SLS/{9482F4B4-E343-43B6-B170-9A65BC822C77}/x64/6.3.9600.0/0?CH=129&L=en-US&P=&PT=0x7&WUA=7.9.9600.19164
    2019-10-15 19:25:14:890 916 f0c EP Got 9482F4B4-E343-43B6-B170-9A65BC822C77 redir SecondaryServiceAuth URL: "117cab2d-82b1-4b5a-a08c-4d62dbee7782"
    2019-10-15 19:25:14:890 916 f0c SLS FATAL: SLS:CSLSRequest::RetrieveAdditionalAttributesIfRequired: CoCreateInstance failed with 0x80040154.
    2019-10-15 19:25:14:890 916 f0c Agent WARNING: Failed to retrieve SLS response data for service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, error = 0x80040154
    2019-10-15 19:25:14:890 916 f0c Agent FATAL: Caller Service Recovery failed to opt in to service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, hr=0X80040154
    2019-10-15 19:25:14:890 916 f0c IdleTmr WU operation (CSearchCall::Init ID 2) started; operation # 21; does use network; is not at background priority
    2019-10-15 19:25:14:890 916 f0c IdleTmr Incremented idle timer priority operation counter to 3
    2019-10-15 19:25:14:890 916 f0c Agent *** START ***  Queueing Finding updates [CallerId = AutomaticUpdatesWuApp  Id = 2]
    2019-10-15 19:25:14:890 916 f0c AU <<## SUBMITTED ## AU: Search for updates  [CallId = {B9692BE2-F43F-43B5-AC9E-383DB5DFE258} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}]
    2019-10-15 19:25:14:890 916 1288 Agent ***  END  ***  Queueing Finding updates [CallerId = AutomaticUpdatesWuApp  Id = 2]
    2019-10-15 19:25:14:890 916 1288 Agent *************
    2019-10-15 19:25:14:890 916 1288 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdatesWuApp  Id = 2]
    2019-10-15 19:25:14:890 916 1288 Agent *********
    2019-10-15 19:25:14:890 916 1288 Agent   * Online = Yes; Ignore download priority = No
    2019-10-15 19:25:14:890 916 1288 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2019-10-15 19:25:14:890 916 1288 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2019-10-15 19:25:14:890 916 1288 Agent   * Search Scope = {Machine & All Users}
    2019-10-15 19:25:14:890 916 1288 Agent   * Caller SID for Applicability: S-1-5-21-156421512-1056530767-81120456-500
    2019-10-15 19:25:14:890 916 1288 Agent   * RegisterService is set
    2019-10-15 19:25:14:890 916 1288 EP Got WSUS Client/Server URL: "http://ps-00.test.com:8530/ClientWebService/client.asmx"
    2019-10-15 19:25:14:890 916 1288 Setup Checking for agent SelfUpdate
    2019-10-15 19:25:14:890 916 1288 Setup Client version: Core: 7.9.9600.19164  Aux: 7.9.9600.18970
    2019-10-15 19:25:14:890 916 1288 EP Got WSUS SelfUpdate URL: "http://ps-00.test.com:8530/selfupdate"
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: Send failed with hr = 80072ee7.
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: Send request failed, hr:0x80072ee7
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://ps-00.test.com:8530/selfupdate/wuident.cab>. error 0x8024402c
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x8024402c
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x8024402c
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x8024402c
    2019-10-15 19:25:14:890 916 1288 Misc WARNING: DownloadFileInternal failed for http://ps-00.test.com:8530/selfupdate/wuident.cab: error 0x8024402c
    2019-10-15 19:25:14:890 916 1288 Setup FATAL: DownloadCab failed, err = 0x8024402C
    2019-10-15 19:25:14:890 916 1288 Setup WARNING: SelfUpdate check failed to download package information, err = 0x8024402C
    2019-10-15 19:25:14:890 916 1288 Setup FATAL: SelfUpdate check failed, err = 0x8024402C
    2019-10-15 19:25:14:890 916 1288 Agent   * WARNING: Skipping scan, self-update check returned 0x8024402C
    2019-10-15 19:25:14:890 916 1288 Agent   * WARNING: Exit code = 0x8024402C
    2019-10-15 19:25:14:890 916 1288 Agent *********
    2019-10-15 19:25:14:890 916 1288 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdatesWuApp  Id = 2]
    2019-10-15 19:25:14:890 916 1288 Agent *************
    2019-10-15 19:25:14:890 916 1288 Agent WARNING: WU client failed Searching for update with error 0x8024402c
    2019-10-15 19:25:14:890 916 1288 IdleTmr WU operation (CSearchCall::Init ID 2, operation # 21) stopped; does use network; is not at background priority
    2019-10-15 19:25:14:890 916 1288 IdleTmr Decremented idle timer priority operation counter to 2
    2019-10-15 19:25:14:890 916 cd4 AU >>##  RESUMED  ## AU: Search for updates [CallId = {B9692BE2-F43F-43B5-AC9E-383DB5DFE258} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}]
    2019-10-15 19:25:14:890 916 cd4 AU   # WARNING: Search callback failed, result = 0x8024402C
    2019-10-15 19:25:14:890 916 cd4 AU #########
    2019-10-15 19:25:14:890 916 cd4 AU ##  END  ##  AU: Search for updates  [CallId = {B9692BE2-F43F-43B5-AC9E-383DB5DFE258} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}]
    2019-10-15 19:25:14:890 916 cd4 AU #############
    2019-10-15 19:25:14:890 916 cd4 AU All AU searches complete.
    2019-10-15 19:25:14:890 916 cd4 AU   # WARNING: Failed to find updates with error code 8024402c
    2019-10-15 19:25:14:890 916 cd4 AU AU setting next detection timeout to 2019-10-16 06:25:14
    2019-10-15 19:25:14:890 916 cd4 AU Adding timer: 
    2019-10-15 19:25:14:890 916 cd4 AU     Timer: 31DA7559-FE27-4810-8FF6-987195B1FD98, Expires 2019-10-16 06:25:14, not idle-only, not network-only
    2019-10-15 19:25:14:937 916 cd4 AU Currently AUX is enabled - so not show any WU Upgrade notifications.
    2019-10-15 19:25:14:937 916 cd4 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
    2019-10-15 19:25:14:937 916 cd4 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037

    Compared with the log in 2016 which can update, no the issue, looks like the issue server started update without through WSUS. How can I fix it?

    Thank you so much again!

    george


    yxh

    Wednesday, October 16, 2019 1:38 AM
  • I can see these error - 80072ee7 and 0x8024402c , Its seomthing related with your network, kindly refer the below blogs

    https://blogs.technet.microsoft.com/sus/2008/09/24/wsus-client-sync-fails-with-80072ee7-and-0x8024402c-errors-in-windowsupdate-log/

    https://www.updatexp.com/0x8024402c.html

    Wednesday, October 16, 2019 7:05 AM
  • Hi Kalyan,

    Thank you for your advice!

    I did what the second URL said, except proxy parts as you know I have no proxy service on my system. Then, Failed.

    Following the first URL, I checked both local and AD GPO setting, looks like no issue. All of them point to http://ps-000.test.com

    ps-000 is WSUS and SCCM server

    Compared the GPO settings on both DC00 which has the issue, looks like there were a little bit difference ( on DC00, more complicated than exchange), please review them below:


    yxh


    • Edited by george yu Thursday, October 17, 2019 3:00 PM
    Thursday, October 17, 2019 2:55 PM
  • Hi,

    it seems that in the first policy the WSUS server's name is PS-00 instead of PS-000.


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    • Marked as answer by george yu Friday, October 18, 2019 2:42 PM
    Friday, October 18, 2019 9:10 AM
  • Hi Stefano,

    you may be correct because I already replaced the WSUS name with WSUS IP address.

    and the issue fixed.

    Thank you so much!


    yxh

    Friday, October 18, 2019 2:41 PM
  • You shouldn't use group policy to configure your WSUS servers when using ConfigMgr. Your exact issue is one example of why.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, October 18, 2019 3:59 PM
  • You shouldn't use group policy to configure your WSUS servers when using ConfigMgr. Your exact issue is one example of why.

    Jason | https://home.configmgrftw.com | @jasonsandys

    You are perfectly right. It seems, however, that the server "EXCHANGE" was not configured by domain policy("winning GPO=Local Group Policy"), when the server "DC00" is.

    I'm wondering if the server "DC00" is a Domain Controller, and as such (usually) not managed via ConfigMgr at all, so they have to use domain policies instead; where at the contrary "EXCHANGE" is managed via ConfigMgr, so its configuration is set by ConfigMgr client and then appears as a local policy in GPRESULT. This seems confirmed by the fact that they use the "Windows Update" Control Panel applet to update the system, instead of the Configuration Manager Control Panel applet and the Software Center application, which are the correct tools.

    The problem with this approach, I think, is that one must not use the WSUS server role in a ConfigMgr SUP server to manage WSUS clients which aren't ConfigMgr client also. The WSUS server role in a ConfigMgr SUP is not to be used as a "typical" WSUS server, it must be configured and managed by the ConfigMgr Console only.

    If there are systems which are not meant to be updated via ConfigMgr (as usually DCs are), they must be configured (via domain GP or other means) to use a dedicated WSUS server, and never the WSUS server role installed in the SUP server.

    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Friday, October 18, 2019 5:55 PM
  • Sorry, I have no idea what DC00 and EXCHANGE are or where you are seeing those so I can't comment about them at all.

    is that one must not use the WSUS server role in a ConfigMgr SUP server to manage WSUS clients which aren't ConfigMgr client also.

    This is 100% correct as doing this is unsupported (it's technically possible if you know all the little details but even then you're asking for trouble).


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, October 18, 2019 6:00 PM
  • Hi,

    Thank Stefano and Jason for your time and great help! 

    At first, I just want to give out my environment.

    DC00 is a DC, PS-000 has WSUS and SCCM together. Exchange is a server for comparing update result until now, no any application on it.

    Because my typo ps-00.test.com:8530 (should be ps-000.test.com:8530) in GPO updatees ( another typo), I got the issue 8024402C. 

    After replaced ps-00.test.com with the WSUS IP address, the issue 8024402C fixed.

    About Exchange, I also had an error: after added it into Domain, I forgot move it into OU Servers from Computers:

    

    Then, Servers is linked to the GPO update, Computers not:

    

    This is why Exchange had Winning GPO: Local Group Policy and DC00 had Winning GPO: Updatees above.

    On account of  the enlighten of your discussed above, I moved Exchange into Servers from Computers, its GPO result was same with others:


    Thank both of you so much!

    yxh




    • Edited by george yu Saturday, October 19, 2019 3:54 PM
    Saturday, October 19, 2019 1:04 PM
  • Hi George,

    sorry for seeming pedantic, but I'm only trying to spare you troubles.

    If I understand well your configuration, you are deploying ConfigMgr client on servers, and also configuring the same servers via GPO to use WSUS, pointing them to your ConfigMgr site server. This is wrong.

    If you configure Software Updates on ConfigMgr for these servers, you must not configure Windows Update by AD GPO, but let ConfigMgr client settings configure it for you. And you must not approve, decline etc. updates in WSUS, but let your ConfigMgr site server manage them for you, when you create Software Update Groups and deploy them using ConfigMgr console.

    If you don't configure Software Updates on ConfigMgr for these servers (but, if you manage them via ConfigMgr client, you should), you have to configure them by group policy; but you must not point them to your ConfigMgr site server's WSUS service, you must use another WSUS server for this purpose, and approve/decline etc. updates on it, in the 'traditional' way.


    Best regards, Stefano Moretti --------------- Namàrië! Nai hiruvalyë Valimar. Nai elyë hiruva. Namàrië!

    Monday, October 21, 2019 9:44 AM
  • Hi Stedano,

    No, no, you are such a good gentleman and very good helper. Following your advice, I already revised my configuration such as using ConfigMgr to control updating instead of GPO.

    Thank you so much!

    have a great day!

    George


    yxh

    Tuesday, October 22, 2019 10:26 PM