SCCM OSD: come risolvere l’errore disco di sistema non trovato

SCCM OSD: quando il disco di sistema “sparisce”

In un task sequence SCCM, l’errore “system disk not found” quasi mai significa che il disco sia davvero guasto. Più spesso indica che WinPE non vede il controller, vede il disco ma non lo considera avviabile, oppure la sequenza sta cercando il volume sbagliato nel momento sbagliato. La differenza è pratica: se individui il layer giusto, eviti di rifare l’intera immagine e riduci il tempo perso su tentativi a vuoto.

Il punto da tenere fermo è questo: durante l’OSD il problema può stare in BIOS/UEFI, nel driver storage, nel layout del disco o nella task sequence stessa. Se il disco non compare in WinPE, non ha senso guardare subito il sistema operativo finale. Se invece il disco compare, ma la sequenza fallisce quando deve applicare il boot image o partizionare, la causa è quasi sempre nella configurazione del profilo di avvio o nel modo in cui SCCM identifica l’unità.

Il sintomo non basta: va separato in quattro casi

Prima di toccare la task sequence, conviene classificare il comportamento osservato. In pratica, l’errore si presenta in quattro forme ricorrenti:

• WinPE non vede nessun disco nel passaggio di partizionamento.
• Il disco è visibile, ma la task sequence fallisce con riferimento al sistema non trovato o al volume non disponibile.
• Il disco viene visto solo dopo aver caricato un driver manualmente.
• Il disco è presente, ma il firmware espone un layout diverso tra modalità legacy e UEFI.

Questa distinzione conta perché cambia il punto di intervento. Un disco invisibile in WinPE è quasi sempre un problema di driver o di modalità controller. Un disco visibile ma “non valido” è più spesso un problema di partizionamento o di selezione del disco nella sequenza. In ambiente eterogeneo, con modelli diversi e storage NVMe/SATA/RAID misti, il caso peggiore è assumere che la causa sia unica: di solito non lo è.

Controllo minimo: capire dove si rompe il flusso

La verifica più utile è sempre la più semplice: apri la console di WinPE e controlla se il disco esiste davvero dal punto di vista del pre-boot environment. Il comando classico è diskpart. Se il disco non compare qui, il problema è prima di SCCM. Se compare, il problema è nella task sequence o nel mapping del disco.

diskpart
list disk
exit

Se list disk mostra solo il supporto USB o il disco virtuale del media di boot, ma non l’SSD/NVMe interno, hai già la risposta: WinPE non ha il driver giusto o il controller è impostato in una modalità non supportata. Se invece il disco c’è, annota numero, dimensione e tipo di partizione: sono i primi indizi per capire se la sequenza sta puntando all’unità corretta.

Il secondo controllo utile è il log della sequenza. In genere il file da cercare è smsts.log; il percorso cambia a seconda della fase, ma in WinPE spesso si trova sotto X:\Windows\Temp\SMSTSLog o in una cartella equivalente del supporto di avvio. Non serve leggere tutto il file: cerca le righe che parlano di disk, partition, formatting, apply OS e boot. È lì che compare il motivo reale del blocco.

findstr /i /c:"disk" /c:"partition" /c:"apply" /c:"boot" X:\Windows	emp	slog\smsts.log

Se il log non è nel percorso atteso, non è un problema: il punto non è quel path specifico, ma il fatto che il log vada trovato nel WinPE e letto prima di cambiare configurazione. In molti casi basta capire se l’errore arriva durante il “Format and Partition Disk” oppure più avanti, quando la task sequence cerca di installare il boot loader.

Driver storage: il colpevole più frequente su hardware recente

Su macchine moderne il primo sospetto resta il driver del controller. NVMe, Intel RST, VMD, RAID firmware e alcuni controller SATA in modalità “ibrida” possono essere invisibili al WinPE standard se l’immagine non include il pacchetto corretto. Il classico errore è caricare il driver nel sistema operativo finale ma dimenticare che il problema nasce prima, nel boot image.

