デスクトップ ファイルWindows Imaging 形式について

Wes Miller

このコラムは、Windows 展開ツールのプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

Windows Vista のリリースで、Windows のインストール方法および展開方法が大きく変わります。Windows Vista (および Windows Server の次期バージョンであるコードネーム "Longhorn") のセットアップ エンジンと一連の展開ツールは、書き直されました。これらの変更点と

変更に至った Windows® 展開チームの成果については、少し前の TechNet Magazine の記事で説明しました。**ただ、このトピックについては説明することが多くあるため、この新連載のコラムで、Windows PE、Windows のインストールと展開、および Windows の管理とセキュリティに関する他のトピックについて説明します。

初回は、新しい Windows Imaging 形式 (WIM) について説明します。イメージングの詳細についてよくご存じない場合は、補足記事の「通常のイメージング プロセス」で概要を一読してください。次のコラムでは、Windows 自動インストール キットについて説明します。Windows 自動インストール キットとは、WIM イメージの作成および操作に使用するコマンドライン ツール ImageX と、リモート インストール サービス (RIS) に替わる機能である Windows 展開サービス (WDS) を含む一連の新しいツールです。これらのツールによって、OS の展開がどのように容易になるかについて見てみます。

ターニング ポイント

毎年、Windows 展開チームには、OEM および企業ユーザーから同じフィードバックが寄せられてきました。その内容は、イメージングのサポートを充実させること、およびマイクロソフトが統一的なイメージング ツールを提供することを望むものです。ユーザーは、サードパーティ ベンダを選択し、その複雑な製品について学習することを望んでいません。また、これらの OEM および企業ユーザーから、Windows を展開するために使用するイメージング ツールに費用をかけるのが当然とは思わないという苦情をよく聞きました。代わりに、マイクロソフトがこれらのツールを提供することを望んでいます。

Windows Vista™ の開発初期に、Windows 展開チームは非常に大きな賭けに出ました。コンポーネントの多くが 10 年近く使用されてきたセットアップ エンジン全体を、完全に破棄することにしました。セットアップ作業は常に脆弱で、非常に多くの手順がありました。プロセスを高速化し、不要な手順を排除して、Windows セットアップ全体の信頼性を強化したいと考えました。これを実現するため、長い間使用していた手作業を伴うエンジンからセットアップ プロセス全体を変え、完全にイメージベースのセットアップ プロセスに置き換えることにしました。

新しいイメージ形式の設計

セットアップを設計し直すプロセスの初期に、使用するイメージの種類の定義に着手しました。典型的な論点は、セクタかファイルか、という点でした。つまり、ボリュームのコピーをセクタごとの複製として格納するイメージ形式を使用するか、またはすべてのファイルを個々に格納するイメージ形式を使用するか、という点です。多くの人が期待するメリットは、速度 (セクタでのアプローチ) と圧縮 (ファイルベースのアプローチ) です。最終的に、この 2 つの中間的な、優れた形式に落ち着きました。それは、優れたパフォーマンスを実現するだけでなく、優れた圧縮機能も提供します。

まず、OEM および企業ユーザーのニーズを満たすイメージ形式を設計するために達成するべきいくつかの主要な目標を定義しました。その一覧は、ファイルベースのアーキテクチャに大きく傾いていました。チームのメンバ全員がこのアプローチのメリットを認識していたため、最初にこの方向で始まりました。その後すぐに WIM ファイルが誕生しました (参考までに、WIM の "M" に意味はありません。WIM は、リリース マイルストーン近くに定期的に行われる Windows チームのイベントを基に名づけられました。また、*.WI という略語が奇妙に見えるという理由もあります)。それでは、新しいイメージ形式に対する一連の目標を見てみましょう。

Windows ファイル システム形式に依存しない イメージ形式は、Windows でサポートされる両方のファイル システムのアーキテクチャで機能する必要がありました。実行時にはほぼすべてのシステムで NTFS が使用されますが、多くの OEM および企業は、Windows の展開に MS-DOS® を使用するため、一時的に FAT ファイル システムを使用します。その後、NTFS に変換します。Windows Vista でもこのサポートを継続する必要がありました。

ボリュームのサイズに依存しない 大きなボリュームをキャプチャしてそれよりも小さなボリュームに適用するという昔からの問題を回避する必要がありました。イメージング ツールでパーティションを操作してこの問題を回避できても、その信頼性は低くなります。ファイルベースのアーキテクチャでは、イメージを構成するファイルと同じサイズの領域しか必要ありません。ファイル システムは独自に復元されるため、ボリューム サイズに依存しません。

通常のイメージング プロセス

