1 27/10/2026 12 min

Quando il Task Sequence si ferma, il problema quasi mai è “SCCM in generale”

Nel troubleshooting di una Task Sequence in SCCM il primo errore è partire dal sintomo più vistoso e non dal layer che lo genera. Un Task Sequence che fallisce può dipendere dal boot image, dalla distribuzione del contenuto, dal client, dalla rete, dal disco, dal passaggio di WinPE a full OS, oppure da una singola azione della sequenza che rompe il flusso. Prima di cambiare qualcosa, conviene capire in quale fase si ferma e che tipo di fallimento stai vedendo: errore immediato, reboot loop, schermata nera, download che non parte, applicazione che fallisce, o completamento solo apparente con post-configurazione incompleta.

La distinzione più utile è tra problema di pre-OS e problema di post-OS. Se il guasto avviene in WinPE, la priorità è quasi sempre su rete, boot image, driver di storage o accesso al Distribution Point. Se il guasto arriva dopo l’avvio del sistema operativo, entrano in gioco client SCCM, boundary group, policy, content location, account, permessi e log applicativi. Senza questa separazione si finisce a leggere log a caso, perdendo tempo e spesso peggiorando la situazione con modifiche inutili.

Fase della sequenza: capire dove si rompe il flusso

Una Task Sequence sana ha un comportamento prevedibile: il dispositivo entra nell’ambiente di provisioning, recupera i contenuti necessari, esegue le azioni previste, riavvia quando serve e prosegue fino al completamento. Quando qualcosa non torna, il primo dato utile non è il messaggio generico a schermo, ma il punto esatto in cui si interrompe il ciclo. In pratica, chiediti: il dispositivo arriva a WinPE? Scarica la policy? Inizia il download del contenuto? Fallisce su una specifica applicazione? Si blocca al primo reboot? Oppure completa ma il computer resta in uno stato incoerente?

Se il problema è in fase iniziale, i responsabili più frequenti sono PXE, boot image, driver NIC/storage, DHCP, WDS/MP, oppure un Distribution Point che non serve correttamente i contenuti. Se invece il Task Sequence parte ma si ferma dopo uno o più step, il candidato principale diventa il contenuto associato a quella singola azione: pacchetto non distribuito, programma non trovato, command line errata, variabili non valorizzate, oppure una dipendenza che non è compatibile con il sistema target.

Una verifica rapida e poco invasiva è osservare il comportamento con i log aperti in tempo reale. Nel contesto SCCM, i riferimenti più usati sono smsts.log e, a seconda della fase, i log del client e della distribuzione contenuto. Il punto non è memorizzare tutti i nomi, ma leggere il flusso: se il log mostra download, validazione e poi errore su una content location, il problema non è la logica della sequenza ma la disponibilità del contenuto; se invece l’errore arriva prima, il sospetto va su prerequisiti dell’ambiente di boot.

Smsts.log: il file che decide quasi sempre la diagnosi

Per il troubleshooting serio, smsts.log è il primo artefatto da aprire. La sua posizione cambia in base alla fase: in WinPE spesso lo trovi nel percorso del volume di sistema temporaneo, mentre nel sistema operativo completo può trovarsi sotto il percorso del client. Il dettaglio importante non è il path perfetto in astratto, ma sapere che il log segue il dispositivo lungo tutta la sequenza e racconta il punto esatto del fallimento.

In una sessione tipica conviene cercare tre cose: l’ultima azione avviata, il codice di errore restituito e il contesto immediatamente precedente. Se l’ultima riga utile parla di download fallito, il problema è quasi certamente di contenuto o connettività verso il DP. Se il log mostra che il passo successivo non viene nemmeno raggiunto, bisogna capire se c’è una condizione di pre-task sequence, un controllo su variabile, o una dipendenza non soddisfatta. Se il comando viene eseguito ma restituisce un exit code anomalo, allora il problema è nel programma chiamato, non nella sequenza in sé.

Un buon metodo è annotare sempre tre elementi: nome dell’azione, timestamp dell’errore, codice restituito. Senza questi dati si tende a fare ipotesi generiche. Con questi tre campi, invece, puoi confrontare il comportamento con esecuzioni precedenti e capire se il guasto è nuovo, intermittente o legato a un insieme specifico di macchine. È il modo più veloce per distinguere un errore sistemico da un caso isolato.

Se devi cercare una correlazione con il contenuto, verifica anche che la distribuzione sia realmente avvenuta sul Distribution Point giusto. In molti ambienti il problema nasce da un contenuto aggiornato ma non replicato, oppure da una boundary configuration che porta il client a un DP diverso da quello atteso. In quel caso il Task Sequence sembra “rotto”, ma sta semplicemente chiedendo un file che non trova nel punto corretto della rete.

