• [アーティクル]

特集 : Windows Server 2008

IIS 7.0 の概要

Isaac Roybal

 

概要:

  • IIS 7.0 のアーキテクチャの変更点
  • IIS 7.0 の管理
  • 下位互換性
  • IIS 7.0 のトラブルシューティング

IT 企業はそれぞれ異なっています。各環境には独自のニーズや目的があり、特に Web サイトや Web サービスのホストのニーズや目的は環境によって異なります。Web サーバーには、組織の要件を満たすためにあれこれが少しずつ必要になることがあります。さらに、

その構成を複数のサーバーに複製すると同時に、すべてのサーバーを効率的に管理するという問題もあります。インターネット インフォメーション サービス (IIS) 7.0 の最大の変更点のうちいくつかは、IT 企業が Web サーバーまたは Web ファームを構築する際に上記の作業を正確に実行できるようにすることを目的としています。

IIS 7.0 の優れた機能すべての一覧に目を通すうちに、私はこのような機能の詳細を皆さんにお知らせできることが、非常にうれしくなりました。おそらくすべての機能を紹介することはできないと思ったので、この記事では IIS 7.0 の特に重要な機能や大きな変更点の一部に焦点を合わせることにしました。IIS 7.0 の詳細については、IIS.net の IIS コミュニティ Web サイトを参照してください。

新しいアーキテクチャ

IIS 7.0 の主要な変更点は、アーキテクチャ、要求の処理、PHP アプリケーション フレームワークのサポート、および構成ストアに関連しています。基本的に、IIS 6.0 では、機能をすべてインストールするか、まったくインストールしないかのどちらかしか選べませんでした。また、すべての機能をインストールする必要があるうえに、ISAPI を使用しなければ IIS をカスタマイズできませんでした。

IIS 7.0 は、Web 管理者が、基本的な一連の機能を基に、各自の環境に応じて、必要な追加機能のみをインストールできる機能を求めているということを前提に構築されています。環境に最も詳しいのはその環境の Web 管理者ですから、IIS 7.0 には独自の Web サーバーを作成するための構成要素が用意されています。これにより、サーバーが攻撃を受ける危険が回避され、使用しないコンポーネントを更新する必要がなくなるので、管理オーバーヘッドが削減されます。この新しい手法の鍵となるのが、IIS 7.0 のモジュール型のアーキテクチャです。

IIS 7.0 の新しい設計により、サーバーにインストールする機能 (モジュール) を選択できます。モジュールは統合された要求パイプラインに直接追加されます。この新しいモジュールの設計には、攻撃を受ける危険性と Web サーバーのサイズの両方を削減するなどいくつかの長所があります。

IIS 7.0 には現在 40 個の既定のモジュールがあります。たとえば、基本認証、匿名認証、および Windows® 認証は、個々のモジュールとして要求パイプラインに個別に追加できます。簡単に分類すると、モジュールは 8 つのサブカテゴリにまとめられています (図 1 参照)。

図 1 8 つの機能領域に分類されている IIS 7.0 のモジュール

図 1** 8 つの機能領域に分類されている IIS 7.0 のモジュール **(画像を拡大するには、ここをクリックします)

つまり、環境に合わせてカスタマイズされた Web サーバーを構築できます。では、カスタム認証やコンテンツの変更機能など、40 個の既定のモジュールでは利用できない機能が必要な場合はどうでしょうか。問題ありません。必要に応じてネイティブ コードまたはマネージ コードでモジュールを記述して、パイプラインに直接追加できます。この機能によって、マイクロソフトでは新しいモジュールを個別に記述してリリースできるので、次のサービス パックまたは製品のメジャー リリースを待つ必要はありません。また、IIS 7.0 では 40 個の既定のモジュールを独自のカスタム モジュールで上書きできます。独自のモジュールを作成する方法の詳細については、IIS.net を参照してください。

統合された要求パイプライン

