1 23/05/2026 10 min

0xC1030104 in SCCM e WDS: dove si rompe davvero il flusso PXE

L’errore 0xC1030104 in un contesto SCCM/MECM con WDS quasi mai indica un solo guasto. Di solito è il sintomo finale di un problema nel percorso PXE: il client ottiene una risposta dal servizio, ma poi fallisce nel recupero del boot image, nel passaggio al TFTP, nella validazione del punto di distribuzione o nella negoziazione con l’architettura corretta. Se lo si tratta come un semplice “WDS rotto”, si finisce a riavviare servizi a caso e a perdere tempo.

Il modo corretto di leggerlo è questo: il client sta arrivando abbastanza avanti da chiedere l’avvio in rete, ma qualcosa interrompe la catena prima del caricamento del sistema WinPE. La diagnosi va quindi fatta per layer: DHCP/PXE, risposta del Distribution Point, trasferimento del boot file, integrità dell’immagine, e infine coerenza tra policy SCCM e configurazione WDS.

La prima distinzione che evita falsi positivi

Non tutti i casi con 0xC1030104 hanno la stessa origine. In pratica conviene separare subito due scenari:

  • Il client non riceve proprio l’ambiente di boot: il problema è quasi sempre nel percorso PXE/TFTP o nella pubblicazione del boot image.
  • Il client riceve un avvio parziale e poi si ferma: spesso il boot image è corrotto, non aggiornato, non distribuito sul DP corretto oppure non compatibile con l’architettura del client.

Se hai un ambiente con più Distribution Point, boundary group e opzioni PXE differenziate, il rischio più comune è che il client stia parlando con il server giusto ma venga servito con un contenuto non coerente rispetto al suo profilo. In questi casi il registro eventi del server e i log lato client dicono molto più del riavvio di WDS o del provider SMS.

Cosa controllare per primo: evidenza minima e layer coinvolto

Prima di modificare qualunque cosa, raccogli l’evidenza minima. Il punto è capire quale layer sta fallendo, non solo confermare che “non parte”.

  1. Controlla il comportamento del client PXE: compare il messaggio di avvio, ottiene un IP, riceve il boot file, oppure si ferma prima?
  2. Verifica i log sul server SCCM/DP. I file più utili, a seconda della versione e del ruolo, sono tipicamente SMSPXE.log, smspxe.log, distmgr.log, smsts.log e i log WDS/WDSServer.
  3. Conferma che il boot image sia distribuito sul DP giusto e aggiornato dopo eventuali modifiche al contenuto o al driver store.

Un controllo rapido da fare dal lato rete è vedere se il client arriva almeno al servizio di risposta PXE. Se hai accesso alla rete di test, una cattura breve o una verifica del lease DHCP ti dice se il problema è prima o dopo la risposta del DP. Se invece il client arriva a scaricare il file ma poi fallisce, il sospetto si sposta su WDS, TFTP o boot image.

Diagnosi probabile: le tre cause più frequenti

Ordinate per probabilità pratica, non teorica:

  1. Boot image non distribuito o non aggiornato sul Distribution Point. È il caso più comune dopo un cambio di contenuto, driver o update del package. Il client riceve la risposta PXE, ma la catena si rompe quando deve scaricare o avviare il file corretto.
  2. Incoerenza tra architettura client e configurazione PXE/WDS. Un client x64 trattato come x86, oppure opzioni legacy/UEFI non allineate, può generare un errore che sembra generico ma nasce da una selezione sbagliata del boot file.
  3. Problema sul servizio WDS o sul canale TFTP. Servizio fermo, binding errato, firewall locale o filtri di rete sul traffico UDP possono impedire il trasferimento del boot image anche quando il DP risponde.

