Come integrare driver nell’ISO di Windows Server 2022

Quando ha senso integrare driver nell’ISO

Integrare driver in un’ISO di Windows Server 2022 serve quando il sistema non vede lo storage, la NIC, il controller RAID, il chipset o altri dispositivi già in fase di setup. È una pratica utile anche in ambienti datacenter e bare metal, dove vuoi un’installazione ripetibile e ridurre il lavoro manuale post-deploy.

La regola pratica è semplice: integra solo i driver che servono davvero durante l’installazione o al primo boot. Tutto il resto conviene distribuirlo dopo il setup, tramite GPO, SCCM/MECM, WSUS, script di provisioning o pacchetti del vendor.

Su Windows Server 2022 hai due strade principali:

• integrazione offline nel file `install.wim` con DISM;
• repack dell’ISO con strumenti che ricostruiscono il supporto d’installazione e aggiungono i driver in modo guidato.

La prima è la via più controllabile e auditabile. La seconda è comoda se devi fare operazioni ripetitive o vuoi un flusso più “wizard-based”, ma va sempre validata con attenzione.

Tipi di driver da valutare prima di toccare l’ISO

Non tutti i driver sono equivalenti. Quelli che impattano davvero l’installazione sono:

• Storage/RAID/NVMe: se mancano, il setup non vede dischi o volumi.
• NIC: utile se l’installazione dipende da repository di rete, PXE, unattend o post-install automatizzata.
• Chipset / controller specifici: in alcuni server OEM servono per enumerare correttamente bus e periferiche.
• Boot-critical: driver caricati nel percorso di avvio; qui il rischio di incompatibilità è più alto.

I driver puramente applicativi o periferiche secondarie non andrebbero messi nell’ISO. Meglio installarli dopo, quando il sistema operativo è già su disco e hai più controllo sul rollback.

Se il problema è “l’installer non vede il disco”, il driver giusto è quasi sempre storage/RAID/NVMe. Se il problema è “dopo l’installazione non c’è rete”, spesso conviene integrare la NIC solo se serve per automatizzare il setup; altrimenti installala a OS avviato.

Prerequisiti e controlli prima dell’integrazione

Prima di modificare l’ISO, verifica questi punti:

1. Firma del driver: usa driver WHQL o firmati dal vendor. Su Server 2022 il tema firma è sensibile, soprattutto per componenti kernel-mode.
2. Architettura corretta: x64 only, niente pacchetti x86.
3. Compatibilità con Server 2022: non basta che il driver funzioni su Windows 10 o 11. Serve compatibilità dichiarata o testata su Server 2022.
4. Formato del pacchetto: idealmente cartella con `.inf`, `.sys`, `.cat`. Se hai solo un `.exe`, estrailo prima.
5. Edizioni presenti nel WIM: spesso `install.wim` contiene più index. Devi sapere quale edizione stai modificando.

Per capire cosa c’è dentro il WIM:

DISM /Get-WimInfo /WimFile:D:
epackootoot.wim

e per l’immagine di installazione:

DISM /Get-WimInfo /WimFile:D:
epackuildilesootoot.wim

In alternativa, se hai già montato il supporto, controlla il contenuto in `sourcesoot.wim` e `sourcesoot.wim` del media sorgente. Il punto è evitare di lavorare alla cieca su un index sbagliato.

Metodo consigliato: integrazione offline con DISM

Questa è la procedura più pulita quando vuoi mantenere il massimo controllo. L’idea è montare il WIM, aggiungere i driver con DISM, smontare salvando le modifiche e poi ricostruire l’ISO.

Struttura di lavoro tipica:

• cartella sorgente ISO estratta in `D: epackase`;
• cartella driver in `D: epack drivers`;
• mount point in `D: epack empoot` e `D: epack empull`;
• output finale in `D: epack ewiso`.

Per aggiungere driver a un’immagine offline:

mkdir D:
epack	empoot

DISM /Mount-Wim /WimFile:D:
epackaseoot.wim /Index:2 /MountDir:D:
epack	empoot

DISM /Image:D:
epack	empoot /Add-Driver /Driver:D:
epack
drivers /Recurse