統合された要求パイプラインは、ページが提供されるときに必ず発生する一連の重要かつ決まった手順と考えられます (図 2 参照)。通常は、まずなんらかの認証が必要です。その後、コンテンツの取得を承認し、コンテンツに必要なハンドラを特定して実行し、必要なログを記録して、最後に応答を送信します。統合された要求パイプラインを使用すると IIS 7.0 の柔軟性が向上し、異なるアプリケーション フレームワークを同時に実行できます。たとえば、カスタムのログ記録モジュールを使用して、PHP コンテンツでフォーム認証を行えます。また、これらの操作は、すべて同じパイプラインで実行できます。

図 2 IIS 7.0 の統合されたパイプラインとモジュール

図 2** IIS 7.0 の統合されたパイプラインとモジュール **(画像を拡大するには、ここをクリックします)

サーバー上の各 Web サイトには統合された要求パイプラインがあり、統合とクラシックという 2 つのモードのいずれかで実行できます。既定のモードである統合モードでは、特定の機能をパイプラインに追加できるので、要求の処理をきめ細かく制御できます。また、互換性を重視したクラシック モードでは、ISAPI モジュールをパイプラインに追加して、IIS 6.0 または ISAPI の機能を再現します。このモードは、アプリケーションを IIS 7.0 に移行する際にたいへん便利です。

既定のインストール

では、新しいモジュール型の Web サーバーのセットアップについて説明します。IIS 7.0 の既定のインストールを確認すると、モジュールが 10 個しか含まれていない (Windows プロセス アクティブ化サービスを含めた場合) ことがわかります。IIS 7.0 のセットアップでは、Web サーバーの役割をインストールするときに IIS の基本機能をインストールします。この基本機能には、プレーンな HTML や Classic ASP などの静的コンテンツを提供するのに必要なモジュールだけが含まれています。この後でサーバーにインストールするモジュールについては、完全に皆さんの自由です。既定のインストールに含まれる機能は次のとおりです。

  • 静的コンテンツ、既定のドキュメント、ディレクトリの参照、HTTP エラーなど、一般的な HTTP の機能
  • HTTP ログ記録、HTTP 要求監視などの健常性と診断機能
  • 要求フィルタなどのセキュリティ機能
  • 静的なコンテンツの圧縮などの性能機能
  • IIS 管理コンソールなどの管理ツール
  • Windows プロセス アクティブ化サービス

ご覧のとおり、これは必要最低限の機能を備えたサーバーです。ASP.NET も、診断機能やトラブルシューティング機能などの IIS 7.0 のその他の新機能も含まれていません。ただし、ASP.NET や FastCGI (PHP) を提供する機能などの追加機能は、簡単にサーバーで有効にできます。Windows Server® 2008 のサーバー マネージャにある、Web サーバーの役割に関する [役割サービスの追加] でインストールするモジュールを選択します。

新しい構成ストア

作業を簡単にする IIS 7.0 のもう 1 つの重要な変更点は、新しい構成ストアです。メタベースは、下位互換性を維持するためにオプションでインストールするコンポーネントになり、XML の構成システムに置き換わりました。メタベースも XML だったと指摘される方もいらっしゃるかもしれませんし、確かにそうでした。しかし、メタベースは扱いにくく、(少なくとも人間にとっては) 簡単に解読できません。そのため、メタベースはより柔軟な XML システムに置き換わりました。IIS 7.0 では、ASP.NET のように、すっきりと簡潔で、移植性が高く、読みやすい .config ファイルを使用します。

この形式に変更することで、個別のコンピュータに固有のメタベースとは異なり、構成システムがコンピュータに依存しなくなります。このため、単にドラッグ アンド ドロップするか、xcopy を実行するだけで構成システムを他のサーバーにコピーできます。

この新しい構成システムは、共有構成という IIS 7.0 の新機能を使用することで、Web ファームですばらしい効果を発揮します。この新しい構成システムは高い移植性を備えているので、基になる .config ファイルをファームのすべてのノードで共有できます。共有構成を使用すると、正常であることを確認した運用前のサーバーの構成をエクスポートして、運用環境 (つまり使用中の環境) で共有できます。

