• [アーティクル]

デスクトップ ファイルWIM と ImageX のパワー ユーザー ガイド

Wes Miller

このコラムは、Windows 自動インストール キット (WAIK) と Windows Server 2008 のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

以前のコラムでも、ImageX と Windows Imaging (WIM) 形式については説明しました。数か月前に開催された Tech•Ed では、Windows 展開サービス (WDS)、ImageX、および Windows 自動インストール キット (WAIK) を使い始めようとしている IT プロフェッショナルから、いくつかのコメントや質問を受けました。

そこで、より詳しいユーザー ガイダンスが必要であると実感しました。そのため、今月のコラムでは、ImageX と WIM 形式に重点を置き、その活用方法について説明します。ImageX と WIM を併用すると、Windows Vista® と Windows Server® 2008 だけでなく、Windows® XP、Windows Server 2003、Windows 2000 も同様に容易に展開できます。

WAIK の変更点

Windows Server 2008 が間もなくリリースされることで、WAIK にどのような影響があるのかを知りたい思っている人もいるでしょう。マイクロソフトは、Windows Server 2008 のタイムフレームに WAIK の更新版をリリースする予定です。WIM 形式への大きな変更はありません (ImageX ツールと形式は変更されません)。Windows Server 2003 向けの WDS にも変更はありません。うわさに反して、マルチキャストは Windows Server 2003 の WDS では利用できず、Windows Server 2008 を実行する WDS サーバーでのみ WDS の新しいマルチキャスト展開機能を使用できます。

Windows PE 2.0 と Windows セットアップは、次の操作をサポートするために変更されます。

  • Windows Server 2008 と Windows Vista の展開。
  • Windows Server 2008 WDS サーバーからの WDS によるマルチキャスト展開。
  • Windows PE x86 ディスクからの Windows Vista と Windows Server 2008 の x64 バージョンおよび x86 バージョンの展開。

1 点目は、Windows PE 2.0 では Windows Server 2008 を Windows Vista とまったく同じように容易に展開できることを意味します。つまり、いずれの場合でも同じツールとプロセスが機能します。2 点目の変更は、WDS サーバーで Windows Server 2008 を実行すると、WDS によるマルチキャスト展開を使用できるようになります。そして、3 点目は、Windows PE 2.0 の x86 ディスクを使用して、そこから x86 または x64 バージョンの Windows のイメージを展開できることを意味します。

この 3 点目については、Tech•Ed の Windows x64 に関する講座で説明しました。残念ながら、この点については、ブログや Windows のテクニカル コミュニティで混乱が生じていました。これは、すべての Windows Vista または Windows Server 2008 の DVD で Windows x64 と Windows x86 が配布されるということではありません。また、(可能ですが) Windows x64 イメージと Windows x86 イメージを単一の WIM ファイルにまとめる必要があるということでもありません。単一のファイルにまとめても、単一インスタンス化による記憶域の節約にはなりませんが、WIM を 1 つのファイルとして扱うことはできます。

つまり、x86 ベースの展開プロセス (およびカスタム スクリプトやカスタム ツール) の開発に何年も費やしてきた企業ユーザーや OEM は、32 ビットのセットアップを使用して WIM 内から Windows x86 または Windows x64 を展開できるようになります。これは、2005 年に Windows x64 が登場したとき以来、企業ユーザーからずっと寄せられていた要望です。

ImageX の基本事項

/mount、/mountrw、および /delete を使用する

