Importare un file WIM acquisito in MDT

In MDT il punto non è “mettere dentro un file WIM”, ma farlo diventare una sorgente affidabile per le task sequence. Se il WIM arriva da un’acquisizione manuale o da una pipeline di build, il flusso corretto è sempre lo stesso: verificare l’immagine, importarla nel Deployment Share, aggiornare i boot image e poi controllare che la sequenza di deployment la veda davvero.

La differenza pratica tra un import fatto bene e uno fatto in fretta si vede nel momento del deploy: boot PE che non carica i driver giusti, immagine non selezionabile nella task sequence, oppure applicazione dell’immagine bloccata da un mismatch tra architettura, indice o contenuto del WIM. Per questo conviene trattare l’import come un cambio controllato, non come un semplice copia-incolla di file.

Prima di importare: cosa deve essere vero

Un WIM acquisito può andare bene anche se non è stato creato da MDT, ma deve rispettare alcuni requisiti minimi. Deve contenere un’immagine coerente con l’hardware e con il target di deploy, non deve essere corrotto e deve essere montabile o leggibile da DISM. Se questi tre punti non tornano, l’import in MDT diventa solo un modo più elegante di portarsi dietro un errore.

Controlla anche dove si trova il file. Se il WIM è su un share lento o instabile, l’import può riuscire ma l’aggiornamento della share e la generazione dei boot image diventano fragili. In ambienti con più operatori, conviene avere una cartella di staging separata dalla struttura finale di MDT, così il file viene validato prima di entrare nella libreria ufficiale del deployment share.

Se ti manca una di queste informazioni, non procedere alla cieca: verifica indice, architettura e stato del file con DISM prima di aprire MDT.

Verifica rapida del WIM con DISM

Il controllo più utile è quello che ti dice subito se l’immagine è leggibile e cosa contiene. Su una macchina con Windows ADK installato, usa DISM per leggere gli indici disponibili nel WIM.

DISM /Get-WimInfo /WimFile:"D:\Staging\install.wim"

Se il comando restituisce gli indici, la versione, l’architettura e il nome dell’immagine, il file è almeno coerente a livello strutturale. Se invece ottieni errori di accesso, hash o file non valido, il problema non è MDT: va risolto prima di importare. In pratica, il risultato atteso è una lista leggibile di una o più immagini; il risultato KO è un errore di parsing o un file non riconosciuto.

Se il WIM contiene più indici, annota quello corretto. È un errore comune importare il file pensando che MDT scelga automaticamente la build giusta. MDT importa il file, ma poi la task sequence deve puntare all’indice o alla raccolta giusta, altrimenti il deploy applica un’immagine diversa da quella attesa.

Importare il WIM nel Deployment Share di MDT

La strada più pulita è importare il file come Operating System dentro il Deployment Share. Dalla console di Deployment Workbench, entra nel tuo share, apri Operating Systems e scegli l’import del file immagine.

1. Apri Deployment Workbench.
2. Espandi il tuo Deployment Share.
3. Vai su Operating Systems.
4. Tasto destro su Operating Systems e scegli Import Operating System.
5. Seleziona Custom image file quando il WIM è già acquisito.
6. Indica il percorso del file, ad esempio D:\Staging\install.wim.
7. Completa la procedura e assegna un nome descrittivo alla cartella di destinazione interna a MDT.

Questa scelta è importante: Custom image file è l’opzione giusta quando hai un WIM già pronto, non quando vuoi importare un ISO o una sorgente di installazione. Se selezioni il tipo sbagliato, il risultato è spesso una struttura di lavoro confusa, con file duplicati o non coerenti con il tipo di deployment che vuoi fare.

Durante l’import, MDT copia il WIM nella propria struttura, di norma sotto la cartella del deployment share dedicata al sistema operativo. Il file non resta “solo” nel percorso originale: viene inglobato nel repository del progetto, così da avere una sorgente stabile e versionabile. È qui che conviene usare nomi chiari, con data o build number, invece di etichette generiche come “Windows10” o “WIM nuovo”.

Se il file è grande, l’operazione può richiedere tempo. Non forzare la chiusura della console se non sei sicuro che il processo sia bloccato. Prima controlla l’attività disco e la presenza del file nella cartella di destinazione. L’errore più fastidioso è interrompere un import a metà e ritrovarsi con una struttura parzialmente scritta.

Import via share locale o via percorso UNC