.config ファイルをエクスポートするときは、暗号化キー パスワードを設定する必要があります。パスワードを設定すると、.config ファイルが保護され、悪意のある Web サーバーが承認なしにサーバーの .config ファイルを模倣するのを防ぐことができます。

共有構成は簡単に有効にできます。IIS マネージャのサーバー ノードで、作業ウィンドウの [管理] セクションにある [共有構成] をクリックし、[共有構成の有効化] チェック ボックスをオンにして、共有する構成の物理パス (通常は UNC 共有) を指定します。次に、物理パスに接続するために必要な資格情報を入力し、[適用] をクリックします。.config ファイルが検出されると、暗号化のパスワードを入力するよう要求されます。この操作が完了したら、IIS マネージャを再起動して、新しい .config ファイルを適用します。

新しい構成システムの構造は従来の構造と異なるので、主なポイントを説明します。図 3 に示すように、IIS 7.0 の構成は、サーバー全体の設定とサイト固有の設定の 2 種類に分けられています。サーバー全体の設定はすべて、%systemroot%\windows\system32\inetsrv\config フォルダの applicationhost.config に保存されます。このファイルには、インストールされているすべてのモジュール、サーバー上のサイトなどの設定が含まれています。サイト固有の設定は個別の web.config ファイルに保存されます。

図 3 サーバー全体の設定を含む .config ファイルが 1 つと、そのサーバー上の各 Web サイトの設定を含む個別の .config ファイルがあります

図 3** サーバー全体の設定を含む .config ファイルが 1 つと、そのサーバー上の各 Web サイトの設定を含む個別の .config ファイルがあります **(画像を拡大するには、ここをクリックします)

ASP.NET を使用したことがある方は、web.config ファイルをよくご存知でしょう。IIS 7.0 では、web.config ファイルを使用して、サイトの既定のドキュメントとアプリケーションの設定や ASP.NET の設定など、個々の Web サイトに固有の設定を保存します。つまり、各サイトの web.config ファイルをサーバーに保存できます。

サイトの web.config ファイルは、%systemroot%\inetpub\wwwroot など、サイトの物理パスにあります。このような設定によって、サイト レベルでも同様に先に説明したような移植性が向上します。たとえば、テスト サーバーでサイトを開発した後、単純にドラッグ アンド ドロップまたは xcopy を使用して、サイトの web.config ファイルとアプリケーション ファイルを実稼動サーバーに配置できます。

.config ファイルを移植または共有する場合は、IP アドレスやドライブ文字など、コンピュータに固有の情報に注意する必要があります。IIS 7.0 では、このような情報を見落とした場合に備えて、OS の環境変数 (%systemroot% など) をサポートしています。また、テスト サーバーと実稼動サーバーで同じ組み合わせのモジュールがインストールされているかどうかも確認する必要があります。これにより、予期していないアプリケーション エラーを防ぐことができます。エラーは、インストールされていないモジュールを web.config が参照している場合や既定のモジュールとカスタム モジュールが競合している場合に発生することがあります。

Web サーバーを管理する

これで、優れていて新しく、カスタマイズができ、柔軟性と移植性の高い Web サーバーを使用できます。この Web サーバーを管理するにはどうすればよいでしょうか。管理は IIS 7.0 の計画と開発において重要な部分だったので、管理作業を行う方法はいくつかあります。

管理方法の好みは一般的に、次の 3 種類の少なくとも 1 つに分類できます。3 つの種類とは、UI をポイントしてクリックする方法、コマンド ラインからコマンドを入力する方法、およびスクリプトを作成してできる限り作業を自動化する方法です。では、まず UI について説明しましょう。

IIS 6.0 の Microsoft® 管理コンソール (MMC) スナップインでは、ツリー表示とタブ表示という 2 つの基本的でなじみのある表示形式が使用されていました。設定を詳しく調べる場合、右クリックをして [プロパティ] をクリックすると、オプション ボタンやチェック ボックスはもちろん、たくさんのタブが表示されました。