ここでは、ImageX で /mount、/mountrw、および /delete スイッチを使用する際の重要なヒントを紹介します。

  • ボリュームを編集する場合は、/mountrw を使用してマウントします。
  • WIM は空のディレクトリにマウントして、同じディレクトリに格納されている他のファイルとの混乱を排除し、ImageX で不要な警告メッセージが表示されないようにします。
  • 変更を保存する場合には、読み取り/書き込みイメージに対して /unmount /commit を実行します。私は、変更を行ったときに、その変更をコミットし忘れて破棄してしまったことが何度もあります。
  • /mountrw を使用してファイルを削除したり、/delete を使用してボリューム イメージを削除しても、空き領域は増えません。実際には、これらのスイッチの使用よって、さらに多くの領域が使用されることがあります。詳細については、このコラムの /export に関するセクションを参照してください。
  • 一度の読み取り/書き込みアクセスでマウントできるのは、1 つの WIM ファイルだけです。2 人のユーザーが同じ WIM を同時に編集したり、1 人のユーザーが 2 つのボリューム イメージを同時に編集することはできません。
  • ドライバは、マウントされる各イメージのシステムで使用できる Windows の非ページ プール メモリ量に依存するため、読み取り専用モード (/mount) でも、同時にマウントするボリューム イメージ数を制限する必要があります。そのため、この制限は、システムごと (またはシステム アーキテクチャごと) に異なる場合があります。同時に 5 つ以上のイメージをマウントすることはお勧めしません。
  • /mountrw を使用して大幅な編集を行っても、変更する際には、ほとんど時間はかかりません。ただし、/commit では、すべての新しいファイル データを圧縮して格納する必要があるため、このスイッチの実行には、かなりの時間がかかる場合があります。
  • 変更は一度コミットされると、元に戻せないため、/delete と /mountrw を使用する際には注意が必要です。
  • WIM ファイルにボリューム イメージが 1 つしかない場合、/delete は実行できません (WIM ファイル全体を削除するか、別のボリューム イメージを追加する必要があります)。
  • ボリューム イメージの内容のディレクトリ ツリーをすばやく取得するには、/mount ではなく、次のコマンドを使用します。
ImageX /dir <path_to_wim_file> <image index>
  • 2 つの WIM ファイルを同時に編集している場合、/unmount を同時に実行しないようにしてください。マウントとマウント解除のイベントは、一方が他方をブロックしないように順番に行ってください。

ImageX は、OEM と企業ユーザーから報告されたツールの使用方法を反映するようにデザインされました。図 1 はそのプロセスを示しています。

図 1 ImageX の使用

図 1** ImageX の使用 **

手順 5. が重要であることを強調しておきます。実環境では、イメージは常に変化しています。そのため、イメージのキャプチャと変更の作業は、できる限り迅速かつ容易に行える必要があります。

そのため、既に作成したイメージに (/append スイッチを使用して) 別のイメージを追加できます。開発チームでは、当初、ユーザーは追加の SKU (Windows のバージョン) を既存のイメージに追加すると考えていました。しかし、Windows Vista の開発初期に企業ユーザーとの連携を深めるうち、これが、X をすばやく展開して手順 2. のいずれかの変更を行った X1 を再キャプチャするために使用されていることがわかりました。また、この手順により、限られた数のファイルだけを変更しているため、イメージをすばやく再キャプチャできることもわかりました。

このことがわかったとき、開発チームは、元のイメージを保持することがすべての状況で意味をなすわけではないことに気付きました。このシナリオとこの後で紹介する別のシナリオに対応するために追加された /export スイッチについては、このコラムの後半で説明します。

常時行われる変更

開発チームは早くから、WIM ファイルを編集可能にする必要があると考えていました。既に、セクタベースのイメージ形式が機能しないと考えていたため (詳細については 2006 年 12 月号のコラム technetmagazine.com/issues/2006/12/DesktopFiles を参照)、Windows ファイル システムの一部としてファイルをネイティブかつ容易にマウントし、WIM ファイルのマウントされたボリューム イメージに容易に変更を加えられるソリューションを提供する必要がありました。つまり、"不確定要素" (と呼ぶことにします) が、他にもいくつかありました。セクタベース イメージは比較的容易にマウントできますが、WIM など、特殊なアーカイブ形式のマウントには特殊な手法が必要でした。

このような特殊な形式には、コマンド ラインからアクセスできる必要があります (ただし、ZIP ファイルや CAB ファイルをネイティブに処理するのに使用される一般的な Windows のシェル拡張は除きます)。残念ながら、こうしたハンドラではエクスプローラによるオブジェクトへの抽象的なアクセスしか許可されません。

