Windows と Windows コンポーネント用パッケージ インストーラ Update.exe の内部メカニズム

トピック

	はじめに
	主な更新パッケージの種類
	インストーラの実行とリターン コード
	導入
	更新パッケージの内容
	まとめ
	付録 A インストーラのバージョン管理と機能
	付録 B Update.inf ファイル
	付録 C インストーラのプロセス フロー
	付録 D サンプル インストーラ ログ
	付録 E A/RP エントリの標準規則
	付録 F 拡張リターン コード

はじめに

このホワイト ペーパーでは、Update.exe として知られる Windows 用パッケージ インストーラについて説明します。Update.exe は、Windows オペレーティング システムやその他の Microsoft 製品のサービス パックおよび更新プログラム (修正プログラム) のインストールに広く使用されています。このパッケージ インストーラは数年にわたり Windows オペレーティング システムのインストーラとして使用されてきましたが、最近は Microsoft の他のチームも製品のインストーラとして採用しています。このホワイト ペーパーでは、パッケージの種類、導入方法、更新パッケージの内部動作について詳しく説明すると共に、インストールの概要にも触れます。このドキュメントの内容は 2003 年 12 月現在のものです。Windows 用パッケージ インストーラの機能が向上するに従い、このドキュメントも更新されます。このドキュメントの更新版については、http://www.microsoft.com/technet/prodtechnol/windowsserver2003/deployment/winupdte.mspx (英語) を参照してください。ドキュメントが更新されていないかどうかを確認するために、定期的にこのページをチェックしてください。

Windows Sustained Engineering (WinSE) チームがリリースする更新プログラムには必ずこの Windows 用パッケージ インストーラが付属しています。ただし、NT4 の更新プログラムには Update.exe の前のインストーラである Hotfix.exe が付属しています。

Microsoft では、インストーラの統一を目的としてインストーラを統合する計画 (英語) を開始しました。この計画は、インストーラにさまざまな機能向上を加えると共に、数あるインストーラを Update.exe と MSI インストーラの 2 種類に統合しようというものです。このドキュメントでは、Update.exe インストーラについて説明します。MSI インストーラの詳細については、「About Windows Installer」(英語) を参照してください。

Update.exe はサービス パックと修正プログラムの両方に使用されるため、どちらの更新プログラムを適用する場合でも競合が発生しないように設計されています。このインストーラは、更新プログラムとサービス パックのいずれについても、ファイルの追加、既存のファイルの削除または置き換え、レジストリ キーの追加、削除、更新、更新するファイルのバックアップを行います。

このインストーラのプロセス フローを概略的に示すと次の図 1 のようになります。

図 1: インストーラの動作概要

このドキュメントの終わりにある「付録 C インストーラのプロセス フロー」には、Update.exe によるサービス パックや修正プログラムのインストール作業の流れを詳細に示すフローチャートがあります。

ページのトップへ

主な更新パッケージの種類

"更新パッケージ" (単に "パッケージ" ということもあります) とは、インストーラ、関連ファイル、およびペイロード (インストールされる DLL、実行可能ファイル、またはスクリプト) が収められた製品または実行可能ファイルをいいます。これら 3 つのコンポーネントを総称して "パッケージ コンテンツ" といいます (「主な更新パッケージの種類」を参照してください)。ここでは、更新プログラムとサービス パックという 2 つの代表的なパッケージに絞って説明します。

更新プログラム (修正プログラム)

更新プログラム ("修正プログラム" ともいいます) は最も単純な形式の更新パッケージです。インストーラ、インストーラの関連ファイル、およびペイロードが含まれています。

サービス パック

更新パッケージの中で最もサイズの大きなものがサービス パックです。一般に、サービス パックには、製品の前回のサービス パックまたは RTM (Release to Market) バージョンがリリースされた後に発表された更新プログラムがすべて含まれています。サービス パックにも、他の更新パッケージと同じように、インストーラ、インストーラの関連ファイル、およびペイロードが収められています。

ページのトップへ

インストーラの実行とリターン コード

サービス パックや更新プログラムは 1 つの実行可能ファイルとして出荷されます。このファイルには、インストール ロジックやレジストリの変更を含め、上記のファイルがすべて含まれています。コマンド ラインにスイッチをまったく指定せずにパッケージを実行すると、パッケージの内容が一時フォルダに展開され、インストーラ (Update.exe) が起動し、更新プログラムのインストールが開始されます。インストーラには主として次の 3 つの目的があります。

このドキュメントでは、これら 3 つのシナリオにおける Update.exe の動作について説明します。わかりやすいように、まずは 3 つ目のシナリオである「更新パッケージ コンテンツの展開」から説明を始めます。更新プログラムおよびサービス パックのインストール オプションについては、「コマンド ライン スイッチ」を参照してください。

メモ Microsoft では、パッケージのインストール方法として、このドキュメントまたは導入ガイドに記載されている Windows パッケージ インストーラのみを推奨およびサポートしています。

更新パッケージ コンテンツの展開

上の 3 つ目のシナリオのように、インストールを実行する前にパッケージ内のファイルを展開した方がよい場合があります。更新プログラムのインストールによって適用される変更の内容をあらかじめ確認するために、このような方法が一般的となっています。パッケージを解凍すると、インストーラの実行可能ファイル、関連ファイル、およびペイロードが展開されます。ここでは、パッケージ コンテンツを展開する方法と、更新プログラムのインストール方法を指定するコマンド ライン スイッチについて説明します。

パッケージ コンテンツの展開方法やファイルの保存場所を指定できるオプションがあります。コマンド ライン スイッチを使用すると、ユーザー プロンプトの表示とファイルの展開先とするフォルダを指定できます。次の表では、展開方法を指定するスイッチを示し、それぞれの働きについて説明します。

表 1: 展開スイッチ

ディレクトリの指定

ファイルは、展開されると、指定したフォルダに保存されます。フォルダを指定しなかった場合は、ランダムに作成された名前のフォルダに保存されます。たとえば、/X /U と指定し、フォルダの指定を求めるダイアログを表示しなかった場合は、1ed6b742f546f などのフォルダ名が作成されます。表 2 に、パッケージ コンテンツの主な展開方法を示します。

表 2: コマンドラインスイッチの使用例

