1 13/04/2026 9 min

PXE in ConfigMgr: dove si rompe davvero

Gli errori 0x80070490 e 0x80004005 in un avvio PXE con Microsoft ConfigMgr quasi mai indicano “un solo problema”. Di solito sono il sintomo di un punto di rottura diverso a seconda del layer: boot image non distribuita, risorse PXE non allineate sul Distribution Point, DHCP/relay che non inoltra correttamente, WDS o PXE Responder che non risponde come previsto, oppure un client che riceve il boot file ma poi fallisce nel caricamento dell’ambiente WinPE.

La lettura corretta è questa: prima si stabilisce dove si ferma il flusso PXE, poi si interviene con la modifica minima reversibile. Saltare direttamente a “ridistribuisco tutto” spesso allunga solo il fermo e sposta il problema di qualche metro.

Come interpretare i due codici

0x80070490 in questo contesto è spesso coerente con un problema di elemento non trovato o non disponibile nel percorso di boot: file di avvio, policy, record di distribuzione, risposta PXE attesa ma assente. Non è un errore “PXE puro”, è il modo in cui il client o il componente di ConfigMgr traduce l’assenza di una risorsa necessaria.

0x80004005 è più generico: fallimento non specificato. In pratica compare quando il client riceve una risposta incompleta, un file corrotto, un boot image non valido, un problema di autenticazione/permessi sul contenuto, o una condizione di rete che interrompe la sequenza prima che il codice possa essere più preciso.

In breve: il primo ti dice spesso “manca qualcosa”, il secondo ti dice “qualcosa è andato storto ma non abbastanza da classificare meglio”.

Checklist rapida del layer PXE

Prima di toccare ConfigMgr, conviene verificare il percorso completo del boot:

  1. DNS: il client risolve il nome del server o del DP se il flusso passa da riferimenti FQDN.
  2. DHCP/Relay: il client riceve il lease e le opzioni/forwarding giuste verso il PXE server.
  3. PXE/WDS o PXE Responder: il server risponde alla richiesta di boot.
  4. Distribution Point: la boot image è distribuita e attiva per PXE.
  5. Boot image / WinPE: il file viene scaricato e avviato senza corruzione.
  6. Boundary group / site assignment: il client trova il contenuto nel sito corretto.

Se il guasto si presenta solo su una VLAN o solo da una subnet, il sospetto principale è quasi sempre il relay o il boundary. Se invece il problema colpisce tutti i client, il candidato più probabile è il DP/PXE o la boot image.

Diagnosi probabile

Nel caso classico di ConfigMgr, le cause più frequenti sono tre:

  1. Boot image non aggiornata o non ridistribuita dopo una modifica a driver, WinPE o contenuto correlato. Il client arriva al menu PXE ma fallisce nel caricamento successivo.
  2. PXE service point / WDS / PXE Responder in stato incoerente, spesso dopo una modifica di ruolo, un reboot del server o un aggiornamento. Qui il client riceve una risposta parziale o errata e il codice diventa 0x80004005.
  3. Problema di indirizzamento verso il DP corretto, tipicamente boundary group, DHCP relay o opzioni PXE che portano il client a interrogare un server che non ha il contenuto o non è autorizzato a servirlo.

Se il sintomo è “premo F12, vedo la risposta PXE, poi errore”, la probabilità sale verso boot image e DP. Se invece non compare nessuna risposta, il problema è più a monte: rete, DHCP relay, firewall o servizio PXE non operativo.

Verifiche immediate

Qui serve evidenza, non ipotesi. Le verifiche sotto sono quelle che danno un segnale utile in pochi minuti.

  1. Controlla i log di ConfigMgr sul server PXE/DP. I file più utili, in genere, sono SMSPXE.log, DistMgr.log, PkgXferMgr.log e, se c’è WDS, i log di WDSServer. Cerca righe con “not found”, “no advertisement found”, “boot image”, “content not distributed”, “request failed”.
  2. Verifica che la boot image sia distribuita al DP interessato e marcata per PXE. Nel console path tipico: Software Library → Operating Systems → Boot Images, poi stato di distribuzione e proprietà del DP. Se l’immagine è stata aggiornata, controlla che sia stata ridistribuita dopo la modifica.
  3. Controlla il servizio PXE. Se usi WDS o PXE Responder, verifica che il ruolo sia attivo e coerente con la configurazione. Un servizio “running” non basta: conta anche lo stato del componente nel ruolo ConfigMgr.
  4. Conferma il boundary group del client. Se il client cade nel boundary sbagliato, può ricevere un DP che non ha la boot image corretta o che non è configurato per rispondere al PXE. Verifica la subnet/VLAN del client e il mapping nel sito.
  5. Testa il percorso di rete dalla subnet del client verso il server PXE. Se c’è relay, controlla il forwarding verso la porta/indirizzo previsto. Se il client non arriva proprio al server, il problema non è nella boot image.

Un controllo semplice ma spesso risolutivo è confrontare un client che funziona con uno che fallisce: stessa subnet, stesso DP, stessa boot image. Se uno parte e l’altro no, il problema è nel client o nel suo indirizzamento di rete. Se tutti falliscono, il problema è lato server o contenuto.

Soluzione consigliata passo-passo

