IIS 6.0（4）

アプリケーションプール、Webサイトグループ、または単一のWebサイトを右クリックし、[新規]→[アプリケーションプール（ファイルから）]、または[新規]→[Webサイト]を選択します。 →「ファイルから」、または「新規」→「仮想ディレクトリ（ファイルから）」を選択すると、保存した設定ファイルから新しいアプリケーションプール、Webサイト、または仮想ディレクトリを作成できます。したがって、必要に応じて、オブジェクトを作成して設定し、[Save configuration to file]機能を使用してオブジェクトの設定情報をエクスポートしてから、[new]→[virtual directory（from from file）]などの機能を使用して情報を設定できます。複数のWebサイトにインポートします。つまり、テンプレートを慎重に設定してから、それを使用して新しいWebサイトを作成および設定できます。もちろん、問題がある場合は、構成情報のコピーを使用してWebサイトの設定を復元することもできます。
IIS 6.0の設定情報は移植可能であるため、アップグレードに便利なもう1つの利点があります。アップグレード時にWindows 2K /IIS 5.0に直接Windows 2003 /IIS 6.0をインストールできない場合、1台のコンピュータを交換する必要がありますこの時点で、IIS 5.0の移植不可能な構成データを新しいIIS 6.0サーバーに転送する方法に関する問題を解決する必要があります。 IIS 6.0構成データの移植性を利用するには、まず新しいWindows 2003サーバーをインストールし、元のWin 2Kサーバーの完全バックアップを作成してから、2台目のWindows 2003サーバーをWin 2Kサーバーにインストールします。アップグレードし、2台目のWindows 2003サーバーの構成データ（パスワードで暗号化）をエクスポートしてから、その構成データを新しいWindows 2003サーバーにインポートします。新しくインストールされたWindows 2003サーバーは、IUSRアカウントの許可などを調整する必要がありますが、少なくともすべての構成操作を再実行する必要はありません。

IIS 6.0の設定データは標準のテキストファイル（XMLファイル）なので、メモ帳などのテキストエディタで開いて編集できます。 IIS 5.0またはIIS 4.0の構成データを変更した場合、IISを再起動しなければならないことがあります（システム上のWebサイトの数が多いと、時間がかかる場合があります）（ISPのサーバーなど）。この問題を解決するために、IIS 6.0は "ランタイム許可編集"機能をサポートします。ランタイム許可編集機能は、次のように有効になります。IISマネージャで、サーバーを右クリックして、[プロパティ]メニューを選択し、[構成データベースの直接編集を許可する]オプションを選択します（図3を参照）。この機能を有効にした後、メモ帳で構成データファイルを開き、仮想ディレクトリ構成を挿入し、構成ファイルを保存して閉じると、構成ファイルの設定に従ってIIS 6.0をほぼ即座に変更できます。再起動する必要はありません。 。

図3

設定ファイルは直接編集することが許可されているので、設定ファイルによるサーバーとアプリケーションの障害は無効です。この目的のために、IIS 6.0は構成ファイルの履歴バージョンディレクトリ、つまり\\ system32 \\ inetsrv \\ historyを提供します。構成データを変更するかIIS 6.0を再起動するたびに、IIS 6.0は元の構成データのコピーをディレクトリに保存します。
第3に、IISマネージャ
主要な製品アップグレードのたびに、人々はユーザーインターフェースからエキサイティングな新機能を見つけようとします。 IIS 6.0マネージャは変更されましたが、その変更は予想外に小さいものでした。

変更点の1つは小さいですが実用的です。 IISマネージャでフォルダを右クリックした場合は、[権限]メニューを選択してそのフォルダの[セキュリティ]ダイアログを開くことができます。このダイアログでは、IISマネージャを終了しなくてもフォルダのNTFS認証を設定できます。これは小さな変更ですが、今年は世界中のすべてのIIS管理者にとって何千時間もの作業時間を節約できるでしょう。

Webサイトを右クリックして[プロパティ]を選択し、[ディレクトリセキュリティ]ページに移動して、[セキュリティ保護された通信]の下にある[編集]ボタンをクリックします。 - [Secure Communications Properties]ページでは、SSL、証明書信頼リスト（CTL）、およびクライアント証明書を設定できます。 IIS 5.0およびIIS 4.0では、証明書がWebサイトにインストールされていないと、このプロパティページにアクセスできません技術的には、CTL証明書とクライアント証明書の設定で証明書をサーバーにインストールする必要がないため、この制限は好ましくありません。言い換えれば、IIS 5.0にインストールした証明書の唯一の用途は、ユーザーインターフェイスが必要としていたことです。 IIS 6.0ではこの余分な要件が修正されているため、プロパティページにアクセスして使用するためにWebサーバーに証明書をインストールする必要はありません。

IV。ワイルドカードアプリケーション

IIS 5.0およびIIS 4.0用のISAPIフィルタに精通している場合は、それらの欠点に精通している可能性があります。 ISAPIフィルタは作成が難しいだけでなく、Inetinfoプロセス内で実行されるため、作成時に誤ってミスをすると、壊滅的な結果を招きやすくなり、間違ったコードによってIIS全体がクラッシュする可能性があります。さらに、ISAPIフィルタは通常のISAPI DLLが持つ機能を持つことができません。もちろん、IIS 5.0およびIIS 4.0では、ISAPIフィルタは非常に便利なコンポーネントであり、WebサーバーまたはWebサイトに対するすべての要求に対して操作を実行できる唯一のコードです。