使用するインストーラのバージョンによっては、/U スイッチを使用しなくてもフォルダの指定を求めるダイアログ ボックスを省略できる場合があります。このインストーラの Q2 バージョン以降では、/X スイッチと有効なパス (/X:C:\path_name) を指定すると、ダイアログ ボックスは既定で表示されません。Q2 より前のバージョンの場合、/X スイッチを指定すると、ファイルを展開するフォルダを確認するダイアログ ボックスが表示されます (インストーラの機能およびバージョンによる違いについては、「付録 A インストーラのバージョン管理と機能」を参照してください)。

コマンド ライン スイッチ

ここでは、Update.exe に指定できるコマンド ライン スイッチ オプションについて説明します。これらのスイッチによって、Update.exe による更新プログラムおよびサービス パックの既定のインストール方法を変更することができます。指定したスイッチはパッケージの実行可能ファイルから Update.exe に渡されます。ただし、スイッチ オプションではファイルの展開方法を指定することはできません。次に、各スイッチ オプションの機能について説明します。

コマンドラインスイッチオプション

ここに挙げたスイッチ オプションにはスラッシュ (/) が付いていますが、スラッシュの代わりにハイフン (-) を使用することもできます。どちらを使用してもスイッチの機能は変わりません。

リターン コード

インストーラをバッチ ファイルから呼び出すと、インストールが成功したかどうかを示す情報を取得することができます (バッチ ファイルの詳細については、「インストール バッチ ファイル」を参照してください)。インストールが成功したかどうかを示す値は、リターン コードとして呼び出し側のプロセスに返されます。リターン コードを基に、次にどのような作業を行う必要があるかを検討できます。インストーラが返すリターン コードには、"失敗"、"成功"、"成功 - 再起動が必要" の 3 種類があります。

インストーラは、処理が完了すると、値を呼び出し側のプログラムに返します。次の表 4 は、インストーラが返す値とそれに対応するエラー コードを示したものです。

表 4: リターンコード

インストーラをバッチ ファイルから実行する方法の詳細については、「インストール バッチ ファイル」の例を参照してください。インストーラが実行する変更の詳細については、「付録 D サンプル インストーラ ログ」を参照してください。

ページのトップへ

導入

導入とは、サービス パックや更新プログラムを個々のコンピュータにインストールすることをいいます。導入について詳しく説明する前に、このインストーラで使用できる導入の基本的な要素を確認しておきます。最後に、あるサービス パックがリリースされてから次のサービス パックまでの間にリリースされる更新の導入について簡単に説明します。

導入の要素

Pending File Rename

実行中のシステムに更新プログラムをインストールする場合、更新の対象となるファイルが使用中となっていることもあります。そのような場合には、そのファイルの更新版が Pending File Rename (PFR) キューに追加されます。このキューは、システムの再起動時に置き換える必要のあるファイルが記録されるレジストリ キーです。PFR 操作が必要な場合には、システムを再起動して初めて更新プログラムのインストールが完了します。システムの再起動が必要かどうかは、インストーラ ログまたはリターン コードを調べることによって確認できます。

連続したインストール (QChain)

QChain は、複数の修正プログラム パッケージまたは 1 つのサービス パックと修正プログラム パッケージのインストールを効率化するテクノロジです。連続したインストールによって、1 回の再起動で Pending File Rename (PFR) をコミットすることができます。

Window インストーラの以前のバージョンでは、1 回の再起動で複数の更新プログラムをインストールするためには QChain を手動で実行することが必要でした。Update.exe の最近のバージョンには QChain 機能が組み込まれています。QChain の詳細については、「複数の Windows Update または修正プログラムを同時にインストールし、再起動を 1 回で済ませる方法」を参照してください。

2002 年 12 月以前にリリースされた更新プログラムをインストールする場合には、インストールの完了後にシステムを再起動することをお勧めします。インストーラがシステムの状態に加えた変更はインストールが完了しても既定の状態に戻らないからです (再起動が必要なケースの詳細については、Microsoft サポート技術情報の Knowledge Base の文書 815062 を参照してください)。

更新プログラムとオプションのコンポーネント

コンピュータに更新プログラムを適用するときに、更新プログラムの対象となるコンポーネントがインストールされていないこともありえます。このようなことが起きるのは、コンピュータをセットアップするときにオプションのコンポーネントをインストールしなかった場合です。オプションのコンポーネントに更新プログラムを適用するには、"sticky updates" という機能を適用します。sticky updates を完全な状態で適用すると、オプションのコンポーネントをインストール時に更新することができます。

オプションのコンポーネントに影響を与える更新プログラムがインストールされる場合、2 つの状況が考えられます。1 つはコンポーネントがインストールされていて、更新されるケースで、もう 1 つはコンポーネントがインストールされていないケースです。オプションのインストール コンポーネントがインストールされていない場合は、そのコンポーネントの更新に必要なファイルが将来の使用に備えてディスクにキャッシュされます。その時点では sticky updates が完全に適用されていなくても、sticky updates に関連する機能の一部を、更新プログラムのインストール後に確認することができます。キャッシュされたファイルの保存先となるディレクトリはレジストリで確認できます。このディレクトリは、レジストリ キー HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup のレジストリ値 ServicePackCachePath に設定されます。このレジストリ キーにディレクトリが記録されるかどうかは、どのようなオプションのコンポーネントをインストールしたかと、それらのコンポーネントの更新プログラムもインストールしたかどうかによって決まります。

sticky updates が完全に実装された段階で、その機能と動作方法の詳細な説明がこのドキュメントに記載される予定です。

言語に関する考慮事項

システムの言語と一致する言語版の更新プログラムが必要となる場合もあります。また、システムの言語とは関係なく適用できる更新プログラムもあります。Windows Updateが正しく動作するためには、インストールした更新プログラムの言語がコンピュータの既定の言語と一致している必要があります。他の Sustained Engineering チームからリリースされた更新プログラムの場合は、言語の一致が必要ではないこともあります。Microsoft サポート技術情報の Knowledge Base の文書で更新プログラムが言語に一致する必要があるかどうかがわからない場合は、.inf ファイルの LanguageType に設定されている値で確認できます。言語コードが 0x0 であれば、その更新プログラムはシステムがどのようなロケールであっても適用可能です (.inf ファイルの詳細については、「付録 B Update.inf ファイル」を参照してください)。

