Errore WUAgent 0x80004005: come risolvere la sorgente update

0x80004005 su WUAgent: il punto non è “Windows Update rotto”, ma la sorgente update

L’errore 0x80004005 in area Windows Update compare spesso quando il client non riesce a usare in modo pulito la sorgente prevista per gli aggiornamenti. In pratica il problema non è sempre il download in sé: può essere la policy che punta al server sbagliato, il proxy che intercetta male le richieste, una cache locale incoerente oppure un WSUS che risponde ma non è allineato con il tipo di update richiesto.

Se il sintomo è “aggiornamenti che falliscono”, la tentazione è cancellare cartelle e riavviare servizi a occhi chiusi. Funziona solo quando la causa è davvero locale. Se invece la sorgente è sbagliata, il client tornerà a fallire nello stesso punto. Conviene quindi distinguere subito client, policy, rete e server update.

Leggere il sintomo nel modo giusto

Con 0x80004005 il messaggio è troppo generico per dare colpa a un solo componente. La prima domanda pratica è: la macchina vede Internet, vede il WSUS, oppure vede entrambi ma usa la sorgente sbagliata? La seconda è: il problema riguarda tutti gli update o solo una categoria, per esempio feature update, cumulative update o definizioni Defender?

In ambienti gestiti, il caso più comune è questo: il client è configurato per usare un server interno, ma la policy è parziale, il DNS non risolve come previsto, oppure il proxy aziendale rompe l’accesso a endpoint Microsoft necessari per metadata e download. Il risultato è un errore che sembra “update failure” ma in realtà è un conflitto di sorgente.

Le tre cause più probabili, in ordine pratico

1. Policy Windows Update/WSUS incoerente. Il client è puntato a un server di gestione che non pubblica ciò che il sistema si aspetta, o lo fa con policy incomplete. In molti casi bastano chiavi GPO residue per bloccare il passaggio a Windows Update pubblico.

2. Cache WU o componenti locali corrotti. La sorgente è corretta, ma il client tiene in memoria stato, cataloghi o download parziali che impediscono la negoziazione successiva. Qui il problema si manifesta spesso dopo un’interruzione, un reboot forzato o un cambio di policy.

3. Rete/proxy/DNS che alterano il percorso. Il sistema risolve male i nomi, passa da proxy non previsto, oppure il firewall filtra endpoint necessari alla validazione della sorgente. In ambienti ibridi questo è molto più frequente di quanto si ammetta.

Verifiche rapide che separano il client dalla sorgente

Prima di toccare servizi o cartelle, conviene raccogliere evidenza. Su un client Windows, il primo controllo utile è capire se la macchina è agganciata a una sorgente gestita e quale policy la governa.

gpresult /h C:\Temp\gp.html

Apri il report e cerca le impostazioni legate a Windows Update, WSUS, intranet update service e target release. Se vedi policy attive ma non coerenti con il comportamento atteso, hai già un indizio forte. Il controllo non risolve nulla, ma ti dice se stai inseguendo un problema locale o un problema di governance della sorgente.

Il secondo passo è verificare il servizio e il log operativo di Windows Update. Non serve fare acrobazie: basta vedere se il client sta tentando di contattare una sorgente precisa e dove fallisce.

Get-WindowsUpdateLog

Su sistemi recenti il log viene ricostruito dai tracciati ETL. Se trovi errori ripetuti verso lo stesso endpoint o messaggi su source non raggiungibile, la pista è quasi certamente di rete o policy. Se invece il tentativo di contatto non parte nemmeno, il problema è più spesso nella configurazione locale del client.

Terzo controllo: connettività diretta verso la sorgente prevista. Se c’è un WSUS, testa porta e nome host. Se il client deve andare su Internet, verifica DNS e raggiungibilità degli endpoint Microsoft senza proxy “fantasma”.

nslookup nome-wsus.example.local
Test-NetConnection nome-wsus.example.local -Port 8530

