IIS Insider

これを行う方法は多くありますが、どの方法をとるかは様々な詳細によって異なります。例えば、IIS 5 から IIS 5 に移行するのは、IIS 5 から IIS 6 への移行と比較して、いくつかの点で異なるタスクでありますが、共通点も多くあります。

1 つの可能性としては、(移行するサーバーの互いの類似点と使用するライセンスの詳細によって異なります) ソース サーバーのイメージを作成し、対象のサーバーでそのイメージを読み込む方法があります。これは、両方のコンピュータ上のハードウェアが理論上同じものであることを前提とするサーバー間の複雑な IIS のセットアップの移行をする役に立つ方法です。これは、ローカル ユーザーおよびグループが多くある場合、特に役立ちます。

すべてのほかの方法は、より労力を必要とします。FrontPage の Web に関しては、FrontPage クライアントを使用して、サーバーから他のサーバーに Web サイトを公開することを強く推奨します。これにより、非常に多くの機能を使用できるようになりますが、移行作業を行う前に、Web サイトを作成し、そのサイトに FrontPage Server Extensions を追加する必要があります。移行する必要のあるサイトの数によっては、これは、FrontPage の Web を移行するよりよい方法となります。

IIS 5 から IIS 6 に移行する際、コンテンツを移動し、IIS に Web サイトの複製を作成し、IIS 6 Resource Guide の IIS Migration Tool を使用して、まとめて周知のアカウント (ユーザー、すべてのユーザー、認証されたユーザーなど) のアクセス権を移動することができます。また、そのツールにあるスイッチにより、対象のサーバー上の新たな Web サイトに自動的に FrontPage Server Extensions を追加することができます。そのツールは、Microsoft.com/downloads から最新バージョンのツールをダウンロードしてください。(このページの作成時点では、バージョン 1.1 が最新版となっています)

また、Adsonline の IIS Export を検索してください。このシェアウエア ユーティリティは、長い間、IIS の移行タスクで役に立つとの評判を得ています。

おっしゃっているローカルのアクセス権の移行に関しては、少し問題があります。ローカル ユーザーおよびローカル グループのアクセス権は、他のサーバーに直接移行することができません。これには、Web サイトを拡張する際に FrontPage Server Extensions で作成することができる IUSR アカウントおよび ローカル グループのようなユーザーが含まれます。対象のサーバーで新規のユーザーまたはグループを作成し、アクセス権を再度割り当てる必要があります。マイクロソフトは、ローカル ユーザーおよびグループをコンピュータ間で複製するためのユーティリティは提供していませんが、そのようなソフトウェアは、他のベンダから利用可能です。Small Wonders software から、Secure Copy という製品がリリースされており、この作業を行うことができます。おそらく他にも同様の製品があると思われます。

上記の問題だけでなく、証明書、Web アプリケーション、ODBC 接続、COM オブジェクト、またはセキュアなサーバーで使用されているそのほかの技術に関するプランも行う必要があります。それらのタスクは必ずしも単純ではありませんが、綿密な計画によりこれらの問題を管理することができます。

Microsoft Windows Server 2003 Deployment Kit の Deploying IIS 6.0 を参照ください。
(http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx)

IIS 6.0 の httperr.log ファイルは、http.sys の動作およびエラーに関連するイベントを記録します。たとえば、アプリケーション ツールがオフラインの場合、Web サイトはリクエストに応答できないため、入力は http.sys に行われます。そのようなイベントには、無効な http リクエスト、タイムアウトしたクライアントの終了した接続、情報が受け取られるのが遅すぎて他の同様なイベントのログが記録されるために終了した有効な接続などがあります。

httperr ログ ファイルのファイル形式は、以下の通りです。

Web サイト ID (イベントに関連する Web サイトを識別する) が記録されるが、サイトに複数のアプリケーション プールがある場合、リクエストが送られる Web サイトからプールを識別することができません。Windows Server 2003 の製品版のリリースでは、これらのフィールドは設定可能ではありません。

これらの問題に対応するために、マイクロソフトは、httperr ログ ファイルを大幅に変更する http.sys の更新プログラムをリリースしました。その更新プログラムを適用すると、記録されたフィールドで httperr ログ フィールドと W3SVC 標準ログ フィールドの組み合わせた構成をコントロールすることができます。これに、エラーに関連するアプリケーション プールに新たなエントリを追加すると、より多くの情報を含むログ ファイルが得られます。

この変更に関しては、http://support.microsoft.com/default.aspx?scid=kb;ja;832975&sd=tech に説明されています。またこの機能は、Windows Server 2003 Service Pack 1 に含まれる予定です。

まず、IIS 6 がクライアントに戻すデータを確認してみましょう。Microsoft.com へのリクエストをする際、サーバーは、以下のようなデータを戻します。

HTTP/1.1 200 OKCache-Control: publicContent-Length: 13073Content-Type: 
text/htmlExpires: Fri, 08 Oct 2004 18:23:35 GMTLast-Modified: Fri, 08 Oct 2004 15:36:55 
GMTServer: Microsoft-IIS/6.0X-AspNet-Version: 1.1.4322P3P: CP="ALL IND DSP COR ADM CONo CUR 
CUSo IVAo IVDo PSA _PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR 
UNI"X-Powered-By: ASP.NETDate: Fri, 08 Oct 2004 15:56:26 GMT

サーバー バナーと呼ばれる、明らかに IIS 6.0 サーバーを示します。セキュリティ専門家の中には、このバナーを削除して、攻撃者が接続する Web サーバーの種類をわからないようにすることを推奨している人がいます。これは、単純にバナーを取得して、サーバーの攻撃を行う可能性のある「スクリプト キディ」のエンジンの場合、いくつかのメリットがあります。

ご覧のように、サーバーの応答には、X-ASPNet- バージョン番号および X-Powered-by: ASP.NET を含む Microsoft サーバーとして識別する多くのアイテムが含みまれます。

ASP.net がインストールされる際にこれらのタグが追加され、IIS 5 サーバーおよび IIS 6 サーバーで表示されます。また、FrontPage Server Extensions をインストールした場合、Microsoft Office Web サーバーにアクセスしていることを知らせるヘッダが表示されます。

これらのヘッダは、HTTP ヘッダ タブの IIS コンソールで削除することができます。それによって FrontPage に問題が発生するかどうかをテストしていませんが、そのほかには機能への影響はないものと考えられます。

サーバー ヘッダおよびアドオン タグを削除した場合、Asp または ASP.net のページを配信しているという事実によって、IIS サーバーを使用していることが攻撃者によって推測される可能性があります。これは、明らかに非常に細かいことです。その他、同様に簡単に使用しているサーバーの種類を認識するための方法があります。

そのため、サーバー バナーを削除または隠すことは、私はあまりお勧めしませんが、URLScan を使用して、(IIS 5 および IIS 6 の両方に対して) URLScan.ini ファイルの RemoveServerHeader 設定のバナーを削除することもできます。