Multilingual User Interface Pack (MUI) を使用している場合、MUI 固有のインストールはないため、システムを更新プログラムするには、英語版の更新プログラムまたはサービス パックをインストールするだけです。MUI 対応のシステムを更新プログラムする方法の詳細については、「Service Pack Release Notes for Windows Multilingual User Interface (MUI) Version」(英語) を参照してください。

更新パッケージのバージョン管理

更新プログラムに含まれる DLL ファイルだけでなく、更新パッケージそのものもバージョン管理されています。これによって、一度リリースした更新プログラムを再びリリースする場合でも、両者をバージョン番号によって簡単に区別することができます。更新プログラムをインストールすると、そのバージョン番号がレジストリに記録されます (詳細については、「更新プログラムのレジストリ エントリ」を参照してください)。

更新プログラムをインストールする前にバージョンを確認するには、パッケージ内容を展開し、.inf ファイルの内容を表示します。更新のバージョンは .inf ファイルの [Version] セクションではなく BUILDTIMESTAMP キーの [Strings] セクションにあります。パッケージの内容を展開する方法については、「更新パッケージ コンテンツの展開」を参照してください。

更新のバージョン番号は、パッケージが作成された日付と時刻で構成されています。たとえば、バージョン 20030102.120145 の意味は、次の表 5 のようになります。このバージョン管理方法により、どの更新バージョンの方が新しいか (最新のバージョンはどれであるか) を判別することが可能になります (次の表 5 を参照してください)。

表 5: 更新のバージョン管理

更新プログラムのレジストリエントリ

更新プログラムをインストールすると、複数のエントリがレジストリに追加されます。これらのエントリによって、更新プログラムをインストールしたことが記録され、インストールの内容やアンインストールに必要となるファイルの場所などの詳細が明らかになります。これらの情報が設定されるレジストリ キーは、Microsoft Baseline Security Analyzer (MBSA)、QFE Check、[プログラムの追加と削除] (A/RP)、および外部ツールにおいて、現在インストールされている修正コードを特定し、表示する目的で使用されます。

更新プログラムをインストールすると、3 つのレジストリ キーが書き込まれます。それらは通常、修正プログラム レジストリ エントリ、更新レジストリ エントリ、[プログラムの追加と削除] (A/RP) レジストリ エントリと呼ばれます。修正プログラム レジストリ エントリには、インストールされた Windows 修正コードの詳細だけが記録されます。更新エントリには、Windows チームおよびその他のチームからリリースされた修正コードの詳細が記録され、A/RP エントリには、[プログラムの追加と削除] の一覧に表示される修正プログラムの情報が記録されます。

メモ パッケージをインストールするときに /N スイッチを指定すると、A/RP エントリが書き込まれないことがあります。Q2 以前のインストーラ (「付録 A インストーラのバージョン管理と機能」を参照) を使用し、アンインストールなしオプションを選択してインストールした古いパッケージは、[プログラムの追加と削除] の一覧には表示されません。

これらのエントリでは、KB または Q とそれに続く Microsoft サポート技術情報の Knowledge Base の文書番号で更新が表されます。古い更新は Q で始まり、2002 年以降にリリースされた更新は KB で始まります。KB と KB 文書番号で更新を表すことは、現在 Microsoft において標準として規定されています。Q は 2003 年中に使用が中止される予定です。

サービス パックをインストールすると、更新プログラムのインストールによって追加されたレジストリ キーがクリーンアップされます。サービス パックの目的の 1 つは、前回のサービス パックのリリース以後にリリースされた修正プログラムを 1 つにまとめることです。サービス パックをインストールすることによって、それまでにインストールされた更新プログラムのうち新しいサービス パックに含まれている更新プログラムのレジストリ エントリがレジストリから削除されます。代わりにサービス パックのエントリが追加され、[プログラムの追加と削除] の一覧にもサービス パックが表示されます。サービス パックをアンインストールすると、元の修正プログラムとそのレジストリ エントリが復元されます。

更新プログラムのレジストリエントリ

下記の更新レジストリ エントリ キーは WinSE (Windows Sustained Engineering) チームおよび Microsoft の他の Sustained Engineering チームが使用しており、この後に示す修正プログラム キーに代わるものです。このキーの形式はインストールするパッケージの種類 (サービス パックか修正プログラムか) によって異なります。サービス パックの場合は要約情報だけで構成され、更新の場合は以下のように要約情報とファイル一覧のエントリが定義されます。

プログラムの追加と削除キー

サービス パックおよび更新プログラムは RTM イメージへの追加と見なされ、[プログラムの追加と削除] (A/RP) の一覧に追加されます。A/RP は、レジストリ キー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall の情報を基に、インストールされたソフトウェアとそのアンインストール方法を認識します。このキーでは、修正プログラムの情報に加え、他のプログラムに関する情報も取得できます。更新プログラムは、KB 番号または Q 番号によって管理されています (次の表 8 を参照してください)。

インストールされている更新プログラムは、コントロール パネルの [プログラムの追加と削除] で確認できます。インストールされているプログラムの後に、インストールされている更新プログラムが表示されます。

A/RP レジストリ エントリには標準規則が定義されています。詳細については、「付録 E A/RP エントリの標準規則」を参照してください。

メモ パッケージをインストールするときに /n スイッチを指定すると、A/RP レジストリ エントリが書き込まれないことがあります。Q2 以前のインストーラ (「付録 A インストーラのバージョン管理と機能」を参照) を使用し、アンインストールなしオプションを選択してインストールした古いパッケージは、[プログラムの追加と削除] の一覧には表示されません。

表 8: [プログラムの追加と削除] のレジストリキー値

修正プログラムレジストリエントリ

下記の修正プログラム レジストリ エントリは WinSE だけが使用している古いエントリです。キーの中には現在は使用されていないものもあります。このエントリに記録される情報について、次の表 9 で説明します。

例

HKEY_LOCAL_MACHINE \Software\Microsoft\WindowsNT\CurrentVersion\Hotfix\KB######

表 9: 修正プログラムのレジストリキー値

パッケージインストールの種類

サービス パックまたは更新プログラムのインストール形式には、更新プログラムのペイロードがインストール パッケージにすべて揃っている自己完結型とペイロードが動的に決定される高速インストールがあります。現在、高速インストールのパッケージは Windows Update サイトでのみ提供しています。ペイロードを含んだ自己完結型パッケージは Windows Update カタログから取得できます。