さいわい、IIS 7.0 の UI は完全に一新され、この IIS マネージャという UI は、タスク指向の手法を使用できるように設計されました (図 4 参照)。Windows XP や Windows Server 2003 などの下位レベルのクライアント用の Remote Manager (リモート マネージャ) もあり、このツールは IIS.net のダウンロード サイトからダウンロードできます。

図 4 IIS 7.0 の新しい UI

図 4** IIS 7.0 の新しい UI **(画像を拡大するには、ここをクリックします)

新しいユーザー インターフェイスは、左側に接続ウィンドウ、右側に操作ウィンドウ、中央に作業ウィンドウ (ワークスペース) が配置されています。左側の接続マネージャのツリーは、IIS 6.0 の親ノードと子ノードがあるツリー表示に似ています。このツリー表示に新たに追加された機能は、新しい接続を作成、現在の接続を保存、および既存の接続を削除する機能です。最も強化された UI は、作業ウィンドウで、このウィンドウでは 2 種類の表示形式を使用して作業できます。1 つ目の表示形式である機能ビューには、従来のタブに表示されていたすべての構成可能なプロパティが表示され、IIS、管理、セキュリティなどの管理の分野ごとにグループ化されています。

ASP.NET のプロパティも IIS マネージャに統合されているので、別の MMC スナップインを使用する必要がありません。構成可能なプロパティにはそれぞれ専用のアイコンがあり、簡単に見つけることができます。また、IIS マネージャは Windows フォーム アプリケーションとして構築されているので、独自に記述したカスタム モジュールやカスタム機能に組み込みのアイコンを追加できます。

作業ウィンドウの 2 つ目の表示形式はコンテンツ ビューです。このビューには、サイトのコンテンツ ディレクトリの内容が表示され、表示されたコンテンツを操作できる点は IIS 6.0 と同じです。コンテンツ ビューの新機能は、特定のコンテンツ (たとえば、特定の Web ページ) を選択してから機能ビューに切り替えると、選択したコンテンツの設定を表示できる機能です。この機能を使用すると、ページ単位できめ細かく管理できます。

その他の管理方法

コマンド ラインが好きな方には、APPCMD.exe と言う名前の強力な新しいツールがあります。このツールを使用すると、サイトの停止や現在の .config ファイルのバックアップ作成などの単純な作業から構成のスキーマの検索などの複雑な作業まで、さまざまな作業を実行できます。次のように、APPCMD.exe の構文は非常に単純です。

APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.

APPCMD で使用できるすべてのオブジェクトを一覧表示するには、以下のように入力します。

APPCMD /?

また、特定の種類のオブジェクトに使用できるコマンドを確認するには、次のように入力します。

APPCMD (object-type) /?

IIS 7.0 では、開発者向けに、Microsoft.Web.Administration という名前のマネージ コード API と新しい Windows Management Instrumentation (WMI) プロバイダが追加されました。この 2 つの方法を使用すると、スクリプトの作成、自動化、IIS 7.0 を管理するツールの記述など、さまざまな処理を実行できるようになります。どちらも Windows PowerShell® で使用でき、VBScript や JScript® で WMI プロバイダを使用することもできます。詳細については、blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx を参照してください。

リモート管理と管理の委任

IIS 7.0 では、サーバー、サイト、Web アプリケーション、および管理者以外のユーザーに安全に委任された管理権限をリモートで管理する新しい方法が用意されています。まず、新しいリモート管理機能と、この機能を使って作業を簡単にする方法について説明します。

これまで、IIS サーバーをリモートで管理する方法は、リモート管理の Web サイトを使用する方法とリモート デスクトップやターミナル サービスを使用して UI にアクセスする方法の 2 種類でした。ただし、ファイアウォールの外側にいる場合や、オンサイトで作業していない場合は、これらの方法はあまり便利ではありませんでした。IIS 7.0 では、ファイアウォールに対応した HTTPS 経由で機能するリモート管理機能を直接 UI に組み込むことで、この問題を解決しています。

