Come acquisire i log della Task Sequence SCCM dopo l’OSD

Il punto chiave: dopo l’OSD i log non stanno più dove te li aspetti

Con SCCM/MECM la Task Sequence lascia tracce utili in più punti, ma durante e dopo l’OSD il file di log “giusto” cambia posizione. Se cerchi solo in C:\Windows\CCM\Logs rischi di perdere la parte più interessante: la fase di WinPE, la transizione al sistema operativo installato e gli errori che avvengono prima che il client sia davvero operativo.

La regola pratica è semplice: in OSD devi distinguere tra log del pre-boot, log della sequenza in esecuzione e log del client già installato. Il contenitore cambia, ma il criterio resta lo stesso: capire in quale fase è fallita la Task Sequence e poi recuperare i file da quel layer, non da una cartella fissa per abitudine.

Dove cercare i log in base alla fase

Durante il boot in WinPE, il riferimento principale è X:\Windows\Temp\SMSTSLog. È il posto da controllare quando la TS si ferma prima dell’avvio del sistema operativo o durante i primi step di imaging. Se la macchina ha già passato il passaggio al disco locale, il percorso tipico diventa C:\_SMSTaskSequence\Logs\Smstslog\smsts.log oppure una delle sue varianti sotto C:\Windows\CCM\Logs, a seconda di come è stata configurata la cattura dei log e della versione del client.

Se il client è già installato e la Task Sequence è arrivata alla fase finale, puoi trovare elementi utili anche in C:\Windows\CCM\Logs\smsts.log. Però, in pratica, il log di riferimento rimane quasi sempre smsts.log: cambia solo il percorso in cui lo trovi. Questo è il primo punto che evita ore perse a rincorrere file “scomparsi”.

Come leggere il percorso corretto senza andare a tentativi

Il modo più veloce è guardare il contesto della fase in cui sei bloccato. Se sei in WinPE, apri il prompt con F8 se abilitato e verifica le unità montate. Di solito il disco non è ancora C:, quindi non assumere nulla. Una volta identificata la lettera corretta, cerca la cartella _SMSTaskSequence o il log in X:\Windows\Temp\SMSTSLog.

Se invece il PC ha già completato il reboot e il problema emerge quando il sistema operativo è su desktop, usa C:\Windows\CCM\Logs e verifica anche C:\Windows\CCM\Logs\smsts.log con un visualizzatore che supporti il live tail o il refresh automatico. In ambienti reali, la differenza tra “non c’è” e “è in un altro volume” è spesso solo una lettera di unità assegnata in modo diverso durante l’imaging.

Acquisizione rapida dei log da WinPE

Se la macchina è ancora in WinPE, la raccolta più pulita è copiare i log su una share di rete o su una chiavetta, così non perdi il contenuto quando il disco viene riformattato o la sessione si chiude. Prima verifica che la rete sia attiva e che il mapping abbia privilegi minimi sufficienti in sola lettura/scrittura verso la destinazione di raccolta.

Un flusso pratico è questo: apri il prompt, individua la lettera della share o del supporto esterno, poi copia la cartella dei log completa. Se il file è ancora in uso, meglio copiare l’intera directory invece del singolo file, così non perdi i file di supporto e gli eventuali log ruotati.

net use Z: \\server\share /user:DOMINIO\utente
xcopy X:\Windows\Temp\SMSTSLog Z:\OSD-logs\SMSTSLog /E /H /I /Y

Se il percorso corretto non è su X:, sostituisci la lettera con quella reale rilevata in WinPE. Se la share richiede credenziali, usa un account dedicato alla raccolta, con permessi limitati alla sola cartella di destinazione. Non usare account amministrativi se non è necessario: qui il rischio non è tecnico ma operativo, perché i log OSD spesso contengono nomi host, percorsi, eventuali token temporanei e dettagli di infrastruttura che non vanno sparsi inutilmente.

Raccolta da sistema avviato: il caso più comodo

Quando il device arriva a Windows, la strada più semplice è aprire il log con CMTrace o con un editor che evidenzi i timestamp e permetta il refresh. In molte installazioni CMTrace è già presente sul client o nel toolkit SCCM. Se non lo hai, puoi comunque copiare smsts.log e analizzarlo da una macchina amministrativa.

Il vantaggio del sistema avviato è che puoi anche raccogliere i log correlati: execmgr.log, smsexec.log, clientlocation.log, locationservices.log e, se il problema è di contenuto distribuito, distmgr.log lato server. La Task Sequence raramente fallisce da sola: spesso è un sintomo di boundary, contenuto non distribuito, driver mancanti o step condizionali che non matchano il device.

Se la TS fallisce prima del reboot: cosa guardare davvero

I fallimenti precoci hanno quasi sempre una firma chiara nel log: download del boot image, applicazione del driver package, accesso ai contenuti, errore di partizionamento o fallimento del comando di prestart. In questi casi non serve inseguire il client: il problema è prima. Cerca stringhe come failed to run the action, content not found, download failed o task sequence execution engine failed.

Se trovi un errore generico, la riga immediatamente precedente è quasi sempre più utile del codice finale. Molti operatori guardano solo l’error code e ignorano il contesto: è il modo più rapido per perdere tempo. In OSD la riga che precede l’errore ti dice spesso quale package, quale path o quale step ha innescato il guasto.