どちらの方法でペイロードを取得してもインストール手順は同じです。いずれの場合も Update.exe では同じコード パスによってインストールするファイルが特定されます。インストール中、Update.exe は既にインストールされているファイルを調べ、更新プログラムに含まれているファイルと同一またはそれより新しいものがないかどうかを確認します。更新プログラムに含まれているファイルと同一またはそれより新しいファイルが既にインストールされている場合、そのファイルの更新は不要です。高速インストールと自己完結型インストールのいずれにおいても、この手法が使用されています。次に、これら 2 種類のインストールについて詳しく説明します。

自己完結型インストール (完全インストール)

自己完結型インストール (標準インストールまたは完全インストールともいう) とは、更新としてインストールする必要のあるファイルがすべて含まれているインストール パッケージをいいます。ペイロード全体が使用できる状態で含まれているため、Update.exe はインストールする必要のあるファイルを特定し、インストールを実行します。このインストール方法はファイアウォールで保護された大規模な環境に適しています。この方法であれば、ファイアウォールがあるために個々のコンピュータからインターネットにアクセスできない場合や、インターネットからのインストールが禁止されている場合でもインストールが可能です。

高速インストール

自己完結型インストールとは異なり、高速インストールには更新のペイロードが含まれていません。更新に必要なファイルを調べ、インストールするファイルの一覧を作成して、それらのファイルを Windows Update サーバーから取得します。インストールする必要のあるファイルとコンピュータ上のファイルを比較し、既にインストールされているファイルより新しいファイルだけをダウンロードしてインストールします。

ネットワークインストール

ネットワーク インストール (詳細については「導入方法」を参照) には、インストーラに必要なディスク領域が少なくて済むという利点があります。ペイロードをネットワーク上に置くことによって、インストールの作業領域としてネットワーク上の保存場所を使用できるため、ハード ディスク領域を使用する必要がありません。このインストール方法は、コンピュータの記憶容量が限られている環境に適しています。ネットワーク インストールの詳細については、適切な導入ガイドを参照してください。

デバッグシンボル

デバッグ シンボルは、使用頻度が低かったため、現在は Windows Update Web サイトからダウンロードするパッケージには含まれていません。デバッグ シンボルを廃止したことにより、パッケージのサイズが平均で 30% 縮小しました。デバッグ シンボルが必要な場合は、Microsoft サポート技術情報の Knowledge Base の文書「修正プログラム パッケージにはデバッグ シンボル ファイルが含まれない」を参照してください。この文書では、デバッグ シンボルをダウンロードしインストールする方法について説明しています。

導入方法

サービス パックや更新をネットワーク環境のコンピュータに導入するには、いくつかの方法があります。たとえば、インストール オプションを指定して Update.exe を手動で実行する方法もあれば、SMS (Systems Management Server) や Windows インストーラ Sysprep を使用することもできます。さらに、共有ネットワーク フォルダを使用したり Microsoft ダウンロード センターから修正プログラムをダウンロードして更新を配布するという方法も可能です。基本的に、サービス パックと更新はほとんど同じ方法で導入できます。

Windows サービスパックの導入

次の表 10 は、サービス パックの導入方法に関する資料として最適な導入ガイドについてまとめたものです。これらのドキュメントには、サービス パックを単一システム環境および複数システム環境に導入する方法の詳細が記載されています。サービス パックをオペレーティング システムに導入する方法を検討する際には、必ずこれらのドキュメントを参照してください。

表 10: 導入ガイド

Windows サービスパックのスリップストリーム (複合) インストール

サービス パックの場合は、他の更新では使用できないスリップストリーム (複合) インストールという方法を使用できます。この方法は、オペレーティング システムをインストールする前にサービス パックをオペレーティング システムにプレインストールするというものです。スリップストリーム インストールには、インストールの前にオペレーティング システム イメージをサービス パックや更新を使用して更新できるという利点があります。このインストール方法を使用すると、コンピュータを 1 回のイメージング プロセスで完全に更新することができます。この方法を使用できるのは、Windows 2000、Windows XP、または Windows Server 2003 オペレーティング システム全体をインストールする場合です (スリップストリーム インストールを行う方法の詳細については、表 10 に示したドキュメントを参照してください)。

アプリケーションエラー報告 (Watson 報告)

2003 年 12 月にリリースされた Update.exe Version Q4 の特徴の 1 つとして、アプリケーション エラー報告 (Watson 報告) 機能が追加されたことがあります。この機能は、クラッシュ発生時の状況をユーザーの同意を得て Microsoft に報告するというものです。Microsoft に送信されるデータは、「End User Privacy Policy in Application Error Reporting」(英語) に記載された方針に基づいて扱われます。Update.exe の各バージョンにおけるアプリケーション エラー報告機能のサポート状況については、「付録 A インストーラのバージョン管理と機能」を参照してください。

更新の導入

ここでは、サービス パックおよび修正プログラムのさまざまなインストール方法について説明します。

有人モード

家庭や個人が管理する環境で広く使用されているインストール方法で、ユーザーによる操作を必要とします。一般に、このインストールは、いくつかのスイッチと組み合わせて実行します。スイッチの詳細については、「コマンド ライン スイッチ」を参照してください。

ネットワークフォルダからのインストール

個人が管理する環境の複数のコンピュータに更新プログラムをインストールするには、更新を共有ネットワーク ドライブに配置し、以下の手順を実行します。以下の手順では、更新するすべてのコンピュータからアクセス可能なネットワーク上の場所に配布フォルダを作成しています。

メモ 連続したインストールを行う場合は、「連続したインストール」の説明を再確認してください。

インストールバッチファイル

バッチ ファイルを使用することによって、一度に複数の修正プログラムをインストールできます。ここでは、ネットワーク共有から複数の修正プログラムをインストールする状況として代表的な 2 つのシナリオに対応するバッチ ファイルの例を紹介します。1 つ目の例では、サービス パックと複数の修正プログラムを同時にインストールする方法を示します。インストーラが再起動の必要性を判断できるように、可能な限りこちらの方法を使用してください。2 つ目の例では、再起動が必要かどうかを判断する方法について説明します。