Qui la regola è semplice: il driver deve stare nel boot image, non solo nel content del sistema operativo. Se il controller è visto solo dopo un caricamento manuale, la prova è forte: il package è disponibile, ma non è stato iniettato nel WinPE usato dalla task sequence. In ambiente SCCM questo spesso si risolve aggiornando il boot image con il driver storage corretto e rigenerando il media, non toccando il deploy del sistema operativo.

La verifica pratica è immediata: se il disco appare dopo un drvload o dopo il caricamento manuale del file .inf, hai falsificato l’ipotesi “disco guasto”. A quel punto non serve cambiare hardware. Serve invece allineare WinPE al controller reale della macchina.

drvload X:	emp
aidoo.inf
list disk

Se il disco compare solo dopo questo passaggio, il fix strutturale è incorporare quel driver nel boot image SCCM e distribuirlo ai distribution point interessati. Il rischio operativo è basso, ma il blast radius va tenuto sotto controllo: un boot image modificato può impattare più collezioni e più modelli di macchina. Prima di pubblicarlo in produzione, testa su un device rappresentativo e conserva una copia del boot image precedente per un rollback rapido.

UEFI, legacy e partizionamento: il disco c’è, ma non è “quello giusto”

Un altro scenario classico è il disco visibile ma la sequenza che fallisce subito dopo il partizionamento. Qui il problema non è più vedere il disco, ma farlo corrispondere al tipo di boot previsto. Se la macchina parte in UEFI e la task sequence usa un layout MBR, o viceversa, il boot finale fallirà anche se il disco è stato formattato senza errori apparenti.

La verifica è doppia: controlla la modalità firmware nel BIOS/UEFI e confrontala con le opzioni della task sequence. In UEFI serve GPT con partizioni EFI e MSR; in legacy servono impostazioni coerenti con MBR. Se la sequenza sta tentando di installare il sistema su un disco che non è il primo enumerato da WinPE, può comparire un errore che l’operatore interpreta come “disco non trovato”, ma in realtà è un disallineamento nel mapping.

Qui il comando utile resta diskpart, perché ti fa vedere come WinPE sta leggendo il disco. Se il disco è presente ma il layout non coincide con la policy della task sequence, non serve reinstallare il driver: va corretto il profilo di partizionamento. In molti ambienti conviene standardizzare il firmware su UEFI puro e adeguare il TS una volta sola, invece di mantenere eccezioni legacy che poi generano errori intermittenti.

Task sequence SCCM: i punti in cui si sbaglia più spesso

Quando il problema è nella sequenza, i punti fragili sono abbastanza prevedibili. Il primo è l’azione di formattazione: se il disco selezionato non è quello fisico corretto, la sequenza può applicare il layout a un volume sbagliato oppure non trovare il disco atteso. Il secondo è il passaggio di applicazione dell’immagine, quando il sistema si aspetta una partizione di destinazione già preparata. Il terzo è il boot loader, che fallisce se la partizione EFI o la partizione di sistema non sono state create come previsto.

Per isolare il punto esatto, non modificare tutto insieme. Disabilita temporaneamente solo il blocco che applica l’OS e lascia attivo il partizionamento: se il disco viene creato correttamente, sai che il problema è più avanti. Se invece il fallimento arriva prima, la causa è nel mapping o nel driver. Questo approccio riduce il rumore diagnostico e ti evita di confondere un problema di boot con un problema di accesso al disco.

Un errore sottovalutato è l’uso di condizioni troppo rigide nella sequenza, per esempio variabili che dipendono dal modello hardware o dal tipo di storage. Se una variabile non viene valorizzata, la task sequence può saltare il ramo corretto e tentare di usare un disco inesistente. In questo caso il log mostra spesso che l’azione non viene eseguita nel ramo atteso, non che il disco sia fisicamente assente.

Mitigazione rapida: far ripartire l’OSD senza cambiare mezzo parco

Se il problema blocca più postazioni, la mitigazione migliore è la più reversibile: usa un boot image aggiornato con il driver storage corretto e limita il test a un gruppo ristretto di dispositivi. In parallelo, verifica se il firmware della macchina è bloccato in una modalità non coerente con il TS. Non fare un cambio massivo di configurazione BIOS senza un motivo forte: il rischio è spostare il problema da un modello all’altro.