OEM で多数のシステムを複製するとき、または大規模な組織で多数のコンピュータに Windows を展開するときには、通常、イメージング テクノロジを使用します。その際、ホスト システムを導入し、それを適切に構築して、対象のシステムに複製することが前提になります。イメージング プロセスについてよくご存じない場合のため、ここに簡単な概要を示します。

  1. 管理者は、システムに Windows をインストールし、希望どおりに構成します。これには、コンポーネントの追加と削除、よく使用するアプリケーションのインストール、および UI や他の設定の微調整といった操作が伴います。このシステムをホスト システムと呼ぶことにします。
  2. 管理者はその後、(マイクロソフトが Windows 展開ツールの形式で提供している) Sysprep を実行します。このツールにより、Windows のインストール環境を一意に識別する属性 (コンピュータ名や Windows セキュリティ ID (SID) などのシステムの一意の識別子) がクリーンアップされます。これらは、Sysprep の後半部分が実行されるとリセットされます。
  3. 次に、管理者は、コンピュータをシャットダウンし、Windows PE、MS-DOS、または別の OS を選択して再起動し、イメージング アプリケーションを実行できるようにします。
  4. 次に、イメージング ツールを実行し、参照システムのイメージを作成します。このイメージは、参照ディスクまたは参照パーティションの完全な複製を含むファイル (またはファイルのコレクション) です。
  5. システムがシャットダウンされます。管理者はイメージをアーカイブします。このイメージは、必要に応じて (アプリケーション、修正プログラム、および Service Pack を追加して) 更新できます。
  6. イメージを 1 台以上のコンピュータに複製します。その後、Sysprep により簡略モードのセットアップ (Sysprep を実行している Windows のバージョンと Sysprep の構成方法によってミニセットアップまたは Windows Welcome と呼ばれます) が実行されて、作業が完了します。この段階では、setupcl.exe と呼ばれるネイティブモードの小さな実行可能ファイルが使用されます。

システム アーキテクチャに依存しない イメージ アーキテクチャは、Windows によってサポートされるあらゆるアーキテクチャと連携する必要がありました。当時、これは、まったく異なる x86 アーキテクチャと IA64 (Intel Itanium) アーキテクチャのサポートを意味していました。現在では、これに x64 (AMD64 および EM64T) アーキテクチャも含まれます。

短時間でキャプチャおよび適用できる イメージは、圧縮をかけても、ある程度短時間にキャプチャできる必要がありました。しかしそれよりも、イメージを短時間で適用できることの方が重要でした。

非破壊的なイメージの適用をサポートする システム回復に使用するツールを更新するだけでなく、(ユーザーのデータまたはアプリケーションを壊さずに Windows を置き換えることができるように) アップグレード オプションを差し替えていたため、既にボリューム上にあるデータを一切破壊せずにシステムのイメージを適用できるようにしたいと考えました。セクタベースの形式では、かなりの作業を行わないとユーザーはこれを実行できません。一般に、ボリューム全体を復元するか、まったく何も行わないかです。

大幅な圧縮をサポートする Windows Vista の開発当初は、まだ CD での出荷に重点を置いていました。Windows XP のイメージが 1 GB 近くであることを考えると、イメージをできるだけ小さく圧縮することが重要であると考えました。セクタベースのイメージを圧縮する方法はありますが、このような実装は不確定要素があり不安でした。多くのセクタベースの形式では、ディスク上の空の領域を省略し、領域を節約します (常に 0 なのに、なぜイメージに 0 を記録するのでしょうか)。しかし、ファイルベースのアプローチを使用することで、からの領域を扱わなくなったので、これを本質的に処理しました。

ファイルの単一インスタンスをサポートする これは前の問題と同じです。Windows では、同じファイルの複数のコピーがいくつかの異なる場所に格納されます。ファイルベースのアプローチにより、各ファイルの 1 つのインスタンスのみを格納し、必要に応じてそのファイルを使用することが簡単になりました。

複数のメディア (ディスク) への分割をサポートする 私たちは、WIM 開発当初から、1 枚の CD にイメージを収めることができたとしても、複数枚のメディアをサポートする必要があることを認識していました。Windows を 1 枚の CD で出荷しても、ユーザーがアプリケーションや Service Pack などを追加すると、そのイメージは 1 枚の CD または DVD のサイズを超える可能性があります。そのため、独自のインストールおよび復元手段のためにイメージを複数のメディアに分割できるようにする必要がありました。

1 つの BLOB ファイルで複数のボリューム イメージをサポートする 1 つのイメージですべての用が足りることはほとんどありません。"単一インスタンス" を設計したとき、複数のボリュームを取得する機能も含めました。同じ圧縮と単一インスタンスがそれぞれのボリューム間で機能します。そのため、Windows XP Professional のイメージを取得し、(Windows XP Professional を含む) Windows XP Tablet PC Edition の新しいイメージを追加すると、イメージは 2 つのバージョン間で明らかに異なるファイルの分だけ増加します。