@ECHO OFF    
SETLOCAL    
REM Location of updates to install    
SET PathOfFixes=Drive:\hotfix    
%PATHTOFIXES%\SP_install.exe /Z /U    
%PATHTOFIXES%\Update_A.exe /U

@ECHO OFF    
SETLOCAL    
REM Location of updates to install    
SET PathOfFixes=Drive:\hotfix    
REM Flag used to determine if a restart is required, initialize to 0    
SET Reboot_Needed=0    
%PathOfFixes%\update_a.exe /Z /U    
IF ERRORLEVEL 3010 SET Reboot_Needed=1    
%PathOfFixes%\update_B.exe /Z /U    
IF ERRORLEVEL 3010 SET Reboot_Needed=1    
%PathOfFixes%\Update_C.exe /Z /U    
IF ERRORLEVEL 3010 SET Reboot_Needed=1    
REM force restart here    
IF %Reboot_Needed%.==1. Shutdown /r

導入のタイミング

修正プログラムの移行

修正プログラムの移行は、Microsoft Windows XP および Windows Server 2003 プラットフォームでのみ可能です。これらの環境で修正プログラムを移行すると、サービス パックのアップグレード時に同じ更新レベルを維持することができます。Windows XP と Windows Server 2003 では手順が異なりますが、同じ結果になります。サービス パックをリリースする前の数週間の間にリリースされた修正プログラムは、そのサービス パックに含められないことがあります。このような場合 WinSE では、移行可能な修正プログラムを提供しているため、サービス パックをインストールした後にそれらの修正プログラムを再度インストールする必要はありません。実際には、現在のオペレーティング システム リビジョン レベルに対する修正プログラムをインストールし、次のサービス パック レベルに対する修正プログラムをキャッシュします。次のサービス パックをインストールすると、キャッシュされていた修正プログラムがそのサービス パック バージョンに移行します。Windows XP のデュアル モード修正プログラムの詳細については、Microsoft サポート技術情報の Knowledge Base の文書「Windows XP のデュアル モード修正プログラム パッケージについて」を参照してください。Windows Server 2003 における修正プログラムの移行の詳細については、「Windows Server 2003 製品アップデート パッケージの内容に関する説明」を参照してください。修正プログラムの移行に使用されるディレクトリの構造については、「更新パッケージの内容」を参照してください。

デュアル モード インストールの場合はパッケージ内にファイルが 1 つ追加されています。この Xpsp1hfm.exe というファイルは、アップグレードされたサービス パックへの新しい更新の移行を管理するもので、インストールする必要がある更新のバージョンを特定します。デュアル モード インストールでは、パッケージの内容を展開してから、Update.exe ではなく Xpsp1hfm.exe を実行し、インストールを行います。このとき、Update.exe に適用するスイッチと同じスイッチを Xpsp1hfm.exe にも適用できます。

ブロックリスト - 既にインストールされている更新の上書き

サービス パック サイクルの終わりにリリースされ、次のサービス パックには含められない更新を "ブロックリスト修正" といいます。このような "端境期" の更新は次のサービス パックをリリースする直前の短い期間に作成されるもので、数は多くありません。サービス パックのインストール時にこのような更新は上書きされ、それらの更新が無人モードまたは対話モードで行われることを示すインストーラ ログ エントリが作成されます。インストールを開始すると、"システム構成を調べています。" というメッセージに続き、以下のメッセージが表示されます。

"このサービス パックには、コンピュータにインストールされていない修正プログラムに対応するファイルが含まれています。問題が発生する可能性があるため、これらのファイルはインストールされません。

これらの修正プログラムがサービス パックとインストール済みのホットフィックスの両方に含まれるようにするためには、サービス パックをインストールする前またはインストールした後で以下のホットフィックスの更新バージョンを入手し、インストールする必要があります。これらのホットフィックスは svcpack.log ファイルにも列記されています。"

サービス パックのインストール中に上書きされた更新は、もう一度インストールする必要があります。どの更新が上書きされたかを調べるには、サービス パックのリリース ノートを参照するか、Updtblk.inf ファイルの内容をチェックしてください。上書きされる更新を特定できたら、その更新の更新バージョンをダウンロードし、サービス パックのインストール後に続けてインストールします。

ブロックリスト修正は、更新のインストールにも関係します。この場合は、インストールされる更新のバージョンが既に古いことを意味します。この問題が発生した場合は、その更新の新しいバージョンをダウンロードし、インストールしてください。次のようなメッセージが表示されます。

"このホットフィックスは、古いファイルが含まれているため、インストールできません。修正プログラム KB###### の最新バージョンをダウンロードし、インストールしてください。"

ブロックリスト修正の更新の詳細については、次の Microsoft サポート技術情報の Knowledge Base の文書を参照してください。

810077 - いつホットフィックスが SP3 のどの前バージョンにインストールされるコンピュータに SP3 をインストールするか表示される警告を抑制する方法

309601 - Windows 2000 Service Pack 3 (SP3) と競合する Windows 2000 修正プログラム

ページのトップへ

更新パッケージの内容

更新パッケージには、パッケージ インストーラのほかに、インストーラの関連ファイル (.inf ファイルなど)、およびペイロード (更新されるファイル) が収められています。ここでは、バイナリ ファイル、ログ ファイル、およびこれらのファイルの構造について説明します。

バイナリ ファイル

"パッケージ" というときには、通常はサービス パックまたは更新の内容を意味しています。どちらの場合も、使用されているロジックとインストール テクノロジは同じです。次の表 11 ではインストーラのバイナリ ファイルについて説明します。この説明はサービス パックと修正プログラムのどちらにも当てはまります。

表 11: インストーラのバイナリファイル

Custom.dll

custom.dll は、パッケージ インストーラがサポートしていないカスタム機能を組み込む目的で使用されます。Sustained Engineering チームでは、このファイルを使用してパッケージ インストーラに含まれていない機能を提供しています。custom.dll の名前は変更可能であり、ファイル名は .inf ファイルの [Configuration] セクションに指定されています。このファイルによって組み込まれたカスタム機能はインストール プロセスのさまざまな段階で実行されます。

.inf ファイル