DISM /Unmount-Wim /MountDir:D:
epack	empoot /Commit

Per `install.wim` il flusso è analogo, ma devi scegliere l’index corretto:

mkdir D:
epack	empull

DISM /Mount-Wim /WimFile:D:
epackaseilesoot.wim /Index:1 /MountDir:D:
epack	empull

Se il tuo media usa `install.wim`, il comando corretto è sul file in `sourcesoot.wim` o `sourcesoot.wim`? No: attenzione, qui il supporto standard usa `sourcesoot.wim` per l’ambiente di setup e `sourcesoot.wim` non per l’OS finale. Il sistema operativo da installare è in `sourcesoot.wim`? No, il file corretto è `sourcesoot.wim` per WinPE e `sourcesoot.wim` non contiene l’immagine dell’OS. L’OS sta in `sourcesoot.wim`? No: il file da modificare per l’OS è `sourcesoot.wim`? Questa confusione va evitata: su media standard Windows, l’ambiente di setup è `sourcesoot.wim`, mentre l’immagine dell’OS è `sourcesoot.wim`? In pratica, verifica la struttura del media prima di montare: il file da usare per l’installazione è `sourcesoot.wim` soltanto se stai parlando di WinPE; per l’OS vero e proprio devi intervenire sul WIM presente in `sources` che contiene l’edizione di Windows Server. Il modo sicuro è elencare i file con:

dir D:
epackaseilesoot.wim

e controllare con `DISM /Get-WimInfo` quale WIM stai trattando. Se il media è personalizzato, il nome può cambiare: non dare per scontato il layout.

Per aggiungere driver al contenuto dell’OS, usa il WIM corretto e poi salva:

DISM /Image:D:
epack	empull /Add-Driver /Driver:D:
epack
drivers /Recurse

DISM /Unmount-Wim /MountDir:D:
epack	empull /Commit

Se vuoi evitare di includere driver non necessari, puoi puntare a una sottocartella specifica, per esempio solo il pacchetto RAID o solo la NIC.

Driver boot-critical: dove stare molto attenti

Il caso più delicato è il driver storage. Se integri un driver sbagliato puoi ottenere un setup che vede il disco ma fallisce in fase di avvio, oppure un sistema che parte solo in alcuni modelli di hardware. Qui il principio è: integra solo ciò che il vendor dichiara per il modello esatto e per Server 2022.

Se il driver è fornito in più varianti, preferisci il pacchetto destinato al controller preciso, non il “driver generico” aggregato. E se il vendor offre un pacchetto per WinPE/Setup separato da quello per il sistema operativo, usa quello corretto nel posto corretto.

Per verificare se il driver è stato caricato nel WIM montato, puoi usare:

DISM /Image:D:
epack	empoot /Get-Drivers

Atteso: il pacchetto compare nell’elenco con stato installato. Se non compare, il problema è quasi sempre il path sbagliato, il pacchetto non estratto correttamente o un `.inf` non valido.

Ricostruzione dell’ISO

Dopo aver modificato i WIM, devi ricostruire il supporto. Con gli strumenti Microsoft più comuni si usa l’ADK/OSCDIMG. Il flusso tipico è:

1. estrai l’ISO originale in una cartella di lavoro;
2. modifica i WIM con DISM;
3. ricrea l’ISO con `oscdimg` mantenendo il boot sector corretto;
4. testa l’immagine in VM prima di usarla in produzione.

Esempio di build con `oscdimg`:

oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bD:
epackaseootootsect.bin#pEF,e,bD:
epackaseootootsect.bin D:
epackase D:
epack
ewisouild
ew-server2022.iso

Il comando reale può variare in base a come è strutturato il media e al boot file disponibile. Il punto è non improvvisare con parametri di boot: se sbagli quel pezzo, l’ISO può diventare non avviabile anche se i driver sono stati integrati correttamente.

Metodo alternativo: tool di repack con interfaccia

Se preferisci un flusso guidato, puoi usare strumenti di repack che permettono di importare l’ISO, aggiungere driver, eventualmente integrare update e rigenerare il supporto. È una via pratica quando devi ripetere il processo più volte o quando l’operatore non vuole lavorare direttamente con DISM.