La sequenza più sicura è questa, in ordine di impatto crescente.

  1. Ridistribuisci la boot image al DP. È il passo meno invasivo quando sospetti contenuto incoerente. Prima fai uno snapshot della configurazione o annota il DP coinvolto, poi avvia la redistribuzione dalla console. Se il problema era un contenuto obsoleto o corrotto, l’errore tende a sparire senza altri interventi.
  2. Verifica e, se necessario, rigenera l’abilitazione PXE sul DP. Se il ruolo è in stato ambiguo, disabilita e riabilita il supporto PXE solo sul DP interessato, non sull’intero ambiente. Il blast radius resta limitato a quel server. Dopo la modifica, osserva la rigenerazione dei file di boot e dei log PXE.
  3. Controlla la coerenza di WDS o PXE Responder. Se l’ambiente usa WDS, verifica che non ci siano residui di configurazione o conflitti con il responser nativo di ConfigMgr. Se l’architettura è moderna e usa il PXE Responder integrato, evita di tenere attivi componenti duplicati che possono introdurre comportamento non deterministico.
  4. Ricostruisci i file PXE solo se serve. Se i log indicano problemi sui file di avvio, può essere necessario rigenerare i boot files. Questo è un passo più pesante: eseguilo solo dopo aver confermato che la boot image e la distribuzione sono sane. Prima di farlo, pianifica un rollback: restore del contenuto o ritorno alla versione precedente della boot image.
  5. Correggi il boundary group o il relay se il client non raggiunge il DP corretto. Qui la modifica deve essere puntuale: una subnet, un relay, un DP. Non estendere la correzione a tutto il sito se il problema è localizzato. Dopo il fix, riprova da un solo client di test.
  6. Se il problema è su una boot image personalizzata, prova temporaneamente una immagine standard. È un buon modo per falsificare l’ipotesi che il guasto sia nel contenuto WinPE e non nella rete o nel DP. Se la standard funziona, il difetto è nella customizzazione, nei driver o nei componenti aggiunti.

In parallelo, tieni sotto controllo il blast radius: ogni modifica su PXE può impattare tutti i client che fanno imaging. Per questo conviene procedere con una sola variabile alla volta e validare subito con un client noto.

Quando l’errore è davvero 0x80070490

Questo codice si vede spesso quando ConfigMgr non trova l’elemento che il client si aspetta in quella fase del processo. I casi pratici più comuni sono:

  1. boot image non presente sul DP o non disponibile per PXE;
  2. advertisement/policy non coerente con il client;
  3. riferimento a contenuto rimosso o non aggiornato dopo una modifica;
  4. boundary group che porta a un punto di distribuzione sbagliato.

Per falsificare rapidamente questa ipotesi, controlla se il contenuto è effettivamente distribuito e se il client vede il DP corretto. Se il contenuto c’è e il percorso è giusto, allora il problema si sposta su WDS/PXE responder o sulla corruzione del file di boot.

Quando l’errore è davvero 0x80004005

Qui spesso il problema è più “sporco”: una risposta PXE non completa, un file di boot danneggiato, un conflitto tra componenti, o una rete che interrompe il trasferimento. Se il client riceve il menu ma fallisce subito dopo, questo codice è compatibile con un problema nel caricamento del WinPE o nel passaggio da TFTP/HTTP al boot effettivo.

Le verifiche più utili sono:

  1. confrontare l’hash o la distribuzione della boot image con una copia funzionante;
  2. controllare se il problema è iniziato dopo un update di driver o di WinPE;
  3. verificare se il server PXE ha cambiato ruolo o configurazione recentemente;
  4. escludere un problema di sicurezza rete, firewall o MTU quando il download si interrompe sempre nello stesso punto.

Un esempio operativo che evita ore di tentativi

Supponiamo che una VLAN nuova inizi a generare 0x80004005 solo durante il boot PXE. In questo caso il sospetto iniziale non è la boot image, ma il relay o il boundary group. Se la stessa immagine parte da altre VLAN, il contenuto è quasi certamente sano. Il test utile è semplice: un client di controllo nella VLAN nuova, stessa immagine, stesso DP. Se fallisce solo lì, la modifica da fare è sul percorso di rete, non sul contenuto.

Al contrario, se dopo un aggiornamento della boot image tutti i client iniziano a fallire con 0x80070490, la prima cosa da fare è tornare alla versione precedente della boot image o ridistribuire quella corretta. È una correzione reversibile e molto più rapida che inseguire firewall o relay senza evidenza.

Controlli finali / rollback

Dopo la correzione, il minimo indispensabile da verificare è questo:

  1. Avvio PXE riuscito su un client di test, con caricamento del WinPE e accesso all’ambiente previsto.
  2. Nessun errore nuovo in SMSPXE.log durante la richiesta di boot.
  3. Boot image distribuita e coerente sul DP interessato, senza stati pending o failed.
  4. Boundary group e relay ancora corretti per le subnet coinvolte.

Per il rollback, tieni pronta la versione precedente della boot image e annota ogni modifica al DP o al ruolo PXE. Se hai disabilitato e riabilitato il supporto PXE, il rollback deve riportare esattamente la configurazione iniziale, non una variante “simile”.

Assunzione operativa: il problema è in un ambiente ConfigMgr con DP PXE già in produzione, e l’obiettivo è ripristinare il boot senza cambiare architettura o introdurre componenti nuovi.

Regola pratica per non sbagliare intervento

Se l’errore appare prima che il client mostri il menu o l’immagine di boot, lavora su rete, relay e risposta PXE. Se compare dopo che il menu è già visibile, guarda prima boot image, distribuzione contenuto e coerenza del DP. Se il problema è limitato a una subnet o a un solo sito, non toccare tutto l’infrastruttura: il guasto è quasi sempre localizzato.

In ambienti Microsoft, l’errore giusto da correggere non è sempre quello che si legge a schermo. Per PXE in ConfigMgr, il codice è il punto di partenza, non la diagnosi finale. La diagnosi vera è la combinazione di log, stato del contenuto e percorso di rete. Quando questi tre elementi tornano allineati, 0x80070490 e 0x80004005 smettono di essere un mistero e diventano solo un passaggio di manutenzione risolto bene.