その結果、OEM および企業ユーザーは、サイズを急激に増加されることなく多くの派生イメージを相互に追加できます。この機能は、セクタベースの形式では容易に達成できなかったと考えられます。

WIM のしくみ

WIM 形式は、基本理念を満たしながら、できるだけ簡単になるように設計されました。ファイルベースのアプローチによりこれを実現できました。ただ、これは実際どのように機能するのでしょうか。

簡単に言うと、WIM ファイルは CAB ファイル (ZIP 形式に似ていますが、マイクロソフトが、設計し、所有しています) と同じように考えることができます。実際、WIM が "CAB の息子" と呼ばれているのを聞いたことがあります。WIM ファイルと CAB ファイルの主な違いは、WIM イメージは、ファイル自体のキャプチャと圧縮に加え、特定のボリューム イメージにキャプチャされたボリュームを構成するファイルとディレクトリに適用されるメタデータも格納します。そのため、これは、イメージが作成されたときのとおりにボリュームを復元するために必要なメタ情報 (アクセス制御リスト (ACL)、短いファイル名、長いファイル名、属性など) が含まれるアーカイブ ファイルのようなものです。

キャプチャ プロセスの間は、パーティションの情報 (サイズまたは種類) が収集されないことに注意してください。適用プロセスでも、システムのパーティションは分割されません。多くのイメージング ツールとは異なり、ImageX はパーティションに依存しないので、適用前にパーティションを作成して、フォーマットする必要があります。イメージの適用前のプロセスを自動化するには、Diskpart およびフォーマット用コマンドライン ツールを使用する必要があります。

ボリューム イメージに格納できるものに制限はありません。2 種類のボリューム、火曜日と木曜日にキャプチャした同じボリューム、Service Pack を適用したイメージと適用していないイメージなど、ニーズに合わせて格納できます。理解すべき主な点は、同一のファイルが 1 度しかキャプチャされないということです。2 つのボリューム イメージに共通なファイルが少ないほど、より多くの領域が使用されます。

また、WIM 形式は、以前のバージョンの Windows でも使用できる設計になっています。Windows 2000 でも Windows Vista と同じように機能します。では、イメージをキャプチャしたり、適用したりするときに実際に何が起こるかについて詳しく見てみましょう。。

イメージのキャプチャ

ボリューム イメージをキャプチャするとき、次の手順が実行されます。

ボリュームのメタデータがキャプチャされる ImageX が、ファイル名、NTFS の ACL など、ボリュームのファイル システムの属性に関するデータを収集します (スクリプト ファイルを使用して、特定のファイルを除外できます)。

ファイル データがキャプチャされる ファイルが ImageX によって読み込まれます。各ファイルがボリュームに読み込まれ、ファイルに関する特定のデータを収集する準備を整えます。

ファイル ハッシュが生成される ファイル自体を基にしたファイルの暗号化ハッシュが生成されます。このハッシュは、イメージのファイルの一意の識別子になります。

重複の調査と除外が行われる 同じハッシュの別のファイルがイメージに既に存在する場合、これが同じファイルであると想定され、新しいファイルは既に存在しているファイルをポイントすることで参照されます。

一意のファイル データが圧縮される CAB や他の多くのアーカイブ形式とは異なり、WIM ファイルの各ファイルは、1 つのデータ ストリームとしてグループ化されたファイルのコレクションとしてではなく、個別に圧縮されます。また、圧縮を行わないという選択もできます。その場合、この手順は省略されます。

ボリュームのメタデータが圧縮されて格納される すべてのファイルがアーカイブされると、ボリュームのメタデータ エントリが作成されます。このメタデータには、ボリュームのイメージに追加された各ファイルが列挙されます。

イメージの XML データが生成されて格納される このデータは、キャプチャされた各ボリューム イメージの参照です。たとえば、ImageX /info を実行すると、この XML データが表示されます。

キャッシュされた WIM データのインデックスが記述される 最後に、(キャッシュされたデータと共に) マスタ データのインデックスが記述されます。このインデックスは、WIM 全体のマスタ ファイル テーブルであり、ハッシュごとに 1 つのエントリを含みます。

ご覧のとおり、ファイルベースの WIM が作成されます。さらに、イメージに追加するボリュームの数にかかわらず、できあがる WIM ファイルは 1 つです。

イメージのオーバーロード