Per falsificare rapidamente la prima ipotesi, basta verificare nel console SCCM che il boot image sia effettivamente distribuito al DP e che il contenuto sia in stato success o equivalente. Se il DP è in errore o in pending, hai già trovato il punto di rottura. Per la seconda, controlla se l’errore compare solo su una specifica classe di device: se i client UEFI falliscono e i legacy no, il problema è quasi certamente nella selezione del boot file. Per la terza, il test più veloce è il servizio Windows dedicato a WDS e i log del ruolo sul server.

Verifiche immediate sul server SCCM/DP

Qui conviene restare chirurgici. Non serve “riparare” nulla finché non hai confermato lo stato del DP e del contenuto. Un set di controlli rapido è questo:

  1. Apri la console SCCM e verifica il boot image usato dal task sequence. Controlla che sia il file atteso e non una versione vecchia rimasta pubblicata per errore.
  2. Controlla lo stato di distribuzione del boot image sul DP. Se il contenuto non è completo, il client può ricevere il PXE response ma fallire al primo download utile.
  3. Verifica il log SMSPXE.log sul DP. Devi cercare righe che mostrino richiesta ricevuta, architettura rilevata, immagine proposta e eventuali errori di accesso al contenuto.
  4. Controlla i servizi WDS e SMS Executive nel server. Se uno è fermo o in stato instabile, l’errore è plausibile anche senza altri sintomi.

Se trovi un boot image in distribuzione fallita, non forzare subito una rimozione e una ripubblicazione completa: prima capisci se il problema è nel contenuto o nel DP. In molti casi basta una nuova distribuzione del package dopo aver verificato che il file sorgente non sia stato toccato o sostituito. Questo riduce molto il blast radius rispetto a cambiare impostazioni del ruolo PXE a livello globale.

Soluzione consigliata passo-passo

La sequenza sotto è pensata per essere reversibile e con impatto limitato. Fai un passo, verifica, poi passa al successivo solo se serve.

  1. Conferma il boot image corretto nella task sequence. Apri la task sequence e verifica che punti al boot image previsto. Se qualcuno ha duplicato la sequenza o sostituito il contenuto, il client potrebbe ricevere un riferimento incoerente.
  2. Controlla la distribuzione del boot image al DP. Se lo stato non è verde/completo, avvia una nuova distribuzione del contenuto. Questo è l’intervento minimo e reversibile: non cambia la logica del deployment, ristabilisce solo la disponibilità del package.
  3. Verifica l’architettura e la modalità di boot. Se il problema colpisce solo UEFI o solo BIOS legacy, controlla che il boot file e la policy PXE siano coerenti con il firmware del client. Un mismatch qui produce errori apparentemente generici ma molto ripetibili.
  4. Esamina SMSPXE.log durante un tentativo reale. Cerca il punto in cui il DP identifica il device e decide quale boot image servire. Se il log mostra “no boot image available”, “access denied”, “content not found” o un riferimento a architettura non supportata, hai la causa funzionale.
  5. Riavvia solo i servizi coinvolti, non il server intero. Se WDS o il ruolo PXE risultano bloccati, un restart mirato del servizio è preferibile a un riavvio completo. È una mitigazione, non la soluzione definitiva.
  6. Se il problema persiste, ripubblica il boot image. Prima di farlo, assicurati di avere un backup logico della configurazione corrente: annota nome package, versione, DP coinvolto e impostazioni PXE. La ripubblicazione è reversibile, ma solo se sai esattamente cosa stai cambiando.

Un esempio pratico: se dopo un aggiornamento dei driver il boot image non si avvia più e il log mostra fallimenti al caricamento del contenuto, il fix non è toccare DHCP o cambiare le opzioni PXE. Prima ripristina una versione precedente del boot image, verifica che venga distribuita correttamente e solo dopo reintroduci il driver aggiornato in modo controllato.

La regola utile è semplice: se il client arriva al PXE ma non al WinPE, il problema è quasi sempre nel contenuto o nel trasporto del contenuto. Se non arriva nemmeno alla risposta PXE, il problema è prima, nel layer di rete o nella pubblicazione del servizio.

