Desktop fileGuida per utenti esperti su WIM e ImageX

Wes Miller

Questo articolo è basato su una versione non definitiva di Windows Automated Installation Kit (WAIK) e Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

La tecnologia ImageX e il formato WIM (Windows Imaging) sono stati illustrati in molti articoli precedenti. In Tech•Ed alcuni mesi fa ho avuto modo di ascoltare alcuni commenti e domande di professionisti IT che avevano iniziato a utilizzare Windows Deployment Services (WDS), ImageX e Windows Automated Installation Kit (WAIK) che mi hanno fatto riflettere sulla

necessità di maggiori delucidazioni in merito a questi argomenti. Nell'articolo di questo mese l'attenzione verrà pertanto focalizzata principalmente su ImageX e sul formato WIM e verrà illustrato come sfruttare al meglio queste tecnologie. ImageX e WIM consentono di semplificare la distribuzione sono solo di Windows Vista® e Windows Server® 2008, ma anche di Windows® XP, Windows Server 2003 e Windows 2000.

Modifiche apportate a WAIK

È possibile che molti utenti si domandino quali siano le implicazioni del rilascio della nuova versione di Windows Server 2008, disponibile a breve, per WAIK. Microsoft intende distribuire una versione aggiornata di WAIK nell'intervallo di tempo previsto per il rilascio della prossima versione di Windows Server 2008. Non sono previste modifiche significative al formato WIM (lo strumento ImageX e il formato restano invariati); anche WDS per Windows Server 2003 non subirà alcuna modifica. Contrariamente alle voci che corrono, il multicast non sarà disponibile per i server WDS che eseguono Windows Server 2003; solo i server WDS che eseguono Windows Server 2008 disporranno della nuova funzionalità di distribuzione multicast per WDS.

Windows PE 2.0 e il programma di installazione di Windows verranno modificati in modo da garantire il supporto per quanto riportato di seguito:

• Distribuzione di Windows Server 2008 e Windows Vista
• Distribuzione multicast tramite WDS da un server WDS per Windows Server 2008
• Distribuzione delle versioni x64 e x86 di Windows Vista e Windows Server 2008 da Windows PE x86.

Innanzitutto, questo implica che Windows PE 2.0 sarà in grado di distribuire Windows Server 2008 con la stessa facilità con cui garantisce la distribuzione di Windows Vista: per entrambi i tipi di distribuzione è possibile utilizzare gli stessi strumenti e processi. Secondo, una volta installato Windows Server 2008 nei server WDS, sarà possibile utilizzare la distribuzione multicast tramite WDS. Infine, questo supporto implica la possibilità di utilizzare un disco di Windows PE 2.0 x86 e distribuire da tale disco un'immagine x86 o x64 di Windows.

Ho menzionato quest'ultimo punto in Tech•Ed nella mia sessione su Windows x64. Sfortunatamente sembra esistere molta confusione su questo punto nei blog e nella community tecnica di Windows. Questo non significa che Microsoft distribuirà Windows x64 e Windows x86 su ogni DVD di Windows Vista o Windows Server 2008, né che è necessario combinare le immagini di Windows x64 e Windows x86 in un singolo file WIM (sebbene sia possibile). L'esecuzione di un'operazione di questo tipo, sebbene consenta di trasmettere il formato WIM come un singolo file, non consentirà di realizzare alcun risparmio in termini di archiviazione a istanza singola.

L'implicazione più significativa di questo supporto è rappresentata dal fatto che i clienti aziendali e gli OEM che hanno dedicato anni allo sviluppo di processi di distribuzione basati su 86 (oltre che di strumenti e script personalizzati) ora saranno in grado di distribuire Windows x86 o x64 dall'interno di WIM mediante il programma di installazione a 32 bit, venendo incontro in tal modo a una richiesta avanzata dai clienti aziendali sin da quando Windows x64 è stato rilasciato per la prima volta nel 2005.

