1 23/04/2026 11 min

0x800702C2 in SCCM: il punto non è l’errore, è il passaggio che si ferma

Quando una Task Sequence di SCCM si interrompe con 0x800702C2, il codice da solo dice poco: non è la causa, è il sintomo di un fallimento nel momento in cui Windows PE o il sistema in deployment prova a eseguire un’operazione e trova un blocco a livello di file, rete, driver o componente della sequenza. In pratica, il problema quasi mai si risolve “cambiando un flag” a caso. Va isolato il punto esatto in cui la sequenza si ferma e va capito se il guasto nasce prima del boot, durante il download del contenuto, nel passaggio di applicazione immagine o in una fase post-OS come driver, join al dominio o installazione applicazioni.

Il comportamento tipico è questo: la macchina parte, inizia la Task Sequence, poi si blocca su un step specifico oppure si riavvia con un errore generico. In ambienti SCCM maturi il codice compare spesso quando c’è una combinazione di contenuto non coerente, cache corrotta, driver sbagliato, storage lento o un problema di accesso al package su Distribution Point. Se invece il fallimento arriva in una fase molto precoce, la prima ipotesi da guardare è il layer di boot e networking: WinPE vede la rete? Il task sequence media è raggiungibile? Il driver della scheda è quello giusto?

Classificazione pratica: troubleshooting con impatto da produzione

Questo va trattato come troubleshooting con potenziale impatto da produzione, perché una Task Sequence fallita non è solo un PC che non si installa: può bloccare rollout, refresh di parco macchine, imaging di postazioni critiche o provisioning di device in fabbrica. Se il contenuto viene modificato, il blast radius include il collection target, il Distribution Point e, in certi casi, l’intera catena di deployment se il package è condiviso da più Task Sequence.

Dove guardare per primo: il passaggio che fallisce, non il codice

La diagnosi utile parte dalla riga del log in cui compare l’errore. In SCCM i file più importanti sono quasi sempre quelli della Task Sequence e di WinPE: smsts.log è il primo riferimento, poi entrano in gioco i log del client, i log del Distribution Point e, se necessario, i log di setup di Windows. Il punto non è leggere tutto: serve trovare l’ultimo step riuscito e il primo step fallito. Se il task si rompe dopo il download dei contenuti, il problema è diverso da un crash prima dell’avvio di WinPE o da un errore durante l’applicazione del driver pack.

Su una macchina in deployment, la verifica minima è sempre questa: aprire la console di log della sequenza e cercare il timestamp dell’errore, poi correlare il nome dello step con il tipo di azione. Se la Task Sequence fallisce in Apply Operating System, si guarda il contenuto del package e la raggiungibilità del DP. Se fallisce in Apply Driver Package, il sospetto si sposta su compatibilità hardware e ordine dei driver. Se si ferma su Install Applications, il problema può essere nel detection method, nelle dipendenze o in un MSI che restituisce codici non gestiti correttamente.

Ipotesi più probabili, in ordine realistico

1) Driver di rete o storage non coerenti con WinPE o con il modello hardware. È una delle cause più frequenti quando la Task Sequence si interrompe presto o perde accesso al contenuto. La falsifichi in pochi minuti verificando se il device ha IP, se vede il DP e se nel log compare il caricamento del driver corretto. Se in WinPE ipconfig non mostra una interfaccia valida, la pista è quasi chiusa.

2) Contenuto non disponibile o corrotto sul Distribution Point. Package distribuito male, hash incoerente, file mancanti, DP non aggiornato, boundary group errato: tutte cose che in SCCM diventano errori apparentemente generici. La falsificazione rapida è controllare se il medesimo contenuto si scarica da un altro DP o se il package risulta “successfully distributed” ma in realtà manca un file nel path del DP.

3) Problema di sequenza o prerequisiti OS/applicazioni. Una variabile non valorizzata, uno step condizionato male, un reboot inatteso, un MSI che fallisce con exit code non previsto, un application model che non rispetta le dipendenze: qui l’errore non è infrastrutturale ma logico. La falsificazione avviene leggendo smsts.log e cercando il primo return code non gestito oppure uno step saltato per condizioni errate.