.inf ファイルはインストールするファイルの詳細をインストーラに渡します。このファイルによって、更新をリリースするたびにカスタム アクションをインストーラに定義する必要がなくなります。Windows パッケージ インストーラでは複数の .inf ファイルが使用されます。どの .inf ファイルが使用されるかはパッケージの種類によって異なります。update.inf ファイルはすべてのパッケージで使用されます。branches.inf ファイルと updatebr.inf ファイルを使用するパッケージもあります。各パッケージに含まれるファイルの詳細については、「更新パッケージの内容」を参照してください。

Update.inf

update.inf ファイルは、Update.exe に渡されるディレクティブのコアです。複数ブランチ対応のインストールでは、このファイルは修飾名 (update_rtmgdr.inf および update_rtmqfe.inf) で表されます (詳細については、「複数ブランチ対応の .inf ファイル」を参照してください)。update.inf ファイルの構造は柔軟に拡張可能です。最上位レベルでは、更新するオペレーティング システム バージョン情報、変更が必要なレジストリ エントリ、インストール中に実行するカスタム機能などの情報を Update.exe に渡します。このパッケージ インストーラで使用されている .inf ファイルは、MSDN の「Creating an INF file」(英語) に記載された .inf ファイルとよく似ています。異なる点もありますが、ファイルの基本的な構文は同じです。パッチのインストールに使用されるほとんどの update.inf ファイルには、共通のセクションが数多くあります。「付録 B Update.inf ファイル」に、そのような共通のセクションの一覧があります。

複数ブランチ対応の .inf ファイル

複数ブランチをサポートするためには、update_gdr.inf と update_qfe.inf という update.inf ファイルの 2 つのバージョンが必要となります (2 つのファイルの名前が異なるのは、同じディレクトリにあるからです)。他にも updatebr.inf ファイルと branches.inf ファイルの 2 つの .inf ファイルが必要です。これらはブランチを定義したり、ブランチの関係を定義したりするものです。

Branches.inf

このファイルには、更新がどのブランチから作成されたかが示され、ブランチの階層も定義されています。インストール プロセス中に、システムの構成と branches.inf の内容が比較され、インストールが必要なブランチが決定されます。このファイルは、修正プログラムの以前のバージョンを新しいバージョンに移行する必要がある場合にも使用されます。更新のインストールを開始すると、branches.inf ファイルがコンピュータにコピーされます。また、このファイルはバージョン管理されているため、新しいバージョンが作成された場合に対応できます。このファイルの新しいバージョンが別の更新に付属していた場合には、新バージョンに更新されます。

Updatebr.inf

updatebr.inf ファイルには 2 つの目的があります。1 つは共通ファイルと複数ブランチ対応のファイル構造における共通ファイルの位置を定義することであり、もう 1 つはインストールするブランチと update.inf ファイルとの関係を定義することです。複数ブランチ対応のインストールでは、インストールするブランチによって必要となるファイル セットが異なるため、それに対応できるよう複数の update.inf ファイルが更新に付属しています。updatebr.inf の重要な目的の 1 つは、ブランチを適切な update.inf ファイル (update_rtmqfe.inf または update_rtmqfe.inf) にリンクすることです。

インストーラ ログ ファイル

更新またはサービス パックのインストール中には複数のインストーラ ログ ファイルが生成されます。これらのログ ファイルには、インストールの状態などの有用な情報が記録されます。サービス パックまたは更新プログラムをインストールするたびに、新しいログ ファイルが生成されます。インストーラ ログ ファイルは Windows root (%windir%) ディレクトリにあり、ログ ファイルであると簡単にわかる名前が付いています。たとえば、Microsoft サポート技術情報の Knowledge Base の文書 824146 に関連する更新プログラムをインストールした場合、インストーラ ログ ファイルの名前は KB824146.log となります。「付録 D サンプル インストーラ ログ」では、インストーラ ログの例を挙げ、記録された情報の詳細について説明しています。

ログの名前と場所

インストーラ ログの名前は update.inf ファイルに定義されています (場所は定義されません)。.inf ファイルにログ ファイルの名前を定義するエントリがあります。[Strings] セクションの変数 InstallLogFileName を確認してください。この変数は、通常は %SP_SHORT_TITLE%.log に設定され、更新の名前に解決されます。Windows Sustained Engineering が使用している標準のログ ファイル名の一覧は、以下のとおりです。

ログの内容

インストーラ ログ ファイルには、主として以下の情報が記録されます。

このインストーラの Version Q4 以降では、ログ メカニズムの頑強性が向上しています。この節および付録の説明は Version Q3 に関するものです。インストーラのバージョン管理の詳細については、「付録 A インストーラのバージョン管理と機能」を参照してください。

ログエントリ

インストーラ ログには、エラーのように見えて、実は情報の提供を目的としているエントリがあります。エラーのように見えるのは、このインストーラが標準の Windows SetupAPI を使用しており、書式およびエントリの設定機能に限界があるからです。次の表 12 に、エラーと混同しやすいインストーラ ログ エントリの例を示します。

表 12: エラーと混同しやすいログエントリ

Update.exe のログ エントリについては現在見直しを進めており、将来のバージョンで大幅に変更されます。上記のエントリは Q3 およびそれ以前のバージョンのものです。実際のログ ファイルの内容と異なっている場合は、そのログを作成したインストーラのバージョンを確認してください (詳細については、「付録 A インストーラのバージョン管理と機能」を参照してください)。

ファイル構造

展開したパッケージの内容は、ハード ディスクの解凍先フォルダ内の複数のサブディレクトリに一貫した方法で保存されます。解凍先のフォルダ名はユーザーが指定できます。指定しなかった場合は、現在のドライブの root ディレクトリにランダムな名前のフォルダが作成されます。このディレクトリには、インストーラ、関連ファイル、およびペイロードが保存されます。ディレクトリ構造には 3 つの種類があります。どのディレクトリ構造が作成されるかは、パッケージの古さ、種類、および更新の対象となるオペレーティング システムによって決まります。以下に、標準、デュアル モード、複数ブランチ対応の各ディレクトリ構造を示します。表 12 は、各オペレーティング システムで一般的なパッケージの種類を示しています。パッケージの展開内容に関して "root ディレクトリ" という用語は、パッケージの解凍先となるフォルダと同じものを指します。

表 12: オペレーティングシステムごとのディレクトリ構造

標準ファイル構造