IIS 7.0 のリモート管理機能を使用すると、いくつかの方法で作業を簡単にできます。まず、ローカルでログオンした場合と同じ UI を使用できます。また、HTTPS 経由で通信するので、ファイアウォールでポートを開く必要がありません。さらには、1 つの UI で複数のサーバーを管理できるので、リモート デスクトップやリモート Web サイトのウィンドウを同時にいくつも開く必要はありません。

IIS 7.0 の実際のリモート管理サービスは、基本的に小規模な Web アプリケーションです。このアプリケーションは別のサービスとして、NT Service\WMSVC という Windows NT® のローカル サービス アカウントで実行されます。このように設計されているので、IIS 自体が応答しない状態でもリモート管理機能が維持されます。

IIS 7.0 のほとんどの機能と同様に、セキュリティ上の理由から、リモート管理は既定ではインストールされていません。リモート管理機能をインストールするには、管理ツールにある Windows Server 2008 のサーバー マネージャで、Web サーバーの役割の役割サービスを追加します。この機能をインストールしたら、リモート接続を有効にし、WMSVC サービスを開始します (このサービスは既定では停止されています)。

WMSVC サービスは既定では手動で開始するように設定されています。再起動後にサービスが自動的に開始されるようにするには、設定を自動に変更する必要があります。このように設定するには、コマンド ラインで次のコマンドを入力します。

sc config WMSVC start=auto

管理サービスでリモート接続を有効にすると、資格情報の識別、接続、IPv4 アドレスの制限などの設定の一覧が表示されます。この時点で唯一重要な決定事項は、"Windows 資格情報のみ" または "Windows 資格情報と IIS マネージャ資格情報" のどちらの ID 資格情報に対して IIS 7.0 に接続するアクセス許可を与えるかを決定することです。

1 つ目の選択肢は非常に忘れられがちなものですが、ローカル アカウントまたはドメイン アカウントであるかにかかわらず Windows ユーザー アカウントのみを許可することを示します。2 つ目の選択肢は、Windows ユーザー アカウントと、IIS マネージャ ユーザーというユーザーのアカウントの両方を対象にしています。IIS マネージャ ユーザーは IIS 7.0 で導入された新しいアカウントで、Windows ユーザー アカウントとの関連はありません。IIS マネージャ ユーザーを使用すると、管理者は IIS 7.0 のコンテキストでのみ認識され、OS にはアクセスできないユーザー アカウントを作成できます。また、既定では、IIS で自己署名入りの証明書が提供されますが、有効な署名入りの SSL 証明書を追加で使用することをお勧めします。あとは、設定を適用してサービスを開始するだけです。

その他の制御とセキュリティについても、IT 管理者は、個々のサイトや Web アプリケーションの管理作業を管理者以外のユーザーに安全に委任できます。

委任された管理は、基本的にはリモート管理ですが、アクセスできる範囲が個々のサイトや Web アプリケーションに制限されます。この場合、IIS マネージャ ユーザーの機能は特に便利です。IIS ユーザーを単独のサイトの所有者用に作成して、所有するサイトまたはアプリケーションを管理するアクセス許可を委任できます。サイトの所有者はサーバー全体の設定にアクセスできず、所有する特定のサイトまたは Web アプリケーションの設定しかできません。

また、ユーザーが設定できる機能や設定を指定したり、UI に表示する機能や設定を指定したりすることができます。たとえば、サイトで使用している認証方法を変更できないようにするには、この機能を読み取り専用または継承されないように設定します。機能が読み取り専用の場合、ユーザーは機能にアクセスして設定を確認できますが、変更することはできません。継承されないように設定されている場合は、管理を委任されたユーザーの IIS マネージャのウィンドウにはその機能のアイコンが表示されません。このような機能の委任を使用すると、Web サーバーに対する管理者レベルの制御を提供せずに、他のユーザーに厳密に制御されたアクセスを提供できます。

IIS 7.0 に移行する

