none
Errore 8024001F di Windows Update su WSUS RRS feed

  • Domanda

  • Su un server W2K8 R2 con WSUS lanciando la ricerca degli aggiornamenti manualmente mi compare l'errore in oggetto. Preciso che il server, appartenendo a un dominio, riceva da GPO l'impostazione di se stesso come server degli aggiornamenti. Richiedendo invece gli aggiornamenti al sito Microsoft tutto funziona. Gli altri computers ricevono regolarmente gli aggiornamenti da WSUS.
    Ho scaricato e installato il tool automatico di riparazione "WindowsUpdateDiagnostic", il quale ha effettuato alcune operazioni ma senza risolvere il problema.
    Interpellando il servizio di aggiornamenti locale WSUS vengono registrate nel file di log le seguenti informazioni:

    2013-06-06 18:43:36:065  828 10c AU Triggering AU detection through DetectNow API
    2013-06-06 18:43:36:065  828 10c AU Triggering Online detection (interactive)
    2013-06-06 18:43:36:065  828 d1c AU #############
    2013-06-06 18:43:36:065  828 d1c AU ## START ##  AU: Search for updates
    2013-06-06 18:43:36:065  828 d1c AU #########
    2013-06-06 18:43:36:065  828 d1c AU <<## SUBMITTED ## AU: Search for updates [CallId = {ACCF5751-1BFE-48A5-92E0-85B0C38F9975}]
    2013-06-06 18:43:36:074  828 e08 Agent *************
    2013-06-06 18:43:36:074  828 e08 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2013-06-06 18:43:36:074  828 e08 Agent *********
    2013-06-06 18:43:36:074  828 e08 Agent   * Online = Yes; Ignore download priority = No
    2013-06-06 18:43:36:074  828 e08 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"
    2013-06-06 18:43:36:074  828 e08 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2013-06-06 18:43:36:074  828 e08 Agent   * Search Scope = {Machine}
    2013-06-06 18:43:36:074  828 e08 Setup Checking for agent SelfUpdate
    2013-06-06 18:43:36:074  828 e08 Setup Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    2013-06-06 18:43:36:074  828 e08 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2013-06-06 18:43:36:074  828 e08 Misc  Microsoft signed: Yes
    2013-06-06 18:43:36:082  828 e08 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f4
    2013-06-06 18:43:36:082  828 e08 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f4
    2013-06-06 18:43:36:091  828 e08 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f4
    2013-06-06 18:43:36:091  828 e08 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f4
    2013-06-06 18:43:36:108  828 e08 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f4
    2013-06-06 18:43:36:108  828 e08 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f4
    2013-06-06 18:43:36:125  828 e08 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x801901f4
    2013-06-06 18:43:36:125  828 e08 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x801901f4
    2013-06-06 18:43:36:125  828 e08 Misc WARNING: DownloadFileInternal failed for http://172.28.69.6/selfupdate/wuident.cab: error 0x801901f4
    2013-06-06 18:43:36:125  828 e08 Setup WARNING: SelfUpdate check failed to download package information, error = 0x8024401F
    2013-06-06 18:43:36:125  828 e08 Setup FATAL: SelfUpdate check failed, err = 0x8024401F
    2013-06-06 18:43:36:125  828 e08 Agent   * WARNING: Skipping scan, self-update check returned 0x8024401F
    2013-06-06 18:43:36:125  828 e08 Agent   * WARNING: Exit code = 0x8024401F
    2013-06-06 18:43:36:125  828 e08 Agent *********
    2013-06-06 18:43:36:125  828 e08 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2013-06-06 18:43:36:125  828 e08 Agent *************
    2013-06-06 18:43:36:125  828 e08 Agent WARNING: WU client failed Searching for update with error 0x8024401f
    2013-06-06 18:43:36:125  828 e18 AU >>##  RESUMED  ## AU: Search for updates [CallId = {ACCF5751-1BFE-48A5-92E0-85B0C38F9975}]
    2013-06-06 18:43:36:125  828 e18 AU   # WARNING: Search callback failed, result = 0x8024401F
    2013-06-06 18:43:36:125  828 e18 AU   # WARNING: Failed to find updates with error code 8024401F
    2013-06-06 18:43:36:125  828 e18 AU #########
    2013-06-06 18:43:36:125  828 e18 AU ##  END  ##  AU: Search for updates [CallId = {ACCF5751-1BFE-48A5-92E0-85B0C38F9975}]
    2013-06-06 18:43:36:125  828 e18 AU #############
    2013-06-06 18:43:36:125  828 e18 AU Successfully wrote event for AU health state:0
    2013-06-06 18:43:36:125  828 e18 AU AU setting next detection timeout to 2013-06-06 21:43:36
    2013-06-06 18:43:36:125  828 e18 AU Successfully wrote event for AU health state:0
    2013-06-06 18:43:36:125  828 e18 AU Successfully wrote event for AU health state:0

    Sembra che ci sia un errore nel servizio IIS, ma non capisco di cosa si tratta. Qualcuno sa aiutarmi?

    Grazie.


    giovedì 6 giugno 2013 16:43