その結果、WIM ソリューションにはドライバ (wimfltr.sys) と ImageX が含まれ、実際にドライバを読み込む役割を果たし、WIM をマウントするインターフェイスを処理します。図 2 のように、ドライバによって Windows ファイル システムに抽象概念が追加されます。次のようなコマンドを実行すると、この図に示すように、ImageX によって wimfltr.sys ドライバが読み込まれ、ドライバによって最初のボリューム イメージ (下記のコマンドでは 1 が使用されているため) がマウントされた空のディレクトリ上に重ねられます。

図 2 WIM ボリューム イメージのマウント

図 2** WIM ボリューム イメージのマウント **(画像を拡大するには、ここをクリックします)

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

これは、WAIK の既定の動作です。したがって、マウントされたディレクトリでディレクトリ一覧を調査または生成すると、boot.wim のボリューム イメージ 1 のルートを確認できます。もちろん、/mountrw または /mount のどちらを使用するかによって、このディレクトリが読み取り専用か読み取り/書き込み可能かが決まります (詳細については補足記事「/mount、/mountrw、および /delete を使用する」を参照してください)。

当初、/mountrw 機能は、ドライバやその他の XCOPY 可能なファイルまたはコンテンツを容易に追加し、応答ファイルをセットアップし、マウントされた WIM ファイルのオフラインのレジストリを必要に応じて変更できるようにデザインされました (図 3 参照)。(MSI を使用してインストールするアプリケーションはオフラインでインストールできないため) アプリケーション全体が追加または削除されるようにはデザインされませんでした。

図 3 マウントされた WIM ファイルの変更

図 3** マウントされた WIM ファイルの変更 **(画像を拡大するには、ここをクリックします)

WIM ファイルがマウントされている最中に変更を加えても、実際の WIM ファイルは (少なくともすぐには) 変更されないことを理解することが重要です。この場合、変更されるのは、実際の WIM ファイルではなく、重ね合わせと WIM ファイルへの変更内容を結合した WIM ファイルのキャッシュです。補足記事でも触れたように、この点については注意する必要があります。変更作業が完了したら、WIM ファイルに変更をコミットするため、必ず /unmount スイッチと /commit スイッチを使用する必要があります。このスイッチを使用しないと、変更内容は完全に破棄されます。

変更をコミットして保存すると、ドライバに WIM ファイル自体を変更するように指示することになります。ドライバにより、ファイル データが追加されます (/commit の実行時に初めてファイル データが WIM に追加されるため、多くの変更を加えた場合は、/commit の実行にはかなりの時間がかかる可能性があることに注意してください)。

また、セクタベースのイメージ形式とは異なり、ボリューム イメージに含まれるファイルを 1 つ以上変更している場合があります。その結果、(同一のファイルが既に一度格納されていない限り) 単一インスタンスではなくなり、元のファイル データが失われます。NTFS ボリュームや FAT ボリュームとは異なり、WIM ではファイルが削除済みとしてマークされません。ファイルは参照されなくなりますが、削除されません。そのため、/mountrw を使用して頻繁に編集を加えたり、/append 使用して多数のイメージを追加したり、/delete を使用してボリューム イメージを削除したりしても、WIM ファイルによってファイル データが参照されなくなるだけで、関連するファイル データがすべて削除されるわけではありません。

したがって、開発チームは、ある意味では "WIM デフラグ ツール" とも呼べる /export スイッチを作成しました。

エクスポート

/export に関する重要な注意点

/export を使用して新しい WIM ファイルを作成する場合、現在使用されている既定の圧縮の種類を使用するのではなく、使用する圧縮の種類を指定できます。現在使用している圧縮の種類から変更する場合、エクスポートにはかなりの時間がかかることがあります。

/export を (ボリューム イメージを既存の WIM ファイルに追加することで) 実質的に /append として使用した場合、WIM ファイルの /compression 属性を変更できません。

まったく新しい Windows PE 2.0 ボリューム イメージをエクスポートする場合には /boot スイッチを指定できます。