Quando il problema non è SCCM ma la rete

Molti ambienti danno per scontato che il PXE sia “solo un servizio del server”, ma in realtà dipende molto dalla rete. Se il client non riceve risposta, o riceve risposta intermittente, controlla i punti classici: relay DHCP, firewall, VLAN, helper address, filtri UDP e policy di sicurezza sui segmenti coinvolti.

In particolare, se il DP è in una subnet diversa dal client e il traffico PXE passa da apparati intermedi, un cambio di configurazione sul relay può rompere tutto senza lasciare tracce evidenti nel server SCCM. In quel caso i log del DP risultano “puliti” perché la richiesta non arriva proprio. La verifica più rapida è confrontare un client che fallisce con uno nella stessa subnet del DP, oppure fare una prova da una rete nota e stabile.

Problemi di contenuto: boot image, driver e aggiornamenti

Un boot image può essere formalmente distribuito ma comunque inutilizzabile. Succede quando dentro ci sono driver incompatibili, componenti WinPE mancanti o cambiamenti recenti che non sono stati propagati correttamente al DP. Anche qui il sintomo finale può essere 0xC1030104, ma la radice è nel package.

  1. Verifica se il boot image è stato modificato di recente.
  2. Controlla se è stata eseguita la distribuzione aggiornata verso tutti i DP richiesti.
  3. Se il problema è iniziato dopo l’aggiunta di driver, prova temporaneamente una build precedente del boot image.

Qui il rollback è spesso la strada più sensata. Se hai una versione funzionante del boot image, tornare indietro è più sicuro che cercare di correggere al volo un contenuto probabilmente corrotto o incoerente. La cosa importante è non confondere rollback del contenuto con rollback della console o del ruolo: il primo è mirato, il secondo è molto più invasivo.

Controlli finali dopo la correzione

Dopo la modifica, non fermarti al “non dà più errore”. Devi vedere il client arrivare almeno al caricamento di WinPE e, idealmente, all’avvio della task sequence.

  1. Ripeti un avvio PXE da un client di test noto e monitora il log del DP in tempo reale.
  2. Conferma che il boot image venga servito senza errori e che il client superi la fase di download iniziale.
  3. Verifica che la task sequence prosegua oltre la fase di boot, così distingui un problema PXE da un problema applicativo post-boot.
  4. Annota quale change ha risolto il problema: distribuzione contenuto, restart servizio, correzione architettura, ripristino boot image o fix rete.

Se il sistema torna operativo dopo un restart di WDS ma il log continua a mostrare warning o errori di contenuto, non considerare il caso chiuso. Hai solo rimesso in piedi il servizio, non risolto la causa. In produzione questo approccio porta quasi sempre a un secondo fermo, spesso nel momento peggiore.

Rollback e blast radius

Il blast radius dipende da cosa tocchi. Un cambio sul boot image o sulla task sequence impatta solo i deployment che lo referenziano; un cambio su WDS, firewall o relay DHCP può invece colpire tutti i client PXE del segmento. Per questo conviene procedere dal contenuto al servizio, e dal servizio alla rete solo quando i log lo giustificano.

Rollback consigliato, in ordine di impatto crescente:

  1. Ripristino del boot image precedente e nuova distribuzione sul DP.
  2. Riavvio mirato di WDS o del servizio PXE correlato.
  3. Revisione della configurazione del DP/PXE con ritorno al settaggio precedente.
  4. Ripristino delle regole di rete solo se la modifica è stata l’ultima variazione introdotta.

Assunzione operativa: l’errore 0xC1030104 viene trattato qui come sintomo di fallimento nella catena PXE/SCCM/WDS, non come bug isolato del client. Se il tuo ambiente usa configurazioni custom, multicast, fallback DP o policy particolari, la verifica va adattata sui log effettivi del sito e sui dettagli del boundary group.