Risposte

  • A questo punto credo che tutto il problema sia causato dal loop di TMG, anche se non mi spiego come facciano i client a ricevere correttamente aggiornamenti da WSUS se il sito IIS non risulta raggiungibile....

    Prova a vedere se può esserti di aiuto questa discussione (in particolare l'ultimo intervento):

    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgesetup/thread/a22b3a76-423d-4548-a22c-e39e44489e1f/

    Credo che dipenda dalla regola per i protocolli HTTP e HTTPS.



    martedì 11 giugno 2013 15:15
    Moderatore
  • Trovato: si trattava del binding delle schede di rete sul server TMG che, come ho scritto, è dual-homed. Al primo posto c'era la scheda recante l'IP pubblico, dove non sono impostati DNS. Spostando al primo posto la scheda di rete con IP privato, dove come DNS è impostato il DC, e riavviando il servizio di firewall, immediatamente sia i clients che il server WSUS hanno visualizzato correttamente il sito web IIS di WSUS, ma soprattutto ora WSUS interpella correttamente il proprio servizio di aggiornamenti.
    Penso inoltre che questa impostazione errata (la scheda pubblica come primaria) possa essere responsabile di altri piccoli e apparentemente inesplicabili malfunzionamenti che ho sperimentato in passato.

    Grazie infinite per gli utili consigli.



    martedì 11 giugno 2013 16:06

Tutte le risposte

  • lancia questo tool sul server wsus

    http://www.solarwinds.com/products/freetools/diagnostic-tool-for-WSUS-agent.aspx

    e posta il risultato.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    venerdì 7 giugno 2013 14:32
    Moderatore
  • Come dicevo nel primo post, è proprio quello che ho fatto, ma non è servito.
    lunedì 10 giugno 2013 11:08
  • Probabilmente si verifica il problema perché IIS restituisce un errore HTTP 500 all'indirizzo http://172.28.69.6/selfupdate/wuident.cab

    Potresti eseguire una verifica sull'indirizzo localmente e da un client?

    Utilizzi per caso un proxy?

    lunedì 10 giugno 2013 16:41
    Moderatore
  • Sì, le macchine si trovano su una rete privata e si connettono ad Internet mediante un server TMG, che funge da proxy. Sul proxy però sono abilitati tutti gli URL prescritti da Microsoft per Windows Updates.
    Che tipo di verifica devo fare, Fabrizio?

    Grazie.

    martedì 11 giugno 2013 06:59
  • Cioè dovresti verificare se l'indirizzo risulta effettivamente raggiungibile da locale e dai client e riportare eventuali differenze riscontrate.

    Immagino che nel puntamento al server WSUS nelle Group policy sia stato utilizzato direttamente l'indirizzo IP e non il nome, è corretto?

    Hai modo di eseguire un test senza TMG?



    martedì 11 giugno 2013 08:33
    Moderatore
  • Sì, sono impostati da GP con IP.

    Dal server WSUS stesso facendo puntare il browser a http://localhost viene visualizzata regolarmente la pagina di default di IIS.

    Provando invece dai clients a raggiungere il sito web di WSUS, guarda un po', TMG dice:

    Network Access Message: The page cannot be displayed

    Explanation: The page you requested could not be reached, due to a proxy server configuration problem.
     
    Try the following:
     Refresh page: Search for the page again by clicking the Refresh button. The timeout may have occurred due to Internet congestion.
     Check spelling: Check that you typed the Web page address correctly. The address may have been mistyped.
     Contact your administrator: This problem may be due to a mis-configuration.
     
    Technical Information (for support personnel)
     Error Code 12206: Proxy chain loop
     Background: The gateway has detected a proxy chain loop. This condition might indicate a configuration problem on a proxy server.
     Date: 11/06/2013 14:37:26 [GMT]
     Server: PRX-LAB.xxx.xxx.it
    Source: Proxy

    Sembra che ci sia un loop da qualche parte. Eppure dai clients il servizio di aggiornamenti funziona...



    martedì 11 giugno 2013 14:41
  • Però per eseguire un test attendibile dovresti utilizzare l'indirizzo IP anche per il test in locale, utilizzando localhost è normale che non ci siano problemi in quanto viene utilizzando l'indirizzo IP di loopback.
    martedì 11 giugno 2013 14:59
    Moderatore
  • Ehm, hai ragione. In effetti anche dal server immettendo l'IP dà lo stesso messaggio di errore dei clients.
    Lo stesso dal proxy. Diversamente, dal domain controller viene visualizzato correttamente.

    martedì 11 giugno 2013 15:03
  • Quello che non capisco è perché si intrufoli il proxy, quando nelle impostazioni di TMG ho specificato di non utilizzare il proxy per gli indirizzi locali...
    martedì 11 giugno 2013 15:10
  • A questo punto credo che tutto il problema sia causato dal loop di TMG, anche se non mi spiego come facciano i client a ricevere correttamente aggiornamenti da WSUS se il sito IIS non risulta raggiungibile....

    Prova a vedere se può esserti di aiuto questa discussione (in particolare l'ultimo intervento):

    http://social.technet.microsoft.com/Forums/en-US/Forefrontedgesetup/thread/a22b3a76-423d-4548-a22c-e39e44489e1f/

    Credo che dipenda dalla regola per i protocolli HTTP e HTTPS.



    martedì 11 giugno 2013 15:15
    Moderatore
  • Non direi, non ho nessun'altra applicazione proxy di terze parti che gira sulla stessa macchina, che possa generare dei loops...
    martedì 11 giugno 2013 15:55
  • Trovato: si trattava del binding delle schede di rete sul server TMG che, come ho scritto, è dual-homed. Al primo posto c'era la scheda recante l'IP pubblico, dove non sono impostati DNS. Spostando al primo posto la scheda di rete con IP privato, dove come DNS è impostato il DC, e riavviando il servizio di firewall, immediatamente sia i clients che il server WSUS hanno visualizzato correttamente il sito web IIS di WSUS, ma soprattutto ora WSUS interpella correttamente il proprio servizio di aggiornamenti.
    Penso inoltre che questa impostazione errata (la scheda pubblica come primaria) possa essere responsabile di altri piccoli e apparentemente inesplicabili malfunzionamenti che ho sperimentato in passato.

    Grazie infinite per gli utili consigli.



    martedì 11 giugno 2013 16:06