IIS 6.0は、ISAPIフィルタによって通常提供されるサービスを提供するための新しいより柔軟なメカニズムを提供しますISAPIインターセプタ、またはワイルドカードアプリケーションです。ワイルドカードアプリケーションは、IISマネージャのWebサイトを右クリックし、[プロパティ]メニューを選択して[ホームディレクトリ]ページに移動し、[アプリケーションの設定]の下の[構成]ボタンをクリックすると構成されます。図4に示すように、ダイアログボックス。ダイアログの[マッピング]ページで、1つ以上のISAPI DLLをワイルドカードアプリケーションとして設定できます。受信した要求ごとに、IIS 6.0はここにリストされている各ワイルドカードアプリケーションを呼び出します。すべてのサイトに対してワイルドカードアプリを構成するだけでなく、個々のサイトに対して、またはディレクトリレベルでワイルドカードアプリを構成することもできます。これらのISAPIインターセプターは標準のISAPIアプリケーションであるため、ISAPIフィルターのようにヘッダーにアクセスするのではなく、メッセージの本文にアクセスする機能など、通常のISAPIアプリケーションのすべての機能を備えています。

ワイルドカードアプリケーションは、URLのカスタマイズ、IDの確認、特別なログ情報の記録、攻撃の試みの検出、コンテンツの作成など、開発者が行うことなら何でもできます。ワイルドカードアプリケーションは処理を終了した後、要求を適切な処理エンジン（ASPページを処理するasp.dllなど）に転送します。この処理エンジンは、処理エンジンによってさらに処理されます。さらに、ワイルドカードアプリケーションは、ISAPIアプリケーションの新しいExecuteURL関数を呼び出して、同じアプリケーションプール内の任意のページに要求を渡すこともできます。
新しいISAPIワイルドカードアプリは、クリエイティブなアプリケーションデザインへの扉を開きます。たとえば、IIS 6.0のURL承認機能は、ISAPIワイルドカードアプリケーション（urlauth.dll）として実装されています。 URL承認機能を使用すると、IIS 6.0は、ユーザーがグループのメンバーであるかどうか、地理的な場所、データベースまたはAD内のユーザーに関するその他の情報など、一連の規則に基づいてURLへのアクセスを許可できます。 ISAPIワイルドカードアプリケーションとURL承認の詳細については、IIS 6.0のヘルプドキュメントを参照してください。

V.ログ機能

サーバーのログ機能が主な関心事になることはめったにありませんが、毎日のサーバー管理と監視に不可欠なアシスタントです。 IIS 6.0では、ログ機能が大幅に強化されていますが、残念ながらW3SVCログイベントは依然として現地時間で記録されません。

IIS 6.0では、ログ記録はhttp.sysに変更され、http.sysはカーネルモードで実行されています。この改善により、複数のワーカープロセスが同じログファイルをめぐって競合することを回避しながら、ログの書き込み速度が向上します。特別な場合には、http.sysは、Webサイトのログにログ情報を書き込むことはできないが、書き込むことができないときにエラーに遭遇します。たとえば、ワークプロセスがリサイクルされ、http.sysがユーザー要求を処理できない、またはユーザーサーバーに接続しようとしましたが、要求はIISが必要とする情報の一部しか提供していませんでした。この場合、http.sysはイベントを新しいログファイルhttperr.logに書き込みます。

IIS 6.0のトラブルシューティングと最適化の過程で、httperr.logログファイルは非常に重要です。既定では、httperr.logファイルは\\ system32 \\ logfilesディレクトリに保存されますが、HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Services \\ HTTP \\ Parametersレジストリサブキーを変更し、その下にErrorLoggingDirという名前の文字列を追加することによって変更できます。値は、ErrorLoggingDirに保存ログファイルへのフルパスを設定します。 httperr.logログファイルで見つけることができる情報は下記のものを含んでいます：すべての503（サービス利用不可）エラー、アイドル接続タイムアウト、URLを解析するときのさまざまなエラー、および失敗したアプリケーションプールに送信された最後の10の要求。

IIS 6.0にはバイナリログという機能もあり、この機能を有効にすると、Webサイトのすべてのログ情報がバイナリ形式でログファイルに書き込まれます。同上。バイナリロギング機能を有効にするには、設定ファイルのW3SVCC /CentralBinaryLoggingEnabledエントリをture（1）に設定するだけです。 ISPにとっては、この機能は非常に便利です。 ISPの各マシンには1000以上のWebサイトがある可能性があり、各Webサイトが毎日ログファイルを生成すると、ログファイルの総数はすぐに天文学数に達するでしょう。最近リリースされたMicrosoftのLog Parser 2.0ツールは、バイナリログファイルを読み取り、レポートを生成しますhttp://download.microsoft.com/download/iis5​​0/utility/2.0/nt5xp /en-us /setup.exeでダウンロードできます。 Log Parser 2.0は、前述のhttperr.logファイルも読み取り、レポートを生成します。

昔から、IISはログファイルを保存するローカルサーバー上のディレクトリを指定することを許可していました。ただし、IIS 5.0およびIIS 4.0用のIISマネージャでは、ログファイルのパスを指定するときにリモートサーバーの汎用名前付け規則（UNC）パスを入力できますが、実際にはWebサーバーはログをリモートサーバーに保存しません。ログファイルパスのUNCパス名を実際にサポートするのは、IIS 6.0だけです。