Copiare il log SMSTS in caso di errore della task sequence

Copiare il log SMSTS quando una task sequence fallisce

Quando una task sequence di Microsoft Endpoint Configuration Manager, MDT o un deployment OS fallisce, il file più utile da controllare è quasi sempre smsts.log. Il problema pratico non è trovarlo in teoria, ma recuperarlo in tempo utile: la posizione cambia in base alla fase della task sequence, al contesto di avvio e al sistema operativo presente. Se il PC non arriva al desktop, se il disco è stato riformattato o se la macchina è rimasta in WinPE, il log va copiato con un metodo che funzioni anche in condizioni degradate.

Il punto chiave è questo: non aspettare di avere una GUI funzionante. Appena una task sequence fallisce, conviene individuare il layer in cui si è fermata, leggere il log nel percorso corretto e copiarlo in una destinazione persistente, idealmente una share di rete o un supporto rimovibile. In questo modo si evita di perdere il file quando il riavvio, il refresh del disco o il cleanup della sequenza cancellano gli artefatti temporanei.

Dove si trova davvero smsts.log

La posizione del log dipende dallo stato della macchina. Non esiste un unico path valido in ogni fase. Durante l’esecuzione in WinPE, il file è spesso in X:\Windows\Temp\SMSTSLog\smsts.log oppure in X:\SMSTSLog\smsts.log se è stato reindirizzato. Dopo l’avvio del sistema operativo, il log tende a comparire in C:\_SMSTaskSequence\Logs\Smstslog\smsts.log oppure in una directory simile sotto C:\Windows\CCM\Logs in base al client e alla versione del deployment.

Se la task sequence usa il reindirizzamento del log, il path può essere configurato in modo esplicito. In molti ambienti si imposta una directory persistente, ad esempio su C:\SMSTSLog o su una share di rete montata in WinPE. Se non sai quale path aspettarti, il modo meno fragile è cercare il file con una scansione mirata delle unità disponibili.

Metodo rapido da WinPE

Se la task sequence fallisce prima che Windows sia operativo, il recupero va fatto da WinPE. Qui il problema tipico è che le lettere delle unità non coincidono con quelle che avresti in un sistema avviato normalmente. Prima di copiare qualsiasi cosa, identifica le volumi disponibili e verifica dove si trova il log.

Il primo controllo è semplice: apri una console con F8 se abilitata nella boot image, poi usa diskpart o dir per capire quali volumi sono montati.

diskpart
list volume
exit

Se vedi una partizione con i file della task sequence o una share mappata, prova a cercare il log nelle posizioni comuni.

dir X:\Windows\Temp\SMSTSLog\smsts.log
 dir X:\SMSTSLog\smsts.log
 dir C:\_SMSTaskSequence\Logs\Smstslog\smsts.log

Se il file esiste, copialo in una destinazione sicura. Una share di rete è la scelta migliore, perché sopravvive al reboot e non dipende dal disco locale che potrebbe essere riformattato dalla stessa task sequence.

net use Z: \\server\share /user:DOMAIN\utente
copy X:\Windows\Temp\SMSTSLog\smsts.log Z:\hostname-smsts.log

Se WinPE non ha connettività, verifica che i driver di rete siano caricati e che l’indirizzo IP sia stato ottenuto. In molte situazioni il fallimento non è nel log, ma nel fatto che la share non è raggiungibile.

ipconfig
ping server
wpeutil InitializeNetwork

Copiare il log da Windows già avviato

Se il sistema operativo arriva al desktop ma la task sequence ha comunque fallito, il recupero è più semplice. In questo caso puoi usare PowerShell o Esplora file, ma conviene comunque essere precisi sul path. Il rischio più comune è copiare un log vecchio o quello di un’altra esecuzione.

Un controllo utile è confrontare la data di modifica del file con l’orario del fallimento. Se il timestamp non coincide, stai guardando il log sbagliato oppure la task sequence ha scritto in un altro percorso.

Get-ChildItem C:\ -Filter smsts.log -Recurse -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, LastWriteTime -First 5

Una volta identificato il file corretto, copialo in una cartella locale o su una share con un nome che includa hostname e data. Questo evita sovrascritture quando devi raccogliere più casi.

$src = "C:\_SMSTaskSequence\Logs\Smstslog\smsts.log"
$dst = "C:\Temp\$env:COMPUTERNAME-smsts.log"
Copy-Item $src $dst -Force

Se devi spostarlo su rete, usa una destinazione scrivibile e verifica i permessi prima di automatizzare. Un errore classico è avere la share raggiungibile ma non autorizzata per l’account che esegue il comando.

Test-Path \\server\share
New-Item -ItemType Directory -Path "\\server\share\logs" -ErrorAction SilentlyContinue
Copy-Item $src "\\server\share\logs\$env:COMPUTERNAME-smsts.log" -Force

Recupero automatico con script di supporto

In ambienti gestiti conviene avere uno script pronto da eseguire appena la sequenza fallisce. L’obiettivo non è fare forensics completa, ma raccogliere il file giusto nel minor tempo possibile. Lo script deve essere conservativo: cerca il log, lo copia e lascia traccia dell’operazione. Niente cancellazioni, niente modifiche al sistema, niente assunzioni aggressive sul path.

Un esempio essenziale in PowerShell può cercare in più percorsi noti e fermarsi al primo file trovato. È più affidabile di un path fisso quando lavori su dispositivi con versioni diverse di client o task sequence differenti.