Esecuzione di attività quotidiane con ImageX

Utilizzo di /mount, /mountrw e /delete

Di seguito sono riportati alcuni importanti suggerimenti per l'utilizzo delle opzioni /mount, /mountrw e /delete con ImageX:

• Montare un volume con /mountrw se si intende modificarlo.
• È consigliabile montare un file WIM in una directory vuota, semplicemente per eliminare eventuali confusioni dai file archiviati in tale directory e impedire che in ImageX venga generato un messaggio di avviso non necessario.
• Ricordare inoltre di utilizzare i comandi /unmount /commit per eseguire il montaggio o il commit delle immagini di lettura/scrittura nel caso in cui si desideri salvare le modifiche apportate. Mi è capitato di frequente di aver apportato delle modifiche ma di aver dimenticato di eseguirne il commit (e di conseguenza le modifiche sono andate perse).
• L'eliminazione di file tramite /mountrw e di immagini del volume tramite /delete non consentirà di risparmiare spazio, ma al contrario potrebbe richiedere l'utilizzo di una maggiore quantità di spazio. Per ulteriori dettagli, vedere la sezione di questo articolo relativa a /export.
• È possibile montare un singolo file WIM una sola volta per l'accesso in lettura/scrittura. Due utenti non possono modificare lo stesso file WIM contemporaneamente così come non è possibile modificare contemporaneamente due immagini del volume.
• Anche in modalità di sola lettura (/mount), è consigliabile limitare il numero di immagini del volume montate simultaneamente in quanto il driver è dipendente dalla quantità di memoria del pool non di paging di Windows disponibile nel sistema per ciascuna immagine montata. Questo introduce una limitazione sul numero di immagini da utilizzare, che potrebbe variare in base al sistema (o all'architettura del sistema). È consigliabile non tentare di utilizzare più di cinque immagini contemporaneamente.
• L'esecuzione di modifiche significative tramite /mountrw richiede pochissimo tempo, mentre il commit delle modifiche apportate tramite /commit potrebbe richiedere una notevole quantità di tempo in quanto è necessario comprimere e archiviare tutti i nuovi dati dei file.
• Prestare particolare attenzione quando si utilizzano /delete e /mountrw in quanto, una volta eseguito il commit delle modifiche, non è possibile annullarle.
• Non è possibile eseguire /delete se è presente una sola immagine del volume in un file WIM (è possibile invece eliminare l'intero file WIM o aggiungere un'altra immagine del volume).
• Per ottenere rapidamente una struttura di directory del contenuto di un'immagine del volume, utilizzare in luogo di /mount il seguente comando:

ImageX /dir <path_to_wim_file> <image index>

• Se si stanno modificando due file WIM contemporaneamente, è consigliabile non eseguirne lo smontaggio contemporaneamente tramite /unmount; organizzare in sequenza gli eventi di montaggio/smontaggio in modo che non si blocchino reciprocamente.

ImageX è stato progettato specificatamente per effettuare il mirroring della modalità di utilizzo degli strumenti da parte di OEM e clienti aziendali. Il processo viene descritto nella Figura 1.

Figura 1** Utilizzo di ImageX **

Notare che il passaggio 5 riveste un'importanza fondamentale in quanto mette in rilievo che un'immagine viene modificata continuamente. È necessario pertanto che le operazioni di acquisizione e modifica dell'immagine vengano eseguite nel modo più rapido e semplice possibile.

A tal fine, è possibile aggiungere un'ulteriore immagine (mediante l'opzione /append) all'immagine già creata. Inizialmente, il team di sviluppo pensò che fosse utile poter aggiungere un'ulteriore SKU (versione di Windows) all'immagine precedente; tuttavia, collaborando a stretto contatto con i clienti aziendali nelle fasi iniziali del processo di sviluppo di Windows Vista, ho avuto modo di scoprire che l'immagine aggiuntiva veniva utilizzata per distribuire rapidamente X e successivamente acquisire di nuovo X1 in cui si erano apportate alcune delle modifiche riportate nel passaggio 2. Era dunque possibile riacquisire rapidamente l'immagine, poiché si era modificato solo un numero limitato di file.