Se hai controllo sul deployment, una strada pragmatica è creare un ramo di task sequence dedicato al modello problematico. È meno elegante di una sequenza universale, ma spesso è il modo più veloce per rimettere in servizio il parco mentre si lavora al fix strutturale. Il blast radius resta contenuto e il rollback è semplice: torni alla TS precedente o al boot image stabile.

Questa è la parte che vale più di qualsiasi teoria: prima fai ripartire il flusso, poi normalizzi. Con OSD, inseguire la perfezione prima del ripristino operativo spesso prolunga solo il fermo macchina.

Fix strutturale: rendere il problema ripetibile e quindi eliminabile

Una volta individuata la causa, il fix serio consiste nel togliere variabilità. Se il problema è il driver, includilo nel boot image e documenta il modello hardware a cui si applica. Se è il layout del disco, uniforma UEFI e schema GPT. Se è la task sequence, correggi le condizioni, i riferimenti alle variabili e il disco target. Se il problema è misto, separa i modelli in profili di deploy diversi invece di forzare una sequenza unica per tutto.

Conviene anche lasciare un minimo di audit operativo: versione del boot image, driver aggiunti, data di pubblicazione e modello testato. Non serve un documento lungo; basta poter risalire velocemente a cosa è cambiato quando il problema ricompare. In ambienti SCCM maturi, la differenza tra “funziona” e “si rompe dopo tre settimane” è quasi sempre la tracciabilità del change.

Un’ultima nota pratica: se il parco è misto e include piattaforme con VMD o controller storage recenti, non aspettare l’incidente per aggiornare il boot image. Mantieni una baseline di WinPE allineata ai modelli effettivamente in uso. È un lavoro noioso, ma è meno costoso che fermare l’OSD nel momento in cui serve distribuire una nuova build.

Checklist operativa da usare sul campo

Quando il problema si presenta, questa è la sequenza minima che evita giri inutili:

1. Apri WinPE e verifica il disco con diskpart e list disk.
2. Se il disco non compare, controlla driver storage e modalità firmware.
3. Se il disco compare, leggi smsts.log e identifica il passaggio esatto del fallimento.
4. Se il fallimento è sul partizionamento, confronta UEFI/legacy con lo schema usato dalla task sequence.
5. Se il disco appare solo dopo il caricamento manuale del driver, aggiorna il boot image e ripubblicalo.
6. Se il problema è limitato a un modello, separa il flusso in una TS dedicata o in un ramo condizionato.

Il vantaggio di questa checklist è che porta rapidamente da un sintomo generico a una causa tecnica verificabile. Non risolve ogni caso possibile, ma evita il classico errore di cambiare tre cose insieme senza sapere quale abbia avuto effetto.

Chiudere il cerchio: cosa controllare dopo il fix

Dopo la correzione, il controllo non deve fermarsi al fatto che l’installazione parta. Verifica che il disco venga partizionato secondo standard, che il sistema completi il primo boot e che il log non contenga più errori relativi a storage o boot loader. Se possibile, valida il risultato su almeno un secondo modello dello stesso gruppo hardware: ti dice subito se hai risolto la causa o solo un sintomo locale.

Se hai aggiornato il boot image, conserva il precedente fino a fine verifica. È il rollback più rapido in caso di regressione. Se hai modificato la task sequence, esporta o annota il delta prima di rilasciare. Se hai toccato il firmware, documenta esattamente quale opzione è stata cambiata, perché il vero rischio non è solo rompere l’OSD: è introdurre un comportamento diverso su una parte del parco e accorgersene troppo tardi.

In sintesi, l’errore “disco di sistema non trovato” in SCCM OSD va trattato come un problema di catena, non come un singolo guasto. Prima si identifica il layer, poi si applica la correzione minima, infine si stabilizza il processo. È il modo più veloce per passare da un blocco di deploy a un ambiente prevedibile.