Se lavori in team, il file spesso arriva da un file server. In quel caso puoi puntare a un percorso UNC, ma solo se la rete è stabile e i permessi sono corretti. L’import da share è comodo, però espone a due problemi classici: credenziali insufficienti e disconnessioni durante la copia.

Un approccio più robusto è questo: copia prima il WIM in una cartella di staging locale sul server dove gira MDT, verifica il file, poi importalo dal disco locale. In questo modo separi il problema di rete dal problema di formato. Se l’import fallisce da locale, sai che l’origine è il file; se fallisce solo da share, il collo di bottiglia è la connettività o i permessi.

Una verifica minima dei permessi sul percorso di staging può essere fatta così:

dir "D:\Staging\install.wim"
icacls "D:\Staging\install.wim"

Se il file non è leggibile dal servizio o dall’account che esegue l’operazione, l’import si interrompe o produce errori poco utili. In ambienti ben tenuti, la share di staging ha permessi di sola lettura per i team che preparano i pacchetti e scrittura solo per chi pubblica le build finali.

Aggiornare le boot image dopo l’import

Importare il WIM non basta. Se la task sequence deve partire in WinPE, devi aggiornare i boot image di MDT, altrimenti rischi di avviare un ambiente che non conosce i driver necessari o che non riflette le modifiche più recenti della share.

1. In Deployment Workbench, tasto destro sul Deployment Share.
2. Scegli Update Deployment Share.
3. Seleziona almeno la generazione dei boot image richiesta dal tuo scenario.
4. Verifica che vengano rigenerati i file LiteTouchPE_x64.wim e, se serve, LiteTouchPE_x86.wim.

Se usi driver injection, questo passaggio è ancora più importante. Un WIM importato correttamente ma avviato con un WinPE senza driver di rete o storage ti lascia fermo prima ancora di vedere l’elenco delle task sequence. Il sintomo non è nell’import, ma nel bootstrap dell’ambiente di preinstallazione.

Per una verifica rapida, controlla che i file di boot siano stati aggiornati nel percorso del deployment share. In molte installazioni si trovano sotto una struttura simile a \DeploymentShare\Boot\, con timestamp coerenti rispetto all’ultimo update. Se il timestamp non cambia, l’update non è andato a buon fine o non ha rigenerato l’immagine che ti aspetti.

Collegare il WIM alla task sequence

L’import dentro MDT crea la sorgente, ma non la usa automaticamente. Devi aprire la task sequence e puntarla all’immagine corretta. Qui si vede spesso l’errore di processo: il WIM è stato caricato, ma la sequenza continua a riferirsi a una vecchia build o a un altro indice.

1. Apri la task sequence interessata.
2. Controlla il passo di applicazione dell’immagine.
3. Verifica che il riferimento punti al WIM importato di recente.
4. Se il WIM ha più indici, assicurati che l’indice selezionato sia quello giusto.

Nel dubbio, fai una prova in lab con un target pulito. Il criterio di successo è semplice: la task sequence deve applicare l’immagine, completare il deploy e arrivare al primo login o al primo punto di check previsto. Se il deploy parte ma fallisce a metà, il problema potrebbe non essere il WIM, ma i driver, lo spazio disco o il contenuto post-installazione.

Quando il WIM è generato da un sistema già personalizzato, evita di trattarlo come una golden image immutabile. Documenta sempre da quale macchina, build e data è stato catturato. Un file chiamato solo install.wim non ti aiuta a capire se contiene una build vecchia, un test fallito o una release pronta per produzione.

Importazione da WIM acquisito: differenze rispetto a una sorgente standard

Con una sorgente standard, MDT importa file di installazione e li organizza in modo abbastanza prevedibile. Con un WIM acquisito, invece, ti porti dietro anche lo stato del sistema da cui è stato catturato. Questo significa che driver, app preinstallate, configurazioni locali e persino residui di personalizzazione possono entrare nel ciclo di deployment se non hai fatto pulizia prima della cattura.

Per questo, un WIM acquisito è utile quando vuoi distribuire uno stato controllato e ripetibile, non quando vuoi sostituire una normale installazione standard senza criterio. Se l’obiettivo è solo installare Windows e aggiungere applicazioni via task sequence, una sorgente pulita spesso è più manutenibile. Se invece hai bisogno di una baseline già predisposta, il WIM acquisito ha senso, ma va governato bene.