Quando il team comprese questo, giunse alla conclusione che conservare l'immagine originale poteva non essere utile in tutti i tipi di situazioni. Più avanti in questo articolo verrà illustrata l'opzione /export che è stata aggiunta specificamente per soddisfare le esigenze di questo scenario e di quello successivo.

Modifiche costanti

Il team di sviluppo decise immediatamente che era necessario che i file WIM fossero modificabili. Poiché aveva già deciso che un formato di imaging basato su settore non avrebbe funzionato (per un'eventuale spiegazione vedere l'articolo di dicembre all'indirizzo technetmagazine.com/issues/2006/12/DesktopFiles), il team si trovò di fronte alla necessità di fornire una soluzione che consentisse di montare facilmente i file in modo nativo come parte del file system di Windows e apportare modifiche alle immagini del volume montate nel file WIM. Questo ha avuto come conseguenza la disponibilità di un maggior numero di "componenti mobili", come amo definirli. Il montaggio di un'immagine basata su settore è relativamente semplice, mentre il montaggio di un formato di archiviazione proprietario, come WIM, ha richiesto l'utilizzo di strumenti molto specifici.

Il formato richiedeva l'accesso dal prompt dei comandi, escludendo le estensioni shell di Windows comunemente utilizzate per gestire i file ZIP e CAB in modo nativo. Sfortunatamente, questi gestori consentono solo a Esplora risorse l'accesso astratto a un oggetto.

Di conseguenza, la soluzione WIM prevede un driver (wimfltr.sys) e lo strumento ImageX, che viene utilizzato per caricare il driver e gestire l'interfaccia per il montaggio del file WIM. Il driver viene utilizzato per aggiungere un'astrazione al file system di Windows, come illustrato nella Figura 2. Quando si esegue un comando come uno di quelli riportati di seguito, si indica a ImageX di caricare il driver wimfltr.sys e di impostare il driver in modo che si sovrapponga alla prima immagine del volume (corrispondente a 1 nei comandi utilizzati in questo articolo) nella directory di montaggio vuota, come illustrato di seguito:

Figura 2** Montaggio di un'immagine del volume WIM **(Fare clic sull'immagine per ingrandirla)

ImageX /mount iso\sources\boot.wim 1 mount 
ImageX /mountrw iso\sources\boot.wim 1 mount 