Verifiche immediate: cosa controllare senza toccare nulla

Prima di cambiare qualsiasi cosa, raccogli evidenza. È il modo più veloce per evitare tentativi alla cieca e capire se il guasto è riproducibile o legato a un singolo endpoint.

  1. Apri smsts.log e identifica l’ultimo step completato. Su Windows in esecuzione il file può trovarsi in C:\Windows\CCM\Logs\smsts.log; in WinPE spesso è in X:\Windows\Temp\SMSTSLog\smsts.log. Atteso: vedi chiaramente il nome dello step e il codice di uscita. KO: il log si interrompe prima dello step incriminato, segno che il fallimento è precedente.

  2. Verifica connettività e DNS dal contesto in cui gira la sequenza. Se sei in WinPE, usa ipconfig e un test verso il DP o il Management Point. Atteso: IP corretto, gateway presente, risoluzione nome funzionante. KO: niente IP o nome DP non risolto, quindi il problema è di rete o driver.

  3. Controlla nel console di SCCM lo stato del package o dell’application distribuita. Atteso: contenuto distribuito sui DP richiesti e stato coerente. KO: package parzialmente distribuito, DP non aggiornato o boundary group che non instrada il client sul punto giusto.

  4. Se l’errore avviene dopo il boot dell’OS, controlla il registro eventi o i log di setup relativi allo step fallito. Atteso: nessun errore di accesso al file o all’MSI. KO: codice di uscita non previsto o file mancante nel percorso del package.

Soluzione consigliata passo-passo

Qui conviene muoversi in modo reversibile. L’obiettivo è ridurre il perimetro del problema e correggere il layer più probabile senza introdurre altre variabili.

  1. Salva una copia della Task Sequence o esporta lo step interessato. Prima di toccare condizioni, driver o applicazioni, crea un backup logico della sequenza. Se lavori da console SCCM, annota nome, versione e step coinvolto. Blast radius: limitato alla Task Sequence modificata. Rollback: ripristino della versione precedente o import del backup.

  2. Isola il punto di rottura con un test minimale. Disabilita temporaneamente gli step non necessari dopo quello che fallisce e riprova su un singolo device di test. Se il task arriva oltre, il problema è legato allo step sospetto e non all’intera sequenza. Verifica attesa: il flusso supera il punto critico. KO: si ferma nello stesso punto, quindi la causa è ancora nel layer precedente.

  3. Se sospetti driver, sostituisci solo il pacchetto interessato. Aggiorna il driver pack del modello hardware coinvolto, non tutti i driver del catalogo. In ambienti con WinPE, verifica che il driver della NIC e, se serve, dello storage controller siano presenti e corretti. Dopo la modifica, controlla che il device ottenga rete e che il contenuto del DP sia accessibile. Rollback: ripristina il driver pack precedente se il nuovo introduce regressioni.

  4. Se sospetti il contenuto, valida il package sul DP. Ridistribuisci il package o l’application incriminata e controlla che il contenuto sia completo. Se il problema appare solo su un DP, confronta i file presenti sul nodo con la sorgente del contenuto. Atteso: file identici e distribuzione riuscita. KO: hash o dimensioni non coerenti, oppure package non presente sul DP corretto.

  5. Se il fallimento è applicativo, correggi detection e exit code. Molti errori “misteriosi” nascono da un MSI che termina con un codice non considerato successo oppure da un detection method troppo aggressivo. Verifica il codice di uscita nello step e assicurati che la Task Sequence lo interpreti correttamente. Se serve, aggiungi il codice al set di success codes solo se il comportamento dell’installer è noto e documentato. Rollback: rimuovi la modifica ai success codes se introduce installazioni incomplete.

  6. Rilancia il test su un solo endpoint e con logging massimo. Non serve validare sul parco intero finché il comportamento non è stabile su una macchina campione. Usa un device rappresentativo del modello interessato, con log completo e accesso al DP previsto. Atteso: la sequenza completa l’installazione senza errori. KO: stesso codice 0x800702C2 o nuovo errore nello step successivo.