標準ディレクトリ構造は 3 種類の中で最も単純です (次の図 2 を参照してください)。ファイルは解凍先の root ディレクトリか Update ディレクトリのいずれかに保存されます。次の表 13 は、標準ディレクトリ構造における各ファイル、ファイルの保存先、およびファイルの目的をまとめたものです。

図 2: 標準ファイル構造の例

このファイル構造の例は、セキュリティ情報 MS03-026 に関連する Windows 2000 の更新 823980 をダウンロードすると確認できます。

表 13: 標準ファイル構造における各ファイルの目的と保存先

デュアルモードファイル構造

デュアル モード インストールのファイル構造は標準インストールの場合よりやや複雑です。デュアル モード インストールでは、同じオペレーティング システムの 2 つのバージョンに対応できるようにペイロードが拡張されています。たとえば、1 つの更新を Windows XP RTM と Windows XP SP1 の両方に適用することができます (次の図 3 を参照してください)。デュアル モード インストールは Windows XP にのみ対応しています。ここでは、Windows XP RTM および Windows XP SP1 の更新を目的として作成されたデュアル モード インストール パッケージを前提としています。デュアル モード インストールの詳細と、このようなインストールが必要となる理由については、「導入のタイミング」の「修正プログラムの移行」を参照してください。

デュアル モード インストールの場合、ファイルは次の 4 つのディレクトリに展開されます。

図 3: デュアルモードファイル構造の例

このファイル構造の例は、セキュリティ情報 MS03-026 に関連する Windows XP の更新 823980 をダウンロードすると確認できます。表 14 は、各ファイルの目的と保存先を示しています。

表 14: デュアルモードファイル構造における各ファイルの目的と保存先

複数ブランチ対応ファイル構造

複数ブランチ対応インストールは Windows Server 2003 でのみ使用可能であり、デュアル モード インストールの場合と同じように、1 つのパッケージで複数のインストール シナリオに対応します。複数ブランチ対応の更新では、デュアル モード インストールのシナリオに対応できるほか、オペレーティング システムのサービス パック レベルが同じである 2 種類の開発環境も更新することができます。あるサービス パックから次のサービス パックがリリースされるまでの間に、ブランチと呼ばれる開発環境から更新がリリースされます。ブランチには、GDR (General Distribution Releases) ブランチと修正プログラム ブランチの 2 つがあります。セキュリティ上の脆弱性などの広範囲に及ぶ重大な問題への対応策として Microsoft がリリースする更新は GDR と呼ばれ、Windows Update から配布されます。このような更新は他の修正プログラムとは別に GDR ブランチで作成されます。修正プログラムは、ユーザーから要望のあった特殊な問題に対処する目的で Microsoft 製品サポート サービスが配布するもので、GDR ほどの徹底した検証は行われません。このように 2 つのブランチがあることで、GDR を入手して広範囲に及ぶ重大な問題 (セキュリティ上の脆弱性など) だけを解決し、修正プログラムのコード変更を加えないことができるため、ユーザーにとってリスクが小さくなります。複数ブランチの詳細については、「Windows Server 2003 製品アップデート パッケージの内容に関する説明」を参照してください。どちらのブランチで作成されたものであっても、修正コードは必ず次のサービス パックに含められます。

複数ブランチ対応の更新を解凍すると、root ディレクトリの下に更新ディレクトリと共に関連ブランチのバイナリ ファイルが収められた複数のディレクトリが作成されます。これらのディレクトリには図 4 に示すような名前が付きます。ディレクトリ名の前半は製品のマイルストーンを表します (たとえば、RTM は Release To Market を意味し、SP1 は Service Pack 1 を意味します)。ディレクトリ名の後半が更新を作成したブランチ (開発環境) を表します。次の図では、GDR と QFE がブランチを表しています (複数ブランチ対応の更新では、QFE が修正プログラムを意味する略語として使用されており、修正プログラム ブランチを表す標準の名前となっています)。

このディレクトリ構造では、インストーラとペイロードによってディレクトリが分けられています。インストーラは更新のインストールに必要な関連ファイルと共に Update ディレクトリに保存され、ペイロードは RTMQFE と RTMGDR の 2 つのディレクトリに保存されます。

図 4: 複数ブランチ対応ファイル構造の例

このファイル構造の例は、セキュリティ情報 MS03-026 に関連する Windows Server 2003 の更新 823980 をダウンロードすると確認できます。表 15 は、各ファイルの目的と保存先を示しています。

表 15: 複数ブランチ対応ファイル構造における各ファイルの目的と保存先

ページのトップへ

まとめ

Microsoft の Windows パッケージ インストーラは、オペレーティング システムおよびインストール済み製品にサービス パックや更新を適用することを目的とした全機能搭載のインストーラです。このインストーラは、ユーザーや製品グループの要求に応えながら発展していきます。標準モードやネットワーク インストールなどのインストール方法を使用できるほか、インストール バッチ ファイルを使用してインストーラの処理を制御することもできます。導入方法を検討する際の情報源としては、サービス パックに付属の導入ガイドが最適です。

このドキュメントでは、インストーラがファイルのコピー以外にどのような操作を実行するのかを十分に理解できるよう、インストーラの機能について詳しく説明しました。また、レジストリに加えられる変更やレジストリ エントリの働きについても詳しく解説し、インストール ログ ファイルに書き込まれる内容にも触れました。さらに、パッケージ構造にも説明を加え、パッケージの主要なディレクトリ構造などを紹介しました。

このドキュメントは 2003 年 12 月現在のインストーラ テクノロジに関するものです。インストーラの機能がユーザーの要求に対応して変更されたときには、このドキュメントにも変更が加えられるため、改訂版が発行されていないかどうかを定期的にチェックしてください。

ページのトップへ

付録 A インストーラのバージョン管理と機能

バージョン管理

インストーラの統一を目的として、さまざまな製品グループがコード修正のインストーラを Update.exe に切り替え始めています。効率性をさらに高めるために、2003 年、Update.exe の開発チームは開発サイクルを四半期ベースに変更し、Update.exe の新バージョンを 3 か月ごとにリリースしました。2004 年は、1 年を 3 つの期間に分割し、4 か月ごとに新リリースを提供する予定です。

修正プログラムについては、最新のインストーラ機能と組み合わせて動作を検証します。したがって、エラーの発生を防止するためには、付属の Update.exe とは異なるバージョンの Update.exe で修正プログラムをインストールしないことが必要です。