Questo è il comportamento predefinito in WAIK. Pertanto, quando si esplora o si genera un elenco di directory nella directory di montaggio, è possibile visualizzare la directory radice dell'immagine del volume 1 in boot.wim. Naturalmente, l'utilizzo di /mountrw o /mount determinerà se questa directory è di sola lettura o di lettura/scrittura (per informazioni dettagliate vedere l'intestazione laterale "Utilizzo di /mount, /mountrw e /delete").

La funzionalità /mountrw è stata originariamente progettata per aggiungere con facilità driver e altri file o contenuti copiabili, impostare i file di risposta o modificare il Registro di sistema non in linea di un file WIM montato per modificarlo in base alle esigenze (vedere la Figura 3). Non è stata progettata per aggiungere o rimuovere intere applicazioni (in quanto le applicazioni installate in MSI non possono essere installate in modalità non in linea).

Figura 3** Modifica di un file WIM montato **(Fare clic sull'immagine per ingrandirla)

È fondamentale capire che quando si apportano modifiche al file WIM dopo che è stato montato, non si modifica direttamente il file WIM effettivo (almeno non immediatamente) ma si modifica una cache del file WIM che rappresenta in realtà un'unione della sovrapposizione e delle modifiche apportate. Sono stato colpito da questo in precedenza, come illustrato nell'intestazione laterale. Assicurarsi di utilizzare, dopo aver apportato le modifiche, le opzioni /unmount e /commit, in quanto solo in tal caso verrà eseguito il commit delle modifiche nel file WIM. In caso contrario, le modifiche andranno completamente perse.

Quando si salvano le modifiche apportate grazie al commit, si indica al driver di eseguire le modifiche nello stesso file WIM. Il driver aggiunge i nuovi dati dei file. Tenere presente che se si sono apportate numerose modifiche, il commit potrebbe richiedere una significativa quantità di tempo, in quanto l'aggiunta dei dati dei file al file WIM viene eseguita solo nel corso di tale operazione.

Inoltre, a differenza del formato di imaging basato su settore, è possibile che si sia modificato solo uno o più file nell'immagine del volume. Di conseguenza, i file non si presentano più nel formato a istanza singola (a meno che non siano già stati memorizzati una volta) e i dati dei file originali andranno persi. In WIM, a differenza del volume NTFS o FAT, un file non viene contrassegnato come eliminato; sebbene non vi venga più fatto riferimento, il file non viene eliminato. Di conseguenza, se si apportano modifiche frequenti tramite /mountrw o si aggiungono numerose immagini tramite /append oppure si utilizza /delete per eliminare un'immagine del volume, questa operazione consente al file WIM solo di ignorare i riferimenti ai dati dei file, ma non determina l'eliminazione dei dati dei file correlati.

Pertanto il team di sviluppo ha creato l'opzione /export, nota anche come "utilità di deframmentazione WIM".

Esportazione

Note importanti per /export

Quando l'opzione /export viene utilizzata per creare un nuovo file WIM, è possibile specificare il tipo di compressione da utilizzare anziché accettare il tipo di compressione predefinito correntemente utilizzato. Se si imposta un tipo di compressione differente da quello correntemente utilizzato, l'esportazione potrebbe richiedere una notevole quantità di tempo.

Quando utilizzata come /append (aggiungendo un'immagine del volume a un file WIM esistente), l'opzione /export non consente di modificare l'attributo /compression del file WIM.

È possibile specificare l'opzione /boot se si esporta un'immagine del volume di Windows PE 2.0 completamente nuova.

L'opzione /export è stata creata per soddisfare le esigenze di entrambi gli scenari menzionati in precedenza e un paio di altri scenari meno comuni scoperti dal team. In poche parole, /export consente di acquisire un'immagine del volume esistente (o anche più immagini) e di esportarla. Il risultato è la rapida acquisizione del file WIM X e X1 sopra riportato e la creazione di un nuovo file WIM contenente X, solo X1 o X1 e Y1, eseguendo l'esportazione da un altro file WIM.

Si immagini uno scenario in cui vengono apportate modifiche a X e tali modifiche vengono aggiunte tramite /append come X1. A un certo punto si decide di eliminare X in quanto la si è sostituita con una nuova immagine. È possibile utilizzare l'opzione /delete in modo da rimuovere l'immagine X da ImageX. Tuttavia, per risparmiare spazio eliminando tutte le informazioni correlate all'immagine X, occorre eseguire il seguente comando:

ImageX /export source.wim 2 destination.wim "New image for Q4CY07"

Questo comando consentirà di esportare la seconda immagine del volume in un nuovo file WIM con il nuovo nome, eliminando completamente le informazioni precedenti dall'immagine del volume 1. È inoltre possibile eseguire l'esportazione dalle immagini WIM con spanning se si desidera riassemblarle in un singolo file WIM (come verrà illustrato più avanti in questo articolo). Le immagini con spanning non possono essere modificate tramite /mountrw, uno dei motivi per cui è consigliabile riassemblarle. È importante notare che ImageX non prevede alcun comando /import in quanto /export consente di creare nuovi file WIM o di aggiungerli a quelli esistenti. Per ulteriori informazioni su questo argomento, vedere l'intestazione laterale "Note importanti per /export".

Questa opzione è fondamentale anche nel caso in cui si esegua peimg /prep: sebbene consenta di preparare l'immagine Windows PE da utilizzare, questo comando non determina l'eliminazione di alcuna informazione da WIM. L'ideale sarebbe preparare, nel corso del processo di rilascio di Windows PE, l'immagine ed esportarla in un nuovo file boot.wim. Tenere presente che il processo di avvio cerca il file WIM solo in \sources\boot.wim; assicurarsi pertanto di assegnare al file il nome corretto e che il file venga contrassegnato come immagine del volume di avvio.

Come menzionato in precedenza, è consigliabile ottimizzare le immagini eseguendo il comando /export quando si è pronti per rimuovere le autorizzazioni per le immagini del volume obsolete o combinare insieme più immagini. È opportuno inoltre eseguire questa operazione se si sono apportate numerose modifiche tramite /mountrw o /delete. In caso contrario, col passare del tempo il file WIM continuerà ad aumentare di dimensioni (in modi misteriosi che non si è in grado di diagnosticare). Se si utilizza /mountrw o /delete a intervalli regolari, valutare l'opportunità di aggiungere /export nel flusso di lavoro per assicurare che le immagini siano completamente ottimizzate.

Spanning

Un altro problema a cui il team ha dovuto immediatamente far fronte è stata la probabile necessità di adattare i file WIM alle dimensioni di più supporti scrivibili. Come anticipato, Windows verrà distribuito su più CD (e potenzialmente su più DVD), il che ha determinato la necessità per WIM e ImageX di fornire il supporto per lo spanning.

Come menzionato in precedenza, un'immagine con spanning creata tramite /split è in sostanza un'immagine di sola lettura; l'immagine non può essere acquisita tramite /capture direttamente in una nuova immagine con spanning, non può essere montata tramite ImageX né aggiunta a un'immagine esistente mediante /append. Di conseguenza, è consigliabile suddividere il file WIM solo dopo aver utilizzato il flusso di lavoro standard e quando si è pronti per il rilascio. In altre parole, apportare tutte le modifiche desiderate al normale file WIM e valutare l'opportunità di utilizzare la suddivisione come parte del processo di rilascio per lo scenario di distribuzione.

Per quanto riguarda l'applicazione dell'immagine, l'utilizzo di immagini con spanning può dar luogo a non poche difficoltà. È consigliabile utilizzare ImageX anziché il programma di installazione quando si utilizzano immagini con spanning. È opportuno inoltre applicare le immagini in rete (per ottenere prestazioni ottimali senza eseguire l'imaging del disco da cui si sta applicando l'immagine) o copiarle direttamente nell'unità e successivamente applicarle (tenere presente che si sarà vincolati al disco in quanto durante la fase di applicazione il disco esegue le operazioni di lettura e scrittura su se stesso).

Verifica della validità

Quando si utilizza ImageX, si sposta una notevole quantità di dati molto importanti. Una domanda che quest'anno è stata posta di frequente in Tech•Ed riguardava la necessità di disporre di un metodo appropriato per assicurare che le immagini siano valide. Non si tratta certo di un'operazione semplice ma in realtà non è neppure estremamente complessa.

L'aspetto principale da tenere presente riguardo a WIM è che, come la maggior parte dei formati di archiviazione, è soggetto a danneggiamento. Un file WIM viene in genere danneggiato quando viene trasmesso in rete. In Windows Vista si sono rilevati da subito problemi specifici con determinate schede di rete: se i pacchetti venivano ignorati, il file WIM si danneggiava e non era sempre semplice diagnosticare la causa di questo danneggiamento. Questa situazione era quasi identica a quanto si era verificato alcuni anni prima quando il file driver.cab era aumentato di dimensioni; anche in tal caso si era assistito a un danneggiamento casuale molto simile. In generale, se vengono visualizzati report relativi a immagini non valide o a errori di installazione, è consigliabile verificare il tipo di NIC in uso nei sistemi su cui vengono generati i report. È opportuno seguire questa procedura sia che si utilizzi ImageX da solo sia che si esegua WDS.

In che modo quindi è possibile verificare se un'immagine sia valida o meno? Innanzitutto, è possibile utilizzare l'opzione /check. Questa opzione consente di evitare ulteriori controlli di integrità nel file WIM e di verificare, prima dell'applicazione, che il file WIM non sia stato danneggiato. Assicurarsi di eseguire /check anche in fase di applicazione in modo che l'immagine venga convalidata (questa operazione potrebbe richiedere più tempo).

Inoltre, in caso di problemi o semplicemente per meticolosità, è possibile eseguire un'utilità hash sui file prima dell'acquisizione e dopo l'applicazione. È possibile eseguire la verifica anche dopo l'acquisizione montando l'immagine e generando un nuovo hash: un metodo efficace per assicurare che un'immagine sia stata acquisita in modo corretto.

È probabile che si desideri assicurarsi che le immagini siano state acquisite in modo corretto dall'inizio. L'opzione /check e lo stesso formato sono stati progettati come punti di controllo non come punti di ripristino per ripristinare un 'immagine acquisita in modo non corretto.

Avvio e flag

In precedenza si è affermato che è possibile utilizzare /boot per acquisire un'immagine del volume WIM di Windows PE e avviarla. Occorre pensare a questa opzione come un settore di avvio su una specifica immagine del volume. questo settore di avvio può essere presente solo su una singola immagine del volume per ogni file WIM ed è valido solo per Windows PE 2.0. Tenere presente che non è possibile eseguire l'avvio di Windows PE 1.x da WIM.

È possibile che nelle immagini del volume di Windows siano presenti riferimenti ai flag. I flag vengono utilizzati solo dal programma di installazione di Windows. Un flag su un'immagine del volume 2 indica che un'immagine del volume contiene Windows PE e il programma di installazione. Un flag 9 indica che l'immagine del volume contiene solo Windows PE. Qualsiasi altro flag o la mancanza di un flag indica che l'immagine non verrà e non può essere utilizzata dal programma di installazione. Tenere presente che è possibile impostare i flag su un'immagine dopo che è stata acquisita utilizzando ImageX per modificarli. È consigliabile utilizzare WAIK (e se necessario Business Desktop Deployment Solution Accelerator) per creare l'immagine di avvio WIM di Windows PE, in modo da impostare correttamente i flag.

Nota per gli utenti di HTA

Di recente ho sentito parlare di alcuni report relativi a problemi correlati all'esecuzione dei file HTA su Windows PE 2.0. Sfortunatamente sembra che si verifichi un errore durante l'esecuzione dei file HTA che contengono script significativi. Nella Figura 4, dare un'occhiata alla schermata del file di esempio creato e prendere nota dell'errore di script (senza informazioni) restituito. Questo problema è stato segnalato da diversi clienti e io stesso ho avuto modo di sperimentarlo.

Figura 4** Errore di script HTA **(Fare clic sull'immagine per ingrandirla)

Per fortuna il problema può essere risolto con facilità. Durante la fase di preparazione dell'immagine, aggiungere il supporto XML e il supporto HTA. La dipendenza mancante nel componente HTA è inclusa nel modulo aggiuntivo XML, risolvendo pertanto il problema.

Vorrei ringraziare per l'aiuto alla realizzazione di questo articolo Bruce Green, sviluppatore ImageX, e Minxiao Zhou e Raja Ganjikunta del team per il test della distribuzione di Windows.

Wes Miller è un responsabile di sviluppo presso Pluck (www.pluck.com), Austin (Texas). In precedenza, ha lavorato per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.