Se il log dice “access denied” ma il contesto è un mapping verso una share, il problema non è sempre la password: può essere anche il tipo di autenticazione, la presenza di SMB signing, o un permesso mancante sulla cartella di destinazione.

Portare fuori i log senza sporcare il sistema

In ambito operativo conviene standardizzare l’export. La raccolta manuale su desktop locale funziona, ma in produzione è fragile: il device può riavviarsi, il disco può essere ripartizionato, il profilo può non esistere ancora. Meglio prevedere una share centralizzata, una naming convention e una cartella per ticket o per hostname, così il log arriva già ordinato.

Un metodo pulito è copiare l’intero set di file in una directory strutturata per data e host. Se vuoi essere rapido, crea un archivio compresso solo dopo aver verificato che i file siano stati copiati correttamente. La compressione non sostituisce la raccolta: la rende solo più gestibile.

mkdir Z:\OSD-logs\PC12345
copy X:\Windows\Temp\SMSTSLog\smsts.log Z:\OSD-logs\PC12345\smsts.log

Se il log è ruotato o frammentato, copia anche i file con suffissi numerici o le directory collegate al task sequence engine. In diversi ambienti il file principale non basta da solo: i messaggi utili possono stare nei segmenti precedenti o nei log di contesto generati nello stesso minuto.

Quando il percorso non coincide con quello atteso

La confusione più comune nasce dalle differenze tra versioni del client, configurazioni della TS e stato del sistema al momento del fallimento. Se il percorso “classico” non esiste, non improvvisare: verifica la presenza di _SMSTaskSequence su tutte le unità montate, controlla se la macchina è in WinPE e cerca i log nei mount point attivi. Se hai accesso alla console, confronta anche la configurazione del passaggio dei log verso il sistema operativo, perché alcune impostazioni spostano il file in una posizione diversa da quella che ti aspetti.

Un altro caso frequente è il device che ha già eseguito il primo reboot ma non ha ancora completato la fase di installazione del client. In quel momento puoi avere sia i residui del pre-boot sia i log del sistema appena installato. Qui vale la pena scaricare tutto il blocco temporale intorno al fallimento, non solo il file singolo: ti evita di inseguire un errore che in realtà nasce cinque minuti prima.

Analisi veloce: cosa estrarre dal log per arrivare alla causa

Per fare triage in modo utile, annota sempre quattro elementi: timestamp dell’errore, step della TS, codice di errore e risorsa coinvolta. Con questi quattro dati puoi già capire se sei davanti a un problema di contenuto, di rete, di storage o di script. Senza questi riferimenti, il log diventa solo rumore testuale.

Se l’errore è intermittente, controlla se cambia sempre nello stesso step o se migra. Se migra, spesso il problema è ambientale: rete, driver, timing, dipendenza da hardware. Se è sempre identico, il problema è più probabilmente nel contenuto della Task Sequence o nel package richiamato da quello step.

Una procedura operativa che funziona in pratica

Quando ricevi un device bloccato in OSD, il flusso più razionale è questo: prima identifichi la fase, poi trovi il percorso del log, quindi lo copi fuori in modo sicuro, e solo dopo inizi a fare ipotesi sulla causa. Saltare direttamente alla correzione è il modo più veloce per cambiare tre variabili insieme e non capire quale abbia davvero risolto o rotto il processo.

1. Verifica se sei in WinPE o in Windows completo.
2. Individua il percorso del log corretto per quella fase.
3. Copia smsts.log e i file correlati su una share o su supporto esterno.
4. Apri il log con un viewer che mostri timestamp e contesto immediato.
5. Correla l’errore con il relativo step della Task Sequence e con i log di supporto.

Questo approccio è più solido del classico “cerco l’errore nel log” perché ti obbliga a preservare il contesto. Nei problemi OSD il contesto è metà della diagnosi: senza di esso un codice di errore può sembrare generico anche quando non lo è affatto.

Buone pratiche per non perdere i log al prossimo giro

Se gestisci spesso Task Sequence, conviene predisporre una raccolta standard: share dedicata, permessi minimi, naming coerente e, se possibile, una fase della TS che sposti automaticamente i log al termine. In questo modo non dipendi dall’intervento manuale dell’operatore nel momento peggiore, cioè quando il client è appena stato ripartizionato o il sistema è in uno stato parziale.

È utile anche mantenere una piccola checklist interna: percorso atteso in WinPE, percorso atteso dopo il reboot, log correlati lato client e lato server, e un punto di raccolta centralizzato. Non è burocrazia: è il modo più economico per evitare che ogni incidente OSD diventi un esercizio di archeologia digitale.

Infine, ricordati che i log OSD sono spesso sensibili dal punto di vista operativo. Contengono riferimenti a host, share, domini, package e talvolta dettagli utili a un attaccante interno o a chi ha accesso improprio ai file di troubleshooting. Conserva solo ciò che serve, limita l’accesso alla cartella di raccolta e rimuovi i file quando il caso è chiuso.

In sintesi operativa

Per acquisire correttamente i log della Task Sequence SCCM dopo l’OSD non devi cercare “il” percorso unico, ma il percorso coerente con la fase in cui si è fermato il device. WinPE, post-reboot e client completo hanno punti diversi, ma il file chiave resta smsts.log. Se lo raccogli con metodo, il debug diventa rapido e ripetibile; se lo insegui a vista, perdi tempo e contesto.