/export スイッチは、既に説明したシナリオと、開発チームが発見したより難解なシナリオへの対応策として作成されました。簡単に言うと、/export を使用することで、既存のボリューム イメージを 1 つ (または 2 ～ 3 つ) 取得してエクスポートすることができます。つまり、別の WIM ファイルからイメージをエクスポートすることで、上記の WIM ファイル X と X1 をすばやく取得し、X のみ、X1 のみ、または X1 と Y1 の両方を使用して新しい WIM を作成します。

X に変更を加え、/append を実行して変更を X1 として追加するシナリオを想像してみてください。ここで、X を新しいイメージに置き換えたため、X を削除するとします。/delete スイッチを使用することで、ImageX では X イメージが使用されなくなります。ただし、X に関連するすべての情報を削除して空き領域を確保するには、次のコマンドを実行する必要があります。

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

このコマンドにより、2 番目のボリューム イメージが新しい名前の新しい WIM ファイルにエクスポートされ、ボリューム イメージ 1 に関する以前の情報が完全に削除されます。また、1 つの WIM ファイルに再構築する場合には、分割した複数の WIM イメージからボリューム イメージをエクスポートすることもできます (詳細については、このコラムの後半で説明します)。分割イメージは /mountrw を使用して編集することはできません。これは、分割イメージの再構築が必要な理由の 1 つです。ImageX では、/export を使用して新しい WIM ファイルを作成したり、既存の WIM ファイルに追加したりすることができるため、/import コマンドがありません。このトピックの詳細については、補足記事「/export に関する重要な注意点」を参照してください。

また、これは peimg /prep を実行する場合にも重要です。このコマンドによって、使用する Windows PE イメージが準備されますが、WIM ファイル内の情報はクリーンアップされません。理想的には、Windows PE リリース プロセスの一環として、イメージを準備して、それを新しい boot.wim ファイルにエクスポートするのが望ましいです。ブート プロセスでは、\sources\boot.wim で WIM ファイルを見つけることだけが指定されているため、正しいファイル名を指定し、ファイルがブート ボリューム イメージとしてマークされるようにする必要があります。

既に説明しましたが、古いボリューム イメージが廃棄できるか、複数のイメージをまとめられるようになったときに、/export を実行してイメージを最適化できます。また、/mountrw や /delete を使用して大幅な変更を行った場合にも、/export を実行できます。これを実行しないと、WIM ファイルは (診断できない難解な方法で) 徐々に増大し続けます。定期的に /mountrw や /delete を使用している場合には、イメージが適切に最適化されるように、ワークフローへの /export の追加を検討してください。

分割

開発初期に発生した別の問題は、WIM ファイルを複数の新しいメディアにまたがって格納する必要があるかもしれない、ということでした。Windows が複数の CD で出荷される (また、実際そうであったように DVD で出荷される可能性がある) と予想していたため、WIM と ImageX に分割のサポートを組み込みました。

既に説明したように、/split を使用して作成した分割イメージは基本的に読み取り専用です。新しい分割イメージは、直接 /capture を実行したり、ImageX を使用してマウントしたり、/append を使用して追加することはできません。そのため、標準ワークフローを完了してリリースできる状態になった後にのみ、WIM ファイルを分割することをお勧めします。つまり、すべての編集は通常の WIM ファイルで行い、展開シナリオのリリース プロセスの一環として、WIM ファイルを分割することを検討してください。

イメージを適用する際には、分割イメージは厄介な場合もあります。分割イメージを使用するときには、セットアップではなく ImageX を使用することをお勧めします。また、ネットワーク経由でイメージを適用する (適用元のディスクのイメージを作成せずに最適なパフォーマンスを実現する場合) か、ドライブにイメージを直接コピーしてから適用することをお勧めします (適用時にはディスク自体で読み取りと書き込みを行うため、ディスクの制限を受けることに注意してください)。

検証ツール

ImageX を使用しているときには、非常に重要なデータを大量に移動しています。今年の Tech•Ed では、「イメージが有効であることを確認する方法はありますか」という質問を頻繁に耳にしました。その方法は、特別簡単ではありませんが、それほど難しくもありません。

