IIS 7 以降のメタベース互換性

投稿者 : Saad Ladki

はじめに

IIS 7 以降の構成システムは、API レベルのレガシ構成インターフェイスと互換性があります。 これは、管理ベース オブジェクト (ABO) インターフェイス (IMSAdminBase とも呼ばれます) と、IIS 6.0 の ABO 上に構築された ADSI および WMI プロバイダーをサポートします。 IIS のメタベース互換性コンポーネントがインストールされている限り、既存のアプリケーションとスクリプトは引き続き IIS 7.0 以降のプログラム インターフェイスを呼び出して動作し続けることができます

Note

規定では、このコンポーネントはインストールされません。

メタベース互換性サポートのインストール

このコンポーネントは、インターネット インフォメーション サービス->Web 管理ツール -> IIS 6.0 管理機能機能のセットアップで確認できます。

最初から IIS を使用するように設定されていないため、このコンポーネントは既定ではインストールされていません。 レガシ インターフェイスにはいくつかの制限があり、分散構成ファイルの操作には適していません (後述の「制限事項」セクションを参照)。そのため、時間の経過と共に、特に、より多くの委任のために構成システムを開く場合 (つまり、IIS 設定が含まれる web.config ファイルがシステム上に存在する場合) は、レガシ スクリプトとアプリケーションを新しいシステムとそのインターフェイスに移植することを検討することをお勧めします。

新しいインターフェイスを使用して新しいスクリプトとアプリケーションを開発することもお勧めします。新しいシステムで理想的に動作し、構成システムの新しいプロパティ、概念、構造にアクセスできるようにするためです。

すべてのレガシ スクリプトとアプリケーションを新しいインターフェイスに移植されたら、メタベース互換性機能をアンインストールすることをお勧めします。

メタベース互換性のしくみ

メタベース互換性機能は、メタベース サービス (IISADMIN) 内で実行されます。 ABO へのすべてのメソッド呼び出しをインターセプトします。 メソッド呼び出しの情報が Web サーバー構成に関連している場合は、新しいシステムにマップされます。 FTP、SMTP、NNTP の構成に関連する場合は、Metabase システムの通常のロジックに従い、メタベース ファイルに格納されます。

Web サーバー構成の下にあるカスタム プロパティも、新しいシステムにマップ (および永続化) されることに注意してください。

マッピングの決定は、問題のメタベース ノードに基づいています。 Web サーバーの構成は、通常、カスタム プロパティを含む LM/W3SVC の下にあり、Mime Maps などのいくつかの追加機能があります。

マッピングは、ABO ビューと新しいシステム ビューの間を前後に変換するために行われます。 たとえば、新しいシステムには、各サイトの下とすべての仮想ディレクトリの上に、アプリケーションの概念があります。 レガシ システムでは、アプリケーションの処理方法が異なります。アプリケーションとしてマークする特別なプロパティを持つ単純な仮想ディレクトリ (AppIsolated または AppRoot) です。

ABO を呼び出して Web サーバー構成を記述すると、メタベース互換性コンポーネントによって applicationHost.config にデータが保持されます。これは、情報がメモリ内に保持されないため、"書き込みスルー" と呼ばれます。 Web サーバー構成を読み取るために ABO を呼び出すと、メタベース互換性コンポーネントによって applicationHost.config から読み取られます。情報が再びメモリからフェッチされないため、これは "読み取りスルー" と呼ばれます。

サーバー ランタイムで使用する準備ができていない不完全なデータは、customMetadata と呼ばれる applicationHost.config の特別なセクションに保持されます。 このセクションはメタベース互換性機能の永続的なストアとして使用されます。お客様はコンテンツを変更しないでください。 不完全なデータの例として、レガシ スクリプトによってサイト ID が設定されたが、サイト バインドが設定されていない場合などがあります。 IIS 6.0 では、このような呼び出しによって構成に無効なサイト オブジェクトが作成されていました。 IIS 7.0 以降では、セクションに保持され、サーバーでは使用されません。 サイト バインドを設定するために後続の呼び出しが行われた場合、サイト オブジェクトは完全と見なされ、セクション全体で保持され、サーバー ランタイムによって取得されます。 一時データはその時点から削除されるため、ユーザーはシステムから残り物をクリーンアップする必要はありません。 このような後続の呼び出しが行われなければ、サーバー ランタイムにはこの無効なサイトは表示されませんが、レガシ スクリプトでは IIS 6.0 と同様に ABO ビューに表示されます。 レガシ スクリプトの観点からは、このシステムは IIS 6.0 と完全に互換性があります。