WIM の開発を始めたとき、同じようなソリューションを開発しているチームは数多くありました。Automated Deployment Services チームは、私たちとは異なるユーザー層に向けたイメージング ソリューションを開発していました。そのアプローチは、実装の低レベル部分の詳細が非常に興味深かったのですが、イメージング エンジンが、当時主流を占めていたセクタ ベースでした。Windows XP Embedded チームも、セクタベースのイメージング エンジンを構築し、組み込みの独立系ハードウェア ベンダ (IHV) が独自のイメージをシステムの製造時に展開できるようにしました。2003 年にマイクロソフトが Virtual PC チームを買収したとき、バーチャル ハード ディスク (VHD) ファイル用の別のファイル形式がもたらされました。

これらすべての形式は、セクタベースが中核となっていました。これらのソリューションは、各ユーザー層のニーズは満たしましたが、WIM のガイドラインは満たしません。その結果、私たちはイメージをキャプチャするための新しい WIM 形式と ImageX コマンドライン ツールの構築を続けました。最終的に、WIM 形式は、Windows Vista ベータの一部として公開されるずっと前に、他の多くのチームに採用されました。たとえば、SMS チームは、Operating System Deployment Feature Pack で WIM を早期に実装しました。

イメージの適用

では、対になるプロセスであるイメージの適用について見てみましょう。

キャッシュされた WIM データのインデックスが読み込まれる これは、前の処理の最後の手順に関連します。このインデックスはマスタ インデックスであるため、どのボリューム イメージを適用するかを指定した後、最初に WIM から読み込まれます。

イメージのメタデータが取得されて読み込まれる ImageX が、各ボリューム イメージに固有のメタデータを読み込みます。

ディレクトリ構造が作成される すべてのファイルの復元先が存在することを確認するため、ボリュームのディレクトリ ツリー全体が作成されます。

ファイル データが抽出される ファイルは、アーカイブされた順番どおりに WIM から抽出されます。

ファイル データが適用される ファイルが読み込まれ、展開されて (ボリューム イメージを WIM で圧縮した場合)、参照先の各場所にコピーされます。最後に、各ファイルのすべてのメタデータが適用されます。

すべてのディレクトリのメタデータが適用される ディレクトリの ACL によってはイメージを正しく適用できない可能性があるため、これが最後の手順であることが重要です。

柔軟な圧縮

WIM イメージ形式の主な目標の 1 つは、柔軟な圧縮のオプションを提供することでした。そのため、必要に応じて圧縮をかけてボリューム イメージをキャプチャできる一方、圧縮せずにイメージをキャプチャすることもできる機能を提供しました。後者のオプションは、イメージをあえて圧縮する必要がない場合や、高速なキャプチャが重要な場合に適切です。

圧縮について言うと、覚えておくべきいくつかの基本事項があります。圧縮は、常に、展開よりも時間がかかります。圧縮効果が高い圧縮アルゴリズムほど、特定のデータ セットを圧縮するのにより長い時間がかかります。また、圧縮アルゴリズムを多くのデータに適用するほど、圧縮率が高まります。

WIM イメージは、XPress または LZX 圧縮を使用して圧縮できます。また、もちろん、圧縮をしないように選択することもできます。XPress は、多少の圧縮が必要でも、キャプチャ プロセスにあまり長い時間をかけたくない場合に適切です。LZX は圧縮率が最も高いですが、おわかりのとおり、この方法にはかなりの時間がかかります。

圧縮を使用しない場合、イメージは最短でキャプチャできますが、サイズが最大になります。圧縮の種類は WIM ごとに選択します。WIM に 1 つのボリューム イメージをキャプチャしたら、その後のすべてのボリューム イメージも同じ圧縮設定でキャプチャされます。

WIM イメージはファイルごとに圧縮されるため、圧縮が完全でないことに注意してください。これは意図的な決定でした。こうすることで、イメージをより容易に編集することができます。キャプチャ後にイメージを編集する機能は、重要なオプションです。イメージをキャプチャした後にファイルを編集するには、ファイル データとそのメタデータを置き換える必要があります。WIM 全体を 1 度にすべて圧縮した場合、ファイル編集のサポートの設計が、(仮にできたとしても) 非常に複雑になっていたでしょう。また、イメージ内のファイルの置き換えに、非常に長い時間がかかるでしょう。私たちは折り合いを付け、適切に圧縮できて、ツールを使用して編集することもできる形式を考案しました。

Windows Vista 用に設計したイメージング機能がどのように機能するかについて、理解していただけたでしょうか。次のコラムでは、WIM イメージの管理と展開に使用できるいくつかのツールについて説明しながら、ImageX および Windows 展開サービスについて詳しく見ていきます。

Wes Miller は、テキサス州オースティンにある Pluck 社 (www.pluck.com、英語) の開発マネージャです。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com です。Wes は、このコラムに協力してくれたマイクロソフトの現在の WIM および ImageX のプログラム マネージャである John Macintyre に感謝の意を表しています。

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