Se il nome non risolve, il problema non è WUAgent. Se risolve ma la porta non è raggiungibile, il blocco è a rete o firewall. Se entrambi vanno a buon fine ma l’errore resta, allora la sorgente è raggiungibile ma non viene accettata dal client o non risponde con contenuti coerenti.

Quando la sorgente update è il vero problema

La parola “sorgente” qui va presa sul serio. Un client Windows può essere indirizzato verso più origini logiche: WSUS, Microsoft Update, Microsoft Store per alcuni componenti, endpoint di telemetria e download metadati, proxy autenticato, cache locale. Se una sola di queste è incoerente, la catena si spezza.

Il caso classico è il computer che riceve policy da dominio e allo stesso tempo ha impostazioni residue da configurazioni precedenti. Per esempio: WSUS impostato in GPO, ma chiavi locali ancora presenti; oppure un proxy configurato a livello utente che interferisce con il servizio di sistema; oppure un DNS interno che non consente il corretto fallback verso gli endpoint pubblici quando la policy lo richiede.

Un altro scenario frequente è il server WSUS stesso: il client lo vede, ma il catalogo lato server è incompleto, le approvazioni non sono allineate, o il contenuto non è stato sincronizzato correttamente. In quel caso il client non sta “rompendosi”: sta solo eseguendo una richiesta che il server non riesce a soddisfare.

Soluzione consigliata: prima riallinea, poi resetta

Il principio operativo è semplice: non cancellare tutto subito. Prima riallinea la sorgente, poi pulisci la cache locale solo se serve. È il modo più sicuro per evitare reset inutili e falsi positivi.

1. Verifica la policy effettiva con gpresult /h o con la console GPO se gestisci il dominio. Cerca le impostazioni di Windows Update e conferma se il client deve usare WSUS, Microsoft Update o entrambi in scenari separati.

2. Conferma che il nome della sorgente sia risolvibile e raggiungibile. Un nslookup e un Test-NetConnection bastano per separare un problema DNS/firewall da un problema applicativo.

3. Se il client è dietro proxy, controlla la configurazione effettiva del contesto di sistema e non solo quella dell’utente. Molti fallimenti nascono da proxy impostati male nel profilo sbagliato.

4. Solo dopo aver escluso policy e rete, riavvia i componenti di Windows Update e pulisci la cache di download, sempre con backup mentale del fatto che stai toccando una macchina di produzione.

Per il reset locale, il flusso classico è fermare i servizi coinvolti, rinominare la cache e riavviare. È reversibile se eseguito con ordine, perché non stai cancellando dati di business ma solo artefatti di aggiornamento.

net stop wuauserv
net stop bits
net stop cryptsvc
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv

Questo passaggio ha un blast radius limitato al client, ma va comunque trattato come modifica operativa: alcuni download in corso si perdono e la macchina dovrà ricostruire il catalogo. Il rollback è semplice: se qualcosa peggiora, puoi rimettere i servizi in stato normale e ripristinare i nomi delle cartelle rinominate.

Se la sorgente è WSUS, controlla anche il lato server

Quando il client è configurato per un update server interno, il vero collo di bottiglia può essere il server stesso. Non basta che risponda sulla porta: deve pubblicare contenuti, approvazioni e metadata compatibili con i client che lo interrogano.

Le verifiche minime lato WSUS sono tre: servizio attivo, sincronizzazione recente, spazio disco sufficiente per contenuti e database. Se il server è pieno o la sincronizzazione è fallita, i client spesso mostrano errori generici come 0x80004005 anche se il problema è in origine lato infrastruttura.

In un ambiente con WSUS su IIS, vale la pena controllare anche i log dell’application pool e l’eventuale presenza di errori 503, timeout o limiti sul pool stesso. Un WSUS formalmente “up” ma degradato produce sintomi sporadici e difficili da leggere dal solo client.

Quando conviene forzare una correzione delle policy