Un dettaglio che molti sottovalutano è il peso del WIM nel tempo. Ogni volta che lo aggiorni con una nuova acquisizione, aumenta il rischio di accumulare versioni vecchie e non più tracciate. La soluzione pratica è versionare il nome del file e tenere una nota esterna con origine, checksum e data di import. Non serve complicarsi la vita, serve solo sapere quale immagine stai realmente distribuendo.

Controlli di qualità dopo l’import

Dopo l’import, non limitarti a vedere il nome nel nodo Operating Systems. Fai almeno tre controlli: il file esiste nella struttura di MDT, la task sequence lo vede e il boot image è stato rigenerato senza errori.

1. Verifica il file nella cartella del deployment share, ad esempio sotto la struttura del sistema operativo importato.
2. Apri la task sequence e controlla che il riferimento alla sorgente sia corretto.
3. Controlla il log di update del deployment share, in genere sul server MDT, per eventuali errori di generazione dei boot image.

Se vuoi un controllo più rigoroso, esegui un deployment di prova su una VM. È il modo più veloce per separare un problema di importazione da un problema di compatibilità hardware. Una VM che fallisce nello stesso punto di una macchina fisica, con driver diversi, di solito ti dice che il problema sta nella sequenza o nell’immagine, non nel ferro.

Se invece il deploy in VM va a buon fine ma su hardware reale no, il sospetto si sposta su driver di storage, rete o firmware UEFI/BIOS. In quel caso il WIM è probabilmente sano e il collo di bottiglia è nella fase di preboot o nell’hardware target.

Errori tipici e come leggerli senza perdere tempo

Il primo errore classico è il WIM corrotto o incompleto. Si manifesta già nel controllo con DISM o durante la copia nel deployment share. Il secondo è il mismatch tra architettura e boot image: importi un WIM x64, ma il WinPE non è aggiornato o non ha i driver giusti. Il terzo è il riferimento errato nella task sequence, dove il file è presente ma non selezionato nel punto corretto del flusso.

Se l’import sembra riuscito ma il file non compare dove ti aspetti, guarda la struttura del deployment share e il log di importazione. MDT tende a essere abbastanza lineare: se qualcosa non torna, quasi sempre lascia traccia nel log o nel percorso di destinazione. Non saltare direttamente alle modifiche della task sequence senza aver verificato che il file sia stato davvero copiato e indicizzato.

Se lavori in un ambiente con più versioni di Windows, il rischio maggiore non è tecnico ma organizzativo: importare una build corretta nel posto sbagliato. Per evitare confusione, separa le raccolte per famiglia di sistema operativo, usa naming convention coerenti e non sovrascrivere mai un WIM “di produzione” con uno di test.

Procedura sintetica che funziona in pratica

1. Conferma che il WIM sia leggibile con DISM /Get-WimInfo.
2. Copia il file in una cartella di staging locale sul server MDT.
3. Importa il WIM come Custom image file nel nodo Operating Systems.
4. Aggiorna il Deployment Share e rigenera i boot image.
5. Collega il WIM alla task sequence corretta.
6. Fai un test di deploy in VM prima di toccare i client reali.

Questa sequenza riduce gli errori perché separa i problemi di file, di MDT e di target. È più lenta di un import fatto al volo, ma in cambio ti evita di scoprire il difetto quando il servizio è già in finestra di manutenzione e i client stanno aspettando.

Quando il WIM non è la scelta giusta

Non tutti i casi richiedono un WIM acquisito. Se devi distribuire sistemi standard con configurazioni gestite a valle, spesso è meglio partire da una sorgente pulita e applicare personalizzazioni via task sequence, script o strumenti di management. Il WIM acquisito ha senso quando la baseline è realmente stabile e vuoi replicarla senza passaggi intermedi.

Se il contenuto del WIM cambia spesso, l’immagine diventa difficile da mantenere. A quel punto il deployment basato su immagine catturata rischia di trasformarsi in un collo di bottiglia operativo. In questi scenari è più sano spostare la logica fuori dall’immagine e ridurre il WIM a un punto di partenza, non a un contenitore di tutto il sistema.

In sintesi operativa, l’import di un WIM acquisito in MDT non è complicato, ma va trattato come una catena di verifiche: file valido, import corretto, boot image aggiornato, task sequence coerente e test finale. Se uno di questi passaggi manca, il problema non è “MDT che non funziona”, è quasi sempre un controllo saltato a monte.