各インストーラ バージョンの機能

次の表は、Update.exe の各バージョンの主要な追加機能とリリース時期をまとめたものです。個々のインストーラ機能について、Update.exe の各バージョンと機能の相互参照を示しています。この表に挙げた機能の多くは、エンド ユーザーへの直接的な影響はありません。更新パッケージ インストーラを採用する Microsoft チームと追加機能を必要とする Microsoft チームが一致しない場合もあります。

表 16: 各インストーラバージョンの機能

メモ Windows Server 2003 の初期の更新は、バージョン 5.3.17.9 の Q2 インストーラと共にリリースされました。このバージョンの機能セットは、上に記載されている Q2 インストーラのものと同じです。

インストーラのバージョン確認

インストーラに追加された機能が理解できたら、インストーラのバージョンを見分けられるようになることが必要です。そのためには、パッケージの内容を展開します。展開したら、該当するパッケージのディレクトリ構造の表を使用して Update.exe を探します。バージョン番号を表示するには、まず Update.exe を右クリックし、ショートカット メニューの [プロパティ] をクリックします。[update.exe のプロパティ] ダイアログ ボックスの [バージョン情報] タブをクリックします (次の図 5 を参照してください)。

図 5: インストーラのバージョンの例

ページのトップへ

付録 B Update.inf ファイル

ここでは、Update.inf ファイルの主要なセクションについて説明します。このリファレンスを参照するときには、.inf ファイルではエントリの位置が意味を持たないことに留意してください。ただし、ほとんどのファイルでは一定の順序に従ってエントリが配置されています。次に挙げるサンプル ファイルでは、わかりやすくするためにエントリの順序を変えています。

Version 更新が適用される製品のバージョンを示します。このセクションのエントリによって、更新が適用可能なバージョンの範囲が定義されます。ToUpdate の値は更新できる最低バージョンを示し、Max の付いている値は最高バージョンを示します (このバージョン範囲はレジストリ エントリ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ CurrentBuildNumber の設定と照合されます)。

Version セクションの一般的なエントリは以下のとおりです。

[Version]    
  Signature="$Windows NT$"    
  LanguageType=%LangTypeValue%    
  NtBuildToUpdate=3790    
  MaxNtBuildToUpdate=3790    
  NtMajorVersionToUpdate=5    
  MaxNtMajorVersionToUpdate=5    
  NtMinorVersionToUpdate=2    
  MaxNtMinorVersionToUpdate=2    
  MinNtServicePackVersion=0    
  MaxNtServicePackVersion=0    
  ThisServicePackVersion=0    
  CatalogFile=%SP_SHORT_TITLE%.cat

DirectoryID.Include 実行時にプロセスを使用してインストール先を決定します。

次の例では、AddDirID が後続の RISAdm.DirID セクションを指し示しています。RISAdm.DirID セクションには実行されるアクションが指定されます。この例では、SPCustom.dll RISAdminSection に含まれている機能です。

[DirectoryId.Include]    
  AddDirId=RISAdm.DirId    
…    
[RISAdm.DirId]    
  DirId = 65625    
  CustomFunction=SpCustom.dll,GetRISAdminPathName    
  InstallFromSection = RISAdminSection    
  CopyFlags = SP_COPY_FORCE_NEWER | SP_COPY_REPLACEONLY

ProductCatalogsToInstall インストールされるカタログの名前と場所を示します。この例で使用されている変数 %SP_SHORT_TITLE% は .inf ファイルの Strings セクションで解決されます (以下を参照してください)。

[ProductCatalogsToInstall]    
  %SP_SHORT_TITLE%.cat, update\%SP_SHORT_TITLE%.cat

ProductInstall.CopyFilesAlways インストール中にコンピュータに必ずコピーすることが必要なファイルの詳細があるセクションを示します。

[ProductInstall.CopyFilesAlways]    
  CopyFiles=CopyAlways.System32.files    
  CopyFiles=CopyAlways.Inf.files

ProductInstall.CopyFilesAlways.platform_name 必ずインストールされるファイルがプラットフォーム名ごとに定義されています。プラットフォーム名はセクション名の終わりにあります。次の例では、Professional および Server プラットフォームで使用されるファイルの詳細が記述されています。

[ProductInstall.CopyFilesAlways.Professional]    
  CopyFiles=CopyAlways.Prf.System32.files    
[ProductInstall.CopyFilesAlways.Server]    
  CopyFiles=CopyAlways.Srv.System32.files    
  CopyFiles=CopyAlways.Srv.Inf.files

ProductInstall.ReplaceFilesIfExist 既にインストールされている場合に置き換えられるファイルが指定されています。コピーするファイルの詳細については、CopyFiles ディレクティブで参照される別のセクションにあります。次の例の CopyFiles ディレクティブではコピーするファイルを指定するため、System32.files と Cache.files という 2 つのセクションを参照しています。

[ProductInstall.ReplaceFilesIfExist]    
  CopyFiles=System32.files    
  CopyFiles=Cache.files    
…    
[System32.files]    
  urlmon.dll,RTMGDR\urlmon.dll    
[Cache.files]    
  urlmon.dll,RTMGDR\urlmon.dll

ProductInstall.GlobalRegistryChanges.Install インストール中に追加されるレジストリ キーがあるセクションを示します。次の例の AddReg ディレクティブは、レジストリ キーが指定された Product.Add.Reg セクションを参照しています。

ProductInstall.GlobalRegistryChanges.Install]    
  AddReg=Product.Add.Reg    
…    
[Product.Add.Reg]    
  HKLM,SOFTWARE\Microsoft\Windows    
NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed",0x10001,1    
 [ProductInstall.CopyFilesAlways.Professional]

DestinationDirs ファイルのインストール先ディレクトリを定義します。次の例では、システム ディレクトリが %windir%\system32 と定義され、システム .dll キャッシュ ディレクトリが %windir%\system32\DllCache と定義されています。

このセクションは後続の System32.files セクションおよび Cache.files セクションを参照しています。DestinationDirs セクションには、ターゲット ディレクトリの定義とインストールの対象となるファイルの一覧が指定されたセクションへのポインタがあります。パッケージ インストーラは、DestinationDirs セクションを読み取った後、インストールするファイルの名前とコピー元を System32.files セクションおよび Cache.files セクションから取得します。