Quando il problema è nel layer rete e non in SCCM

In molti casi SCCM viene accusato ingiustamente. Se il device non vede il Distribution Point, il problema può essere una VLAN sbagliata, una policy DHCP incompleta, un gateway errato o un firewall intermedio che blocca il traffico necessario alla sequenza. Anche un certificato non valido o un proxy che intercetta richieste verso i servizi del management point può spezzare il flusso. La prova più rapida è semplice: se dal contesto della sequenza non riesci a risolvere il nome del DP o a stabilire connessione, non ha senso inseguire i passaggi della Task Sequence finché la rete non è stata sistemata.

Qui il controllo utile è doppio: da un lato la connettività effettiva del client, dall’altro la raggiungibilità dei servizi SCCM. Se il problema è intermittente, osserva se colpisce solo alcune sedi o solo certi modelli di macchina. Se colpisce un intero segmento di rete, il sospetto va subito su routing, ACL o boundary group. Se colpisce un solo modello, è più probabile il driver della NIC o il firmware.

Il caso classico: la sequenza funziona su un modello, fallisce su un altro

Questo scenario è quasi sempre legato a hardware-specificità: storage controller diverso, NIC diversa, UEFI/Legacy non allineato, o driver pack non aggiornato. Una Task Sequence che funziona su un laptop e fallisce su un desktop della stessa famiglia non va letta come “problema casuale”. È un indizio forte. Il modo giusto di gestirlo è confrontare i parametri di boot, i driver in WinPE e l’ordine di applicazione dei pacchetti. In particolare, se il sistema perde il disco dopo il partizionamento o non vede il volume, il problema è spesso nel driver storage. Se perde la rete, il problema è nella scheda o nel driver NIC.

Un dettaglio che spesso viene trascurato è la differenza tra driver installati nell’OS finale e driver caricati nel boot image. La macchina può avviarsi bene nel sistema operativo installato, ma fallire prima ancora di arrivare lì perché WinPE non ha il driver giusto. È per questo che aggiornare “i driver del sistema” non basta: bisogna verificare anche il boot image e, se necessario, rigenerarlo o aggiornarlo con i driver minimi indispensabili.

Osservabilità minima che salva tempo

Se vuoi ridurre il tempo medio di diagnosi, standardizza tre cose: raccolta dei log, naming dei package e test su un endpoint campione. Il primo punto evita ricerche manuali ogni volta. Il secondo riduce gli errori di distribuzione. Il terzo ti dice subito se la modifica ha rotto qualcosa. Nei contesti più grandi vale anche la pena avere un controllo periodico sullo stato dei DP e dei boundary group: molti 0x800702C2 sono effetti secondari di una distribuzione non allineata, non difetti del client.

Se devi fare audit, la combinazione utile è: log della Task Sequence, stato di distribuzione del contenuto, versione del boot image e corrispondenza tra modello hardware e driver pack. Non serve inventare metriche sofisticate: basta sapere se il contenuto è presente, se il client lo raggiunge e in quale step si rompe. Il resto viene dopo.

Controlli finali e rollback

Prima di dichiarare chiuso il problema, verifica che la Task Sequence completi almeno un run pulito sul modello interessato e, se possibile, su un secondo device dello stesso gruppo. Controlla che non restino step disabilitati per errore, che il driver pack corretto sia quello effettivamente referenziato e che il contenuto sui DP sia distribuito in modo coerente. Atteso: nessun nuovo errore in smsts.log, installazione completa, rete stabile durante tutto il flusso.

Se la correzione è stata fatta su driver, package o condizioni della sequenza, il rollback deve essere immediato e documentato: ripristino del driver pack precedente, re-enable degli step originali, o rimozione della modifica ai success codes. Se hai cambiato il contenuto distribuito, conserva la versione precedente finché non hai validato che quella nuova non introduce regressioni. Assunzione: l’errore 0x800702C2 è stato osservato durante una Task Sequence SCCM standard e la diagnosi parte dal log dello step fallito, non da una modifica massiva dell’infrastruttura.