WinPE, rete e driver: il trio che blocca l’avvio più spesso di quanto sembri

Se la Task Sequence non parte proprio, o si ferma all’inizio senza arrivare a una fase utile, la pista più probabile è WinPE. Qui i problemi classici sono driver mancanti, scheda di rete non riconosciuta, storage controller non supportato, oppure boot image non aggiornata dopo l’aggiunta dei driver. Il sintomo tipico è banale: il dispositivo avvia l’ambiente, ma non ottiene una connettività funzionale oppure non vede il disco su cui installare il sistema.

La verifica minima consiste nel controllare se il dispositivo in WinPE ha davvero accesso alla rete e al contenuto. Se non vede la rete, il problema non è la sequenza ma l’immagine di boot o il driver pack. Se vede la rete ma non il disco, il sospetto va al driver di storage. In entrambi i casi la correzione migliore è minima e reversibile: aggiungere il driver corretto alla boot image, rigenerare l’immagine, ridistribuirla e riprovare su un solo device di test prima di toccare la produzione.

Qui il rollback è semplice ma va comunque pensato: se aggiorni la boot image con nuovi driver, conserva la versione precedente e annota quali pacchetti sono stati aggiunti. In caso di regressione, puoi tornare alla build precedente senza dover ricostruire l’intero ambiente. Il blast radius è alto se la boot image è condivisa da più collezioni o da più flussi di provisioning, quindi ogni modifica va trattata come change controllato e non come correzione estemporanea.

Un’altra verifica utile è il tipo di avvio usato. PXE, media stand-alone e boot da ISO non si comportano allo stesso modo quando mancano driver o quando la rete è filtrata. Se il problema compare solo in uno di questi casi, non hai un guasto universale ma una dipendenza specifica del metodo di avvio. Questo dettaglio cambia molto la diagnosi e spesso evita di intervenire sul Task Sequence quando il vero problema è a monte.

Contenuto non disponibile: la causa più comune dopo il bootstrap

Quando la sequenza parte ma fallisce su uno step preciso, il contenuto è il primo sospettato. Un’applicazione, un package o uno script possono essere corretti nella definizione della sequenza ma irraggiungibili dal client. Il comportamento tipico è un download che si avvia e poi si interrompe, un messaggio di contenuto non trovato, oppure un errore che compare solo su determinate macchine o sedi.

Le verifiche immediate sono tre: il contenuto è distribuito al DP corretto, il client usa il boundary group atteso, e il file realmente esiste sul punto di distribuzione. Se uno di questi tre elementi manca, il problema è già spiegato. Non serve cambiare la logica della Task Sequence finché il contenuto non è accessibile in modo coerente.

Quando il contenuto esiste ma il download fallisce, la domanda successiva è se il problema è di autorizzazione, di rete o di integrità. Un file corrotto o una distribuzione incompleta possono produrre sintomi molto simili a una semplice mancata connessione. Per questo, prima di reimportare tutto, conviene verificare lo stato della distribuzione e confrontarlo con un package che sai funzionare. Se il contenuto di test passa e quello nuovo no, hai isolato il guasto senza cambiare nulla di più del necessario.

In ambienti con più DP, il comportamento può cambiare in base alla sede o al boundary mapping. È un classico: in laboratorio tutto funziona, in filiale no. In questi casi la diagnosi corretta non è “SCCM è instabile”, ma “il client sta ricevendo un percorso contenuto diverso da quello previsto”. La differenza è sostanziale, perché la correzione può essere una semplice sistemazione dei boundary group e non una revisione della sequenza.

Variabili, condizioni e step personalizzati: il punto dove gli errori silenziosi diventano costosi

Molte Task Sequence moderne non falliscono su componenti standard, ma su logica personalizzata. Variabili non valorizzate, condizioni troppo restrittive, branch che escludono dispositivi validi, o script che dipendono da uno stato non garantito sono tutti casi frequenti. Il problema è che questi errori possono sembrare “silenziosi”: la sequenza non si rompe subito, ma salta uno step, entra in un ramo sbagliato o prosegue con presupposti errati.

Qui il metodo migliore è leggere la sequenza come fosse un flusso decisionale. Ogni condizione dovrebbe avere una ragione chiara e una variabile verificabile. Se una variabile è valorizzata da uno step precedente, controlla che quel passaggio sia andato davvero a buon fine. Se una condizione dipende da modello hardware, versione OS o esito di un comando, verifica che il valore sia coerente con il device target. Senza questa lettura, il rischio è correggere lo step sbagliato.