$paths = @(
  "C:\_SMSTaskSequence\Logs\Smstslog\smsts.log",
  "C:\Windows\CCM\Logs\smsts.log",
  "X:\Windows\Temp\SMSTSLog\smsts.log",
  "X:\SMSTSLog\smsts.log"
)

$found = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1
if ($found) {
  Copy-Item $found "C:\Temp\$env:COMPUTERNAME-smsts.log" -Force
  Write-Host "Copied from $found"
} else {
  Write-Host "smsts.log not found"
}

Se il tuo ambiente usa una share centralizzata, puoi aggiungere un secondo step che tenta la copia in rete solo se la connessione è disponibile. Questo riduce i fallimenti secondari e ti lascia comunque una copia locale da prelevare manualmente in seguito.

Se la task sequence muore prima di scrivere il log utile

Non tutti i fallimenti producono un log completo. Se il problema è molto precoce, ad esempio WinPE senza driver, errore di boot image, DNS assente o storage non visto, il file può essere parziale. In questi casi il valore del log è comunque alto, perché spesso mostra l’ultimo step eseguito, il codice di errore e il punto esatto in cui la sequenza ha smesso di progredire.

Se il file è troncato, non forzare ipotesi. Cerca l’ultima riga utile, confronta timestamp e step della sequenza, poi verifica gli eventi correlati: rete, storage, driver, download del contenuto. Il log da solo raramente basta; serve incrociarlo con altri segnali come il contenuto delle cartelle temporanee, la presenza di variabili TS e il comportamento del client durante il provisioning.

Rendere persistente la raccolta del log

Se gestisci molte installazioni, la soluzione migliore è prevenire la perdita del log. Il pattern più solido è reindirizzare o copiare smsts.log verso un percorso persistente già nelle prime fasi della sequenza. In questo modo, anche se il disco viene ripulito o la fase successiva fallisce, il file resta disponibile.

In Microsoft Endpoint Configuration Manager puoi agire sulla task sequence o sul client, a seconda del caso d’uso. La scelta va fatta con attenzione: una destinazione locale è più semplice, ma una share di rete è più utile per il troubleshooting centralizzato. La share però introduce dipendenza da rete, autenticazione e permessi.

Se scegli la rete, verifica almeno questi punti: accesso in lettura/scrittura, DNS funzionante in WinPE, driver NIC inclusi nella boot image e spazio disponibile sul target. Se invece scegli il disco locale, verifica che il percorso non venga cancellato da step successivi della task sequence o da un refresh del sistema operativo.

Checklist pratica per non perdere il log

Prima di chiudere il caso, conviene avere una checklist ripetibile. L’obiettivo è ridurre il tempo tra il fallimento e la raccolta del file, senza improvvisare ogni volta.

1. Identifica il layer del fallimento: WinPE, download contenuto, applicazione immagine, post-install, join dominio o primo boot.
2. Controlla il path del log nel contesto attuale e non assumere che sia sempre lo stesso.
3. Copia subito il file in una destinazione persistente con nome univoco.
4. Se il file non esiste, verifica rete, lettere unità, permessi e timestamp.
5. Conserva anche i log correlati, non solo smsts.log, se il problema non è evidente.

Un dettaglio spesso trascurato è il naming del file copiato. Se usi solo smsts.log, il secondo caso sovrascrive il primo. Meglio includere hostname, data e ora, ad esempio PC-1234-2026-04-11-1430-smsts.log. Così puoi confrontare più tentativi senza ambiguità.

Interpretare il log dopo la copia

La copia del file non è il punto finale, è l’inizio dell’analisi. Cerca l’ultima riga con successfully completed, failed, error o il codice numerico restituito dallo step. Se compare un errore di download, controlla DP, boundary, contenuto distribuito e accesso alla rete. Se il problema è nel passaggio da WinPE a Windows, verifica driver di storage, boot image e modifiche al disco.

Quando il log mostra errori generici, non fermarti al codice. Spesso il messaggio immediatamente precedente è quello utile: ad esempio un file mancante, un percorso non trovato, una variabile non valorizzata o un timeout su una condivisione. In ambienti grandi, il vero risparmio di tempo nasce dal riuscire a recuperare il log in modo standardizzato, non dal cercare l’interpretazione perfetta al primo colpo.

Esempio operativo completo

Scenario tipico: una task sequence fallisce in WinPE dopo il download del contenuto. Il sistema si riavvia o resta bloccato prima dell’installazione. La prima cosa da fare è aprire la console, verificare la rete e copiare il log dalla directory WinPE. Se la share è raggiungibile, il file viene salvato centralmente e puoi aprirlo subito da un workstation amministrativa. Se la share non c’è, lo copi su un supporto locale e lo analizzi dopo aver riavviato il dispositivo.

Questo flusso è robusto perché segue una logica semplice: individuare il file, preservarlo, poi analizzarlo. È molto meglio di tentare subito correzioni alla task sequence senza evidenza, perché rischi di cambiare più variabili insieme e perdere il nesso causale tra sintomo e causa.

Nota operativa finale

Se vuoi un processo affidabile, prepara in anticipo un piccolo kit di troubleshooting: boot image con F8 abilitato, share di raccolta log, script di copia testato e convenzione di naming coerente. È una banalità solo finché non hai dieci macchine ferme e un solo file utile da recuperare. Assunzione: l’ambiente usa task sequence Microsoft con accesso amministrativo al client o alla boot image, e il recupero del log è consentito dalle policy interne.