IIS 7.0 を設計するとき、チームは、IIS 6.0 の管理ツールやスクリプトに対する既存の投資を活用できるようにして、できる限り円滑な移行を行えるようにすることを目指しました。IIS 7.0 が IIS 6.0 のスクリプトと連携するよう、IIS 7.0 の下位互換性機能にはさまざまな工夫が盛り込まれました。IIS 6.0 メタベース互換から実際の IIS 6.0 管理コンソールまで、すべてのツールが揃っています。これらのツールは、セットアップの [IIS 6 と互換性がある管理] ノードでインストールできます。

IIS 6.0 メタベース互換のインフラストラクチャでは、ADOMapper というコンポーネントが使用されます。このコンポーネントを使用すると、IIS 6.0 の Admin Base オブジェクト (ABO)、および Active Directory サービス インターフェイス (ADSI) のメタベース スクリプトを、新しい構成システムの IIS 6.0 の機能に限定して実行できます。したがって、このようなスクリプトでは、新しい IIS 7.0 のプロパティの読み取りや書き込み、新しいランタイム データへのアクセス、ASP.NET のプロパティや web.config ファイルの読み取りや書き込みを実行することができません。

トラブルシューティングと診断

トラブルシューティングと診断は、常に時間のかかる作業でした。ログを詳しく調べて問題を再現することは、大規模な Web ファームはもちろん、1 台のサーバーでも難しい場合があります。IIS 7.0 で導入された要求トレースというツールを使用すると、このような労力と無駄な時間を削減することができます。このツールは、要求がハングしたりエラーが発生した場合や、認証や承認に関する問題を調査する場合など、さまざまな状況で役に立ちます。

失敗したエラーを検索する条件として、要求トレースではトレース規則を使用します。トレース規則を作成して、動作やエラーの種類を検索できます。トレース規則の作成時には、トレースするコンテンツの種類 (たとえば、サーバー上のすべてのコンテンツ、ASP.NET コンテンツのみ、PHP などのカスタム コンテンツ) を指定したり、トレースを開始する条件 (特定の状態コードが返された場合、ページを提供するまでの所要時間、イベントの重大度、これらの条件の組み合わせなど) を指定したりできます。

たとえば、サイトが読み込まれるまでの時間が長すぎるとユーザーから報告を受けたとします。この問題の再現は、どのようなシナリオでも難しいものですが、特に 1 時間に数千回ものアクセスがあるサイトで再現するのは困難です。失敗した要求トレースを使用すれば、問題を再現するのに必要な作業は、ページを読み込む時間が目標の時間 (たとえば 2 秒間) を超えたときにログの記録を開始するようなトレース規則を追加して、あとはサーバーで問題が再発生するのを待つだけです (図 5 参照)。

図 5 失敗した要求トレースを使用したトラブルシューティング

図 5** 失敗した要求トレースを使用したトラブルシューティング **(画像を拡大するには、ここをクリックします)

失敗した要求トレースと従来のログ記録の違いは、失敗した要求トレースでは失敗した要求の特定の条件が検出されたときにのみログが記録される点です。ログ ファイルの形式は XML ですが、XML スタイル シートが適用されているので、簡潔で読みやすいファイルです。他のほとんどの IIS 7.0 機能と同様に、この機能は、既定ではインストールされませんが、セットアップの [健常性と診断] セクションでインストールできます。また、IIS マネージャで有効にする必要があります。

IIS 7.0 はすべての管理者にとって大きな前進です。IIS 7.0 の新しいアーキテクチャと機能がもたらす機敏性と柔軟性があれば、変わり続ける環境に適応できます。また、IIS 7.0 の管理機能、下位互換性、およびトラブルシューティング機能を使用すれば、今日にでも IIS 7.0 を展開して既存の環境と連動させることができます。

Isaac Roybal は、マイクロソフトで Windows Server のプロダクト マネージャを務めており、Windows Server の Web に関連するあらゆる事柄を担当しています。Isaac は Windows NT 3.51 と IIS 4.0 以降 Windows Server に携わってきました。それ以前は、Office Internet Platform and Operations グループのオペレーション プログラム マネージャでした。彼は Windows NT 4.0、Windows 2000、および Windows Server 2003 の MCSE 認定資格を取得しています。

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