La modifica minima e reversibile, in questi casi, è quasi sempre aggiungere logging o rendere più trasparente il passaggio incriminato, non riscrivere tutta la sequenza. Per esempio, prima di cambiare una condizione complessa, conviene rendere esplicito il valore della variabile usata come discriminante e riprovare su un solo client. Se il valore atteso non compare, hai un problema di upstream; se compare ma il ramo sbagliato viene comunque eseguito, la logica condizionale va rivista.

Questo approccio riduce molto il blast radius. Toccare una condizione in produzione può avere effetto su centinaia di client; aggiungere un controllo o un log temporaneo, invece, è una modifica più contenuta e più facile da annullare. Il rollback deve essere pianificato prima: salva lo stato originale della sequenza o esporta il contenuto della modifica in modo da poter tornare indietro senza ricostruire tutto a mano.

Client SCCM, policy e ciclo di valutazione: quando il problema è nel lato gestione

Se la Task Sequence si comporta in modo incoerente su macchine diverse, il problema può essere nel client più che nel contenuto. Un client non aggiornato, una policy non ancora ricevuta, un problema di comunicazione con il Management Point o una registrazione incompleta possono produrre sintomi intermittenti. In questo caso il Task Sequence non è necessariamente difettoso: semplicemente non riceve le istruzioni corrette o non riesce a recuperarle in tempo.

Il controllo più utile è verificare se il client risulta sano, se riceve policy e se il dispositivo compare correttamente nella console con lo stato atteso. Se la macchina è nuova o appena reimmaginata, il timing conta molto: a volte il problema non è la sequenza, ma il fatto che il client non ha ancora completato il ciclo necessario per rendere disponibili i contenuti o le istruzioni successive.

Quando il guasto è legato al client, la correzione minima è spesso un refresh della policy o la verifica della comunicazione con il server. Non bisogna però confondere un ritardo con un errore strutturale. Se dopo un tempo ragionevole il comportamento resta identico, allora la diagnosi cambia e bisogna tornare a guardare log, boundary, contenuto o step della sequenza. Anche qui il principio è non toccare più variabili del necessario.

Strategia di troubleshooting che evita falsi positivi

Una buona sequenza di troubleshooting segue sempre lo stesso ordine: osserva, isola, modifica poco, verifica, poi scala. In pratica, il percorso più efficiente è questo: prima leggi il log della macchina colpita, poi confronta il comportamento con un device noto funzionante, quindi cambia un solo elemento alla volta. Se modifichi boot image, contenuto e condizioni nello stesso momento, non saprai mai quale intervento ha davvero risolto o peggiorato il problema.

Per evitare falsi positivi, conviene usare un device di test rappresentativo: stesso modello, stessa sede, stesso tipo di avvio, stesso profilo di rete. Se il test riesce e la produzione no, il problema è nel contesto; se fallisce anche il test, hai un guasto riproducibile e quindi più facile da diagnosticare. È un passaggio banale ma spesso decisivo, soprattutto quando il problema sembra sporadico.

Un’altra abitudine utile è tenere traccia delle modifiche recenti: nuovi driver nella boot image, cambi di boundary group, aggiornamenti del contenuto, nuove condizioni nella sequenza, cambiamenti ai DP o al punto di distribuzione. Molti incidenti nascono da un cambiamento apparentemente innocuo che si manifesta solo su una nicchia di client. Senza una cronologia chiara, il troubleshooting diventa congettura.

Checklist operativa da usare prima di rifare la Task Sequence

Prima di rifare da zero una Task Sequence, conviene passare da una checklist concreta. Il vantaggio non è solo metodologico: spesso evita di cancellare indizi utili. Se il problema è riproducibile, raccogli questi elementi nell’ordine giusto: fase del fallimento, ultimo step eseguito, codice errore, stato del contenuto, disponibilità di rete, presenza dei driver necessari, comportamento del client e differenza tra device colpiti e device sani.

Se vuoi una sintesi pratica, la verifica minima è questa: il dispositivo arriva alla fase prevista, il contenuto è disponibile sul DP corretto, il log mostra un errore coerente, e la modifica proposta è reversibile. Se uno di questi punti manca, fermati e recupera il dato prima di procedere. È il modo più rapido per evitare interventi inutili e ridurre il rischio di peggiorare la situazione.

In sintesi operativa, il debugging di una Task Sequence in SCCM non è una caccia al messaggio più rumoroso, ma una diagnosi per strati. Prima individui il layer che rompe il flusso, poi confermi il dato con il log giusto, e solo dopo applichi la correzione minima. È così che si passa da un problema confuso a un fix ripetibile, senza trasformare un incidente di provisioning in un progetto di ricostruzione completa dell’ambiente.