Lunedì mattina, ore 8:00. Un sistemista senior di una media azienda italiana riceve l'ordine di preparare l'immagine per 200 nuovi laptop in arrivo per il reparto vendite. Pensa di risparmiare tempo scaricando l'ultima versione disponibile del pacchetto Microsoft e installando tutto, convinto che "più strumenti ho, meglio è". Tre giorni dopo, si ritrova con una flotta di macchine che non eseguono il boot PXE, driver di rete che mandano il sistema in crash dopo l'anteprima OOBE e un task sequence in Configuration Manager che fallisce misteriosamente al 40%. Ha perso 72 ore di produttività aziendale perché non ha capito che Windows Assessment and Deployment Kit ADK non è un software "avanti-avanti-fine", ma un ecosistema di versioni specifiche che devono incastrarsi come un orologio svizzero con la build del sistema operativo di destinazione. Se sbagli la versione o dimentichi il componente WinPE separato, che da qualche anno non è più incluso nel pacchetto principale, hai appena comprato un biglietto di sola andata per un fine settimana di straordinari non pagati.
L'illusione che l'ultima versione di Windows Assessment and Deployment Kit ADK sia sempre la migliore
Il primo errore che vedo commettere costantemente è la corsa all'aggiornamento. C'è questa idea sbagliata secondo cui scaricare l'ultimo installer disponibile dal sito Microsoft risolva i bug delle versioni precedenti. Non funziona così. Ho visto interi reparti IT bloccati perché avevano installato l'estensione per Windows 11 su un ambiente che doveva ancora distribuire immagini di Windows 10. Il risultato? Script di personalizzazione che smettono di funzionare perché certi parametri DISM sono stati deprecati o modificati.
Il disastro della retrocompatibilità mancata
Quando scegli il set di strumenti, devi guardare esclusivamente alla build del sistema operativo che vuoi distribuire, non a quella del PC da cui stai lavorando. Se provi a catturare un'immagine di una vecchia versione di Windows 10 usando gli strumenti pensati per le versioni più recenti di Windows 11, rischi di corrompere il registro di sistema durante la fase di sysprep. Non è un'ipotesi, succede. La soluzione non è installare tutto, ma creare macchine virtuali isolate per ogni progetto di deployment, ognuna con la versione specifica del kit necessaria per quel lavoro. Mischiare le versioni sulla stessa workstation è il modo più rapido per sporcare le variabili d'ambiente e trovarsi con comandi che restituiscono errori criptici come lo 0x80070002 senza una spiegazione logica.
Dimenticare che WinPE è diventato un corpo estraneo
Fino a qualche anno fa, scaricavi il pacchetto e avevi tutto. Poi Microsoft ha deciso di separare l'ambiente di pre-installazione. L'errore fatale oggi è installare il core del sistema e dare per scontato che sia pronto all'uso. Senza il componente aggiuntivo Windows PE, i tuoi strumenti di creazione supporti non produrranno nulla di avviabile.
Ho assistito a una scena quasi comica in un'azienda di logistica: avevano configurato tutto l'ambiente di imaging, ma quando provavano a creare la chiavetta USB di avvio, il software si chiudeva senza errori. Avevano passato ore a controllare i permessi della cartella, quando il problema era semplicemente l'assenza del componente WinPE. Devi scaricare due file separati, installarli nell'ordine corretto e verificare che le cartelle dei componenti siano popolate prima di lanciare qualsiasi comando di personalizzazione dell'immagine. Se non vedi la cartella "Windows Preinstallation Environment" sotto il percorso di installazione, sei fermo al palo e non te ne sei nemmeno accorto.
L'abuso dei driver nell'immagine boot di Windows Assessment and Deployment Kit ADK
C'è questa mania di iniettare ogni driver possibile e immaginabile dentro l'immagine di boot (boot.wim). Pensate che così il PC riconoscerà tutto subito. Sbagliato. Più driver carichi nel WinPE, più l'immagine diventa pesante, lenta da caricare via rete e, soprattutto, instabile. Ho visto immagini di boot che pesavano 2 GB perché contenevano driver video, audio e persino quelli delle stampanti. È una follia tecnica.
L'ambiente di avvio ha bisogno solo di due tipi di driver: storage e network. Se il PC vede il disco fisso e comunica con il server, il resto del lavoro deve essere fatto dal sistema operativo completo, non dal kit di pre-installazione. Ogni driver in più che aggiungi è una potenziale collisione. Se carichi un driver di rete Intel più recente sopra uno standard incluso, potresti scoprire che il boot PXE fallisce solo su certi modelli di laptop perché il driver "nuovo" non gestisce correttamente il protocollo di handshaking del tuo switch. Mantieni l'immagine di boot snella. Meno roba c'è, meno roba può rompersi.
La gestione pessima del file Unattend.xml
Molti pensano che il file di risposta sia solo una lista di domande a cui rispondere in automatico. In realtà, è il cuore della tua automazione e sbagliare una singola riga o una fase di configurazione (come la pass 4 o la pass 7) distrugge l'intera installazione. L'errore classico è usare un file xml creato anni prima per una versione diversa di Windows e limitarsi a cambiare il nome del computer.
Lo scenario reale del prima e dopo la correzione
Immaginiamo una situazione tipica. Prima dell'intervento, il tecnico utilizza un file Unattend.xml generico copiato da un forum online. Quando distribuisce l'immagine, il processo si ferma alla schermata di scelta della lingua, chiede comunque di accettare la licenza e, cosa peggiore, non crea l'account utente locale richiesto. Il tecnico deve passare 15 minuti su ogni PC per finire la configurazione a mano. Moltiplicato per 50 PC, sono più di 12 ore di lavoro manuale sprecato.
Dopo aver pulito il processo, il tecnico usa lo strumento Windows SIM incluso nel kit per generare un file di risposta validato per la build specifica. Inserisce correttamente i parametri "SkipOOBE" e "SkipUserOOBE", configura le partizioni del disco in modo che siano conformi allo standard UEFI anziché al vecchio BIOS Legacy e imposta il fuso orario corretto. Al lancio del deployment, i PC partono, caricano l'immagine e arrivano direttamente alla schermata di login senza che nessuno debba toccare un tasto. Il tempo di intervento umano scende da 15 minuti a zero. Questa è la differenza tra usare uno strumento e saperlo padroneggiare.
Ignorare i log di DISM e puntare al buio
Quando un comando di cattura o applicazione immagine fallisce, la maggior parte delle persone prova a rilanciare lo stesso comando sperando in un risultato diverso. È una perdita di tempo. Ogni volta che interagisci con un file WIM tramite questi strumenti, viene generato un file di log in C:\Windows\Logs\DISM\dism.log. Se non sai leggere quel file, non stai facendo deployment professionale, stai solo tirando a indovinare.
Il log ti dice esattamente quale file è corrotto, quale driver non è stato firmato digitalmente e impedisce l'iniezione, o se lo spazio su disco è insufficiente per le operazioni temporanee. Ho risolto problemi in dieci minuti leggendo i log che altri avevano tentato di risolvere per due giorni reinstallando tutto da zero. Non aver paura della verbosità di quei file; cerca le parole "Error" o "Warning" e troverai la risposta al tuo problema di installazione.
Lo sbaglio di non testare il caricamento degli aggiornamenti offline
Molti preparano l'immagine, la sigillano con sysprep e poi si lamentano che il PC appena acceso deve scaricare 4 GB di aggiornamenti da Windows Update. Pensano che aggiornare l'immagine di base sia troppo complicato o rischioso. In realtà, il rischio è lasciare che 200 PC intasino la banda aziendale contemporaneamente il primo giorno.
Il processo corretto prevede l'iniezione dei pacchetti MSU e CAB direttamente nel file WIM spento, usando il montaggio della cartella. Questo ti permette di avere un'immagine già patchata all'ultimo mese disponibile senza dover mai accendere una macchina virtuale per fare gli aggiornamenti manuali. Chi non usa questa tecnica sta consegnando un prodotto non finito. È come consegnare una macchina nuova senza benzina e con le gomme sgonfie, dicendo al cliente che può gonfiarsele da solo alla prima stazione di servizio.
Reality check: cosa serve davvero per non fallire
Smettiamola di raccontarci favole. L'automazione del deployment non è un'attività "imposta e dimentica". Richiede una manutenzione costante che la maggior parte delle aziende non è disposta a fare finché non scoppia un disastro. Se pensi che basti configurare il kit una volta e usarlo per i prossimi tre anni senza toccarlo, ti sbagli di grosso. Microsoft rilascia aggiornamenti semestrali che cambiano il comportamento dei componenti interni, rimuovono funzionalità o introducono nuovi requisiti di sicurezza come il TPM 2.0.
Per avere successo, devi accettare che passerai il 20% del tuo tempo solo a tenere aggiornato l'ambiente di test. Se non hai una macchina dedicata esclusivamente alla creazione delle immagini, isolata dal resto della rete e con istantanee (snapshot) pronte per tornare indietro quando un aggiornamento rompe qualcosa, non sei pronto. Non esiste una configurazione perfetta universale; esiste solo quella che funziona per il tuo specifico hardware e per le tue specifiche licenze. La documentazione ufficiale è un punto di partenza, ma la vera competenza la costruisci rompendo le immagini e imparando a ripararle dai log di errore. Se non sei disposto a leggere file di testo lunghi migliaia di righe per capire perché un driver non si è caricato, forse questo lavoro non fa per te. Non c'è gloria nel deployment, c'è solo l'efficienza invisibile di un processo che funziona mentre tu sei a prenderti un caffè, sapendo che i tuoi PC si stanno configurando da soli esattamente come avevi previsto.