レガシ スクリプトとアプリケーションを使用して設定されたカスタム Web サーバーのプロパティは、常にセクションに保持されます。 IIS 6.0 と同様に、レガシ インターフェイスを介して取得できるため、このシステムは完全に互換性があります。 明らかに、これは IIS 構成システムを拡張するための推奨される方法とは大きく異なっています。よって、IIS 7.0 以降の構成システムで提供される新しいインターフェイスと新機能を使用するために、いずれはこのようなアプリケーションを移植することを検討する理由の 1 つになります。

その他のメタベース構成データ

FTP、SMTP、NNTP の構成は引き続きメタベース システムに保持され、新しい IIS 構成システムに移植されていないことに注意してください。 これらの構成設定は、従来のプログラム インターフェイスと、metabase.xml ファイルの直接編集を使用して管理できます。

概要

メタベースのキーとプロパティに対するほとんどの操作はシームレスに動作し、ユーザーには、構成セクションや名前付きプロパティなどの新しい IIS の概念ではなく、これらの従来の概念と名前が表示されます (ABO はプロパティ ID を引き続き使用します。ADSI は、従来のプロパティ名を引き続き使用します)。

レガシ ユーザーは引き続き ADSI スキーマを使用でき、IIS 6.0 と同様に拡張することもできます。

XML ファイルの互換性

Web サーバーを拡張するカスタム構成を含む Web サーバー構成は、metabase.xmlではなく system32\inetsrv\applicationHost.config に永続的に保持されます。 そのため、レガシのサポートは API レベルであり、ファイル形式レベルではありません (これが一部のレガシ機能がサポートされない理由でもあります)。 レガシ インターフェイスの呼び出し元は、新しいファイル形式や名前付けや概念ではなく、IIS 6.0 と同様に、構成の "ABO ビュー" を取得します。

つまり、メタベース ACL などの概念がサポートされていないことを意味します。 これは、メタベースのファイル形式に密接に関連しているためです。 IIS 構成システムでは、構成ファイルで標準ファイル ACL が利用されています。 システムでは、メタベース ACL と標準ファイル ACL の間のマッピングは提供されていません。

履歴ファイル、バックアップ/復元、インポート/エクスポートなどの機能は、新しい構成システムに依存しているため、動作が異なります。 したがって、バックアップ構成に対する ABO 呼び出しは無視されます。

レガシ メタベース機能

構成監査は Windows Server® 2003 Service Pack 1 で IIS 6.0 に追加されました。 IIS 7.0 以降では現在サポートされていません。新しい構成システムは非常に異なる方法で設計されているためです (たとえば、IIS 7.0 以降ではインプロセス構成システムを使用し、IIS 6.0 は他のプロセスのユーザー コードからカプセル化された専用 NT サービスを使用しています)。

レガシ メタベースのプロパティ

レガシ プロパティのみがサポートされています。 IIS 7.0 以降の構成プロパティは、レガシ ユーザーには返されず、.NET Framework の構成プロパティも返されません。

マッピングの制限事項

マッピング アルゴリズムでは、IIS 6.0 と IIS 7.0 以降の構成システムの違いを考慮する必要があります。 たとえば、IIS 6.0 では、サイトに名前 ("サーバー コメント") は必要ありませんでした。名前が指定された場合、これらの名前を一意にする必要はありませんでした。 IIS 7.0 以降では、すべてのサイトに一意の名前が必要です。 そのため、古い ServerComment プロパティを新しい Name プロパティにマッピングすることは簡単ではありません。 マッピング アルゴリズムでは、IIS 7.0 以降の構成システムの要件であるため、サイトごとに名前が強制的に一意になります。これは、サーバーのコメントに番号を追加して一意性を作成することで行われます。 最終的な結果として、サーバー コメントに実際に設定される値は、スクリプトで指定された値とは異なります。

分散構成

メタベース互換性機能では、applicationHost.config のみがサポートされています。 web.config ファイル内の構成は、レガシ ユーザーには返されません。 場所タグは、URL ごとの構成をサポートするために applicationHost.config で使用されます。