Il vantaggio è la rapidità operativa. Lo svantaggio è che nascondi parte della catena di trasformazione: per ambienti controllati o auditati, DISM resta più trasparente. Se usi un tool grafico, conserva sempre il progetto o i log di build e valida in VM il risultato.

In generale, il criterio non cambia: non integrare pacchetti “a caso” solo perché il tool lo consente. Aggiungi solo i driver necessari e documenta quali versioni hai usato.

Verifica in laboratorio prima del rilascio

La verifica non è opzionale. Prima di distribuire l’ISO a un team o in produzione, fai almeno questi test:

1. avvio in VM con firmware UEFI e, se serve, BIOS legacy;
2. verifica che il setup veda disco e rete;
3. installazione completa fino al login;
4. controllo in Gestione dispositivi che il driver sia presente senza warning;
5. controllo di Event Viewer per errori di driver o boot.

Comandi utili post-installazione:

driverquery /v

pnputil /enum-drivers

Atteso: il driver compare con provider, data e versione coerenti con il pacchetto integrato. Se il sistema installa ma poi mostra triangoli gialli o errori nel log, hai probabilmente integrato il pacchetto sbagliato o una versione non compatibile.

Problemi comuni e come leggerli

Il setup non vede il disco: quasi sempre driver storage/RAID mancanti o integrati nel WIM sbagliato. Verifica che il driver sia nel WIM di setup, non solo nell’immagine finale.

Il setup vede il disco ma fallisce al reboot: possibile conflitto con controller o boot-critical driver non adatto al modello.

La NIC non funziona dopo l’installazione: il driver è probabilmente corretto ma non necessario per il setup. Valuta se conviene installarlo dopo il primo boot invece di integrarlo nell’ISO.

DISM fallisce con errore di accesso o mount: spesso mount point sporco, WIM già montato o permessi insufficienti. Controlla `DISM /Get-MountedWimInfo` e pulisci solo dopo aver verificato che non ci siano mount attivi da altri processi.

L’ISO non boota: problema nel rebuild, non nei driver. Rivedi boot files e struttura UDF/ISO.

Strategia operativa consigliata

Se devi farlo in modo robusto, la sequenza migliore è questa:

1. identifica il driver minimo indispensabile;
2. scarica il pacchetto corretto per Server 2022 e architettura x64;
3. estrai i file `.inf`, `.sys`, `.cat` in una cartella pulita;
4. monta il WIM giusto;
5. aggiungi il driver con DISM;
6. smonta con commit;
7. ricrea l’ISO;
8. testa in VM;
9. solo dopo distribuisci.

Questo approccio riduce il rischio di introdurre driver inutili o incompatibili e ti lascia sempre un punto di rollback: l’ISO originale non toccata.

Rollback e tracciabilità

Il rollback più semplice è non sovrascrivere mai il media sorgente. Tieni tre elementi separati: ISO originale, cartella di lavoro e ISO finale. Se qualcosa va storto, elimini solo il build fallito e riparti.

Per tracciabilità minima, conserva:

• versione del driver;
• vendor e modello hardware;
• hash dell’ISO finale;
• log DISM della sessione;
• nota su quale WIM e quale index sono stati modificati.

Se l’operazione è destinata a un ambiente di produzione, aggiungi anche una prova di installazione in VM con lo stesso tipo di firmware e, se possibile, lo stesso controller virtuale o emulato del target.

Decisione pratica finale

Se il tuo obiettivo è sbloccare l’installazione su hardware specifico, integra solo il driver strettamente necessario, preferibilmente con DISM, e valida il risultato in laboratorio. Se invece vuoi una soluzione più facile da mantenere nel tempo, considera di spostare i driver runtime fuori dall’ISO e gestirli con un sistema di provisioning o con i pacchetti OEM post-installazione.

In altre parole: ISO personalizzata sì, ma solo per il minimo indispensabile. Più allarghi il set di driver, più aumenti il rischio di incompatibilità e manutenzione nel tempo.