Se il report GPO mostra valori incoerenti con il comportamento atteso, la correzione più pulita è sistemare la policy alla fonte, non sul singolo endpoint. Cambiare il client a mano serve solo per diagnosi o per sbloccare un urgenza temporanea.

Il punto chiave è evitare configurazioni ibride non intenzionali. Se vuoi usare WSUS, il client deve essere chiaramente agganciato a quella sorgente. Se vuoi uscire da WSUS e tornare a Microsoft Update, devi rimuovere la policy e verificare che non restino chiavi locali o criteri residui. In pratica, il sistema deve avere una sola verità operativa, non due mezze configurazioni che si pestano i piedi.

Un dettaglio spesso ignorato: il proxy del servizio, non dell’utente

Molti controllano il browser e pensano che il proxy sia a posto. Per Windows Update non basta. Il servizio gira con contesto diverso e può usare impostazioni differenti da quelle dell’utente loggato. Se il proxy richiede autenticazione o ha esclusioni sbagliate, il client può fallire pur navigando normalmente.

Per questo, quando il problema è intermittente o dipende dall’account, la diagnostica deve includere il livello di sistema. Se hai un proxy aziendale, verifica che gli endpoint richiesti da Windows Update siano consentiti e che non ci siano ispezioni SSL o policy di content filtering che rompono i metadata.

La correzione strutturale: rendere visibile la sorgente

La soluzione che regge nel tempo non è il reset manuale del client, ma la visibilità della sorgente. In una rete gestita serve sapere con certezza chi decide dove il client scarica gli update, chi approva i pacchetti e chi controlla il fallback. Senza questa chiarezza, 0x80004005 continuerà a ricomparire con forme diverse.

In pratica conviene avere tre livelli ben distinti: policy centralizzata, connettività verificata e cache locale ripulibile. Se uno di questi tre livelli è opaco, ogni ticket successivo diventa un’indagine da zero. Se invece hai report GPO, log di update e test di rete standardizzati, il tempo di diagnosi si accorcia molto.

Sequenza operativa che uso di solito

1. Controllo il layer: policy, rete o cache locale.

2. Confermo la sorgente attesa con report GPO o configurazione locale.

3. Testo risoluzione DNS e connettività verso la sorgente update.

4. Leggo il log Windows Update per identificare il punto esatto di fallimento.

5. Solo se la sorgente è corretta e raggiungibile, resetto i componenti locali.

6. Se il problema persiste, verifico lato server WSUS, proxy e firewall.

Questa sequenza evita il classico errore di “riparare” il client quando il problema è a monte. In ambienti con più reparti o più siti, è molto comune che un solo segmento di rete abbia regole diverse e faccia sembrare il guasto casuale.

Segnali che indicano che hai trovato la causa giusta

• Il client inizia a vedere una sola sorgente coerente dopo la correzione della policy.

• I log smettono di mostrare tentativi verso endpoint diversi o fallimenti ripetuti sullo stesso host.

• Dopo il reset della cache, gli update riprendono senza ricadere nello stesso errore.

• Il server WSUS o il proxy non mostrano più timeout, 403, 503 o richieste incomplete durante il download.

Rollback e prudenza operativa

Se hai toccato solo cache locale, il rollback è semplice: ripristina i nomi originali delle cartelle rinominate e riavvia i servizi. Se hai modificato policy, il rollback è il ripristino della GPO precedente o della configurazione locale esportata. Se hai cambiato qualcosa su WSUS o proxy, conserva il diff o lo screenshot di prima di intervenire: senza quello, il rollback diventa improvvisazione.

Per sicurezza, ogni intervento sulla sorgente update andrebbe fatto con un punto di verifica prima e dopo: stato del servizio, esito del test di connettività, log del client e, se c’è, approvazione del change. È il modo più rapido per evitare di confondere una correzione con una coincidenza temporale.

Assunzione operativa: il lettore ha accesso amministrativo al client e, se presente, al dominio/WSUS per verificare policy, log e connettività prima di fare modifiche permanenti.