WIM について特に理解しておく必要があるのは、ほとんどのアーカイブ形式と同様、破損しやすいということです。ほとんどの場合、WIM ファイルの破損は、ファイルがネットワーク経由で転送されるときに発生します。Windows Vista では、当初、特定のネットワーク カードに特異な問題が確認されました。パケットが破棄されると、WIM ファイルが破損し、その方法は診断が困難な場合がありました。この状況は、数年前、driver.cab ファイルのサイズが増大したときに同様のランダムな破損が発生した状況とよく似ています。一般的に、不良イメージやセットアップのエラーに関するレポートを受信した場合は、そのレポートが生成されたシステムで使用されている NIC の種類を確認することをお勧めします。これは、ImageX を単独で使用している場合と WDS を実行している場合のどちらにも当てはまります。

では、イメージが適切かそうでないかはどのように確認できるでしょうか。まず、/check スイッチを使用できます。このスイッチを使用すると、WIM ファイルのその他の整合性チェックを省略でき、WIM が破損していないことを適用前に検証します。同様にイメージの適用時にも /check を実行してください。イメージの適用にかかる時間が長くなりますが、イメージが検証されます。

また、問題が発生している場合や単純に細部までこだわりたい場合は、ファイルのキャプチャ前と適用後に、ファイルに対してハッシュ ユーティリティを実行できます。イメージをマウントして再度ハッシュすることで、キャプチャ後にイメージを検証することもできます。この方法は、イメージが適切にキャプチャされたことを確認するのに悪くありません。

イメージが最初から適切にキャプチャされるようにしたい場合があるでしょう。/check スイッチと形式自体は、適切にキャプチャされないイメージを修復する回復ツールとしてではなく、チェックポイントとしてデザインされています。

ブートとフラグ

既に説明したように、/boot を使用し、Windows PE の WIM ボリューム イメージをキャプチャしてブートすることができます。これは、特定のボリューム イメージのブート セクタと考えてください。ブート セクタは、１ つの WIM につき、1 つのボリューム イメージにのみ存在でき、Windows PE 2.0 でのみ有効です。Windows PE 1.x の WIM ボリューム イメージはブートできないことに注意してください。理由は、単純に不可能だからです。

Windows ボリューム イメージのフラグが参照されている場合があります。フラグは、Windows セットアップでのみ使用されます。ボリューム イメージの 2 というフラグは、ボリューム イメージに Windows PE とセットアップが含まれていることを意味します。9 というフラグは、Windows PE だけが含まれていることを意味します。その他のフラグが設定されていたり、フラグがない場合、そのイメージがセットアップとして使用されない、または使用できないことを意味します。イメージのフラグは、変更を加えるために ImageX を使用してキャプチャした後でも設定できます。WAIK (および必要に応じて Business Desktop Deployment Solution Accelerator) を使用して Windows PE WIM ブート イメージを作成すると、初めにフラグが適切に設定されるので、この方法を使用することをお勧めします。

HTA ユーザーへの注意点

最近、Windows PE 2.0 で HTA ファイルを実行すると発生する問題に関していくつかの報告を耳にしました。残念ながら、大量のスクリプトが含まれる HTA ファイルで発生する問題のようです。図 4 で、私が作成したサンプル ファイルのスクリーンショットをご覧ください。表示されたスクリプト エラーでは、情報が提供されていません。この問題は、複数のユーザーから報告され、私自身も体験しました。

図 4 HTA スクリプト エラー

図 4** HTA スクリプト エラー **(画像を拡大するには、ここをクリックします)

ただ、ありがたいことに、この問題はわりと容易に修正できます。イメージを準備するときに、HTA のサポートだけでなく、XML のサポートも追加してください。HTA コンポーネントにない依存関係が、XML アドイン モジュールに含まれているようです。このサポートを追加することで、問題を解決できます。

このコラムの執筆に協力してくれた ImageX 開発者の Bruce Green 氏、Windows Deployment Test チームの Minxiao Zhou 氏と Raja Ganjikunta 氏に感謝します。**

Wes Miller は、テキサス州オースティンにある Pluck 社 (www.pluck.com) の開発マネージャです。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.