IIS 8.0 Application Initialization

作成者: Shaun Eagan

互換性

バージョン	メモ
IIS 8.0	IIS 8.0 では Application Initialization が組み込まれています。
IIS 7.5	Application Initialization は IIS 7.5 では帯域外モジュールとしてリリースされました。
IIS 7.0	IIS 7.0 では Application Initialization がサポートされていません。

問題

Web サイト管理者が直面する一般的な問題は、Web アプリケーションの初期化タスクと "ウォーミングアップ" タスクを実行する必要があるという点です。 より大規模で複雑な Web アプリケーションでは、最初の HTTP 要求を処理する前に、長いスタートアップ処理、メモリ内のプライム キャッシュ、コンテンツの生成などが必要になる場合があります。

解決策

IIS 8.0 の Application Initialization 機能を使用すると、Web サイト管理者は、1 つまたは複数の Web アプリケーションの初期化タスクを IIS 8.0 が前もって実行するように構成できます。 アプリケーションの初期化中に、アプリケーション初期化タスクが完了するまで、IIS 8.0 が静的コンテンツをプレースホルダーまたは "スプラッシュ ページ" として返すように構成することもできます。

Application Initialization 機能は、Web アプリケーションを初期化する方法とタイミングを IIS 8.0 に指示するグローバル ルールとアプリケーション固有のルールの組み合わせによって構成されます。 また、Application Initialization 機能では、IIS URL 書き換えモジュールとの統合もサポートされており、アプリケーションの初期化中におけるプレースホルダー コンテンツのより複雑な処理がサポートされています。

Note

Application Initialization と アプリケーション要求ルーティング処理 (ARR) の間には、既知の非互換性があります。 ARR がインストールされているマシンで Application Initialization を使用することはお勧めしません。

ステップ バイ ステップの手順

前提条件

Application Initialization 機能では、IIS 8.0 をインストールする必要があります。 さらに、IIS の "アプリケーション開発" サブ機能内の Application Initialization 機能をインストールする必要があります。

Windows Server 2012 サーバー マネージャー UI の次のスクリーンショットは、Application Initialization 機能を示しています。

Note

このチュートリアルでは、Application Initialization 機能のデモンストレーションを行うために、ASP.NET 4.5 アプリケーションも使用します。 このドキュメントの最後の付録には、サンプル アプリケーションと、マシンでアプリケーションを設定する手順が含まれています。

既知のバグの回避策

• 現時点では、この機能に関する既知のバグはありません。

グローバルのアプリケーションの初期化

Application Initialization 機能は、マシン全体の applicationHost.config ファイルと、アプリケーションレベルの web.config ファイルの 2 つの場所で構成できます。 applicationHost.config ファイルの構成には "グローバル" のアプリケーションの初期化設定が含まれます。アプリケーションレベルの web.config ファイルには、"ローカル" のアプリケーションの初期化設定が含まれます。

このチュートリアルでは、アプリケーションに関連付けられているアプリケーション プールの起動時に常に初期化されるようにサンプル アプリケーションを構成します。 アプリケーション プールの動作は applicationHost.config でのみ構成できるため、アプリケーションが起動するたびにアプリケーションの初期化を実行することは、"グローバル" のアプリケーションの初期化設定の一部とみなされます。

applicationHost.config での変更

%WINDIR%\system32\inetsrv\config にある applicationHost.config ファイルをメモ帳で開きます。 (テキスト エディターは必ず [管理者として実行] オプションを使用して実行してください。)

<applicationPools> 構成セクションを見つけ、".NET v4.5" という名前のアプリケーション プール エントリを探します。

アプリケーション プールが常に実行されるように、アプリケーション プール エントリを変更します。 グローバルのアプリケーションの初期化を実行するアプリケーションの場合、通常は、関連付けられているアプリケーション プールを開始して実行する必要があります。 次の構成スニペットの太字の属性は、構成エントリに追加する内容を示しています。

<add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />

applicationHost.config でもう少し下にスクロールし、<sites> 構成要素に移動します。 このセクション内には、サンプル アプリケーションの <application> エントリがあります (マシンでサンプル アプリケーションを作成する手順については、付録をご覧ください)。 アプリケーションは "appinit" という名前で、パス属性値は "/appinit" です。 構成スニペットに示すように太字の preloadEnabled 属性を追加して <application> エントリを変更し、変更を保存します。

<application path="/appinit" preloadEnabled="true" applicationPool=".NET v4.5">

preloadEnabled を "true" に設定すると、関連付けられているアプリケーション プールの起動時に "偽" の要求がアプリケーションに送信されることが IIS 8.0 に知らされます。 前の手順でアプリケーション プールの startMode を "AlwaysRunning" に設定したのは、そのためです。

アプリケーション プールが常に実行されている状態と、アプリケーション自体が偽の要求を常に受信するようにマークされた状態が組み合わせられると、マシンが起動するたびに、または World Wide Web サービスがリサイクルされるたびに、IIS 8.0 はアプリケーションの起動をトリガーするために、アプリケーション プール インスタンスが実行されており、アプリケーションの "/appinit" に常に偽の要求が送信されることを確認します。

アプリケーションの web.config での変更

メモ帳の 2 つ目のインスタンスを使用して、次の場所にあるアプリケーション レベルの web.config ファイルを開きます。 (テキスト エディターは必ず [管理者として実行] オプションを使用して実行してください。)

C:\inetpub\wwwroot\appinit

注: 既定の Web サイトが別の物理ドライブにインストールされている場合は、ドライブ文字を変更します。

web.config ファイルには、既に事前に設定されているが、コメントアウトされている構成セクションがいくつかあります。表示されている構成スニペットのコメントを解除します。これは、<system.webServer> 構成セクション内にあります。 このスニペットは、web.config ファイルのコメント "演習 1 - 手順 1" のすぐ下にあります。 次に、変更を保存します。

<applicationInitialization
    remapManagedRequestsTo="Startup.htm" 
    skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

applicationInitialization 要素は、アプリケーションを初期化するには、アプリケーションのルート URL (この例では "/default.aspx") に要求を発行する必要があることを IIS に指示します。 IIS は "/default.aspx" への要求が完了するまで待機する間、アクティブなブラウザ クライアントに "Startup.htm" を提供します。 "Startup.htm" は、アプリケーションの "スプラッシュ ページ" です。

アプリケーションの実行

管理者特権でのコマンド プロンプト ウィンドウで、次に示すコマンドを使用して World Wide Web サービスをリサイクルします。

net stop w3svc & net start w3svc

コマンド プロンプト ウィンドウは必ず [管理者として実行] オプションを使用して実行してください。

Internet Explorer を使用して、次の URL に移動します。

http://localhost/appinit/default.aspx

ブラウザーは、最初の数秒間、灰色の背景の静的な "Startup.htm" ページを返します。これは、このページが web.config で構成されている "スプラッシュ ページ" であるためです。Web ブラウザーでページの更新を続けると、約 8 秒後に (サンプル アプリケーションの global.asax でスレッド スリープでシミュレートされた) 白い背景の default.aspx の "実際の" コンテンツを受け取ることを確認できます。 これは、アプリケーションの初期化が完了したことを示しています。

重複するプロセスのリサイクルの構成

IIS 8.0 では、バックグラウンドで重複するプロセスでアプリケーションの初期化を実行することで、グローバルのアプリケーションの初期化と重複するプロセスのリサイクルが統合されます。 アクティブなワーカー プロセスがリサイクルされていることを IIS が検出すると、新しいワーカー プロセスが新しいプロセス内のすべてのアプリケーション初期化 URL の実行を完了するまで、IIS はアクティブなトラフィックを新しいリサイクルされたワーカー プロセスに切り替えません。 これにより、アプリケーションがライブで実行された後に、Web サイトを閲覧しているユーザーにアプリケーションの初期化ページが表示されないようにします。

applicationHost.config を表示しているメモ帳のインスタンスに戻ります。次に示す構成スニペットのようになるように ".NET v4.5" のアプリケーション プール エントリを変更します。

<add name=".NET v4.5"
                startMode="AlwaysRunning"
    managedRuntimeVersion="v4.0" >
  <recycling logEventOnRecycle="Schedule">
    <periodicRestart requests="30" />
  </recycling>
</add>

変更は必ず保存してください。

<recycling> 要素は、HTTP 要求 30 件ごとにワーカー プロセスをリサイクルするように IIS に指示します。

アプリケーションをもう一度実行する

管理者特権でのコマンド プロンプト ウィンドウで、次に示すコマンドを使用して World Wide Web サービスをリサイクルします。

net stop w3svc & net start w3svc

Internet Explorer の新しいインスタンスを使用して、もう一度次の場所に移動します。

http://localhost/appinit/default.aspx

灰色の背景の "Startup.htm" スプラッシュ ページが表示されていることにご注意ください。

次に、タスク マネージャーを起動し、[プロセス] タブを表示します。 プロセス リストを名前で並べ替えると、w3wp.exe の 1 つのインスタンスが実行中であることがわかります。 このインスタンスは、"appinit" ASP.NET アプリケーションを現在実行しているワーカー プロセスです。

実際の default.aspx ページのコンテンツが返されるまで、ブラウザーを数回更新します。 背景が白に変わると、アプリケーションで "実際の" default.aspx ページが実行されていることがわかります。 次に、タスク マネージャーとブラウザーの両方を表示できるように、画面にウィンドウを配置します。

次に、ブラウザーに戻り、ページを少なくとも 30 回更新すると、IIS によってアプリケーション プールがリサイクルされます。 次に示すように、w3wp.exe の 2 つ目のインスタンスがタスク マネージャープロセスの一覧に表示されたら、ページの更新を止めることができます。

このスクリーンショットは、前に設定したプロセス リサイクル制限のために開始された w3wp.exe の 2 番目のインスタンスを示しています。

次の 10 秒間ほど、ブラウザー ウィンドウを定期的に更新し続けることができます。 default.aspx は引き続き実行されることにご注意ください。 重複するリサイクルが完了すると、1 つの w3wp.exe インスタンスが [タスク マネージャー プロセス] ウィンドウに表示されなくなります。

重複するリサイクルの実行中は、アプリケーションの初期化がアプリケーション用に構成され、w3wp.exe の新しいインスタンスでバックグラウンドで初期化 URL を実行していた場合でも、"実際の" default.aspx の内容が引き続き表示されます。

URL 書き換えとアプリケーションの初期化

既定では、アプリケーションの初期化では、アプリケーションの初期化中に表示する 1 つの "スプラッシュ ページ" URL のみを指定できます。 ただし、Application Initialization 機能では、アプリケーションの初期化中に要求処理を制御するために使用できるいくつかのサーバー変数がサポートされています。 これにより、事前に生成された静的コンテンツへのより複雑なマッピングを含む URL 書き換えモジュールを使用して宣言型ルールを作成できます。

このチュートリアルでは、remapManagedRequestsTo 属性を、同じ最終結果を実現する URL 書き換えルールのセットに置き換えます。

注: URL 書き換えのインストール手順については、付録をご覧ください。

applicationHost.config での変更

applicationHost.config を開いているメモ帳のインスタンスを使用して、アプリケーション プールとアプリケーション要素の両方を元に戻して、すべてのグローバルのアプリケーションの初期化処理をオフにします。 このチュートリアルの残りの部分では、構成されている Application Initialization の動作に重点を置いているため、この手順ではグローバル設定が削除されます。

アプリケーション プールとアプリケーションの applicationHost.config エントリは次のとおりです。

アプリケーション プールの構成エントリ:

<add name=".NET v4.5" managedRuntimeVersion="v4.0" />

アプリケーションの構成エントリ:

<application path="/appinit" applicationPool=".NET v4.5">

完了したら、変更を必ず保存してください。

また、変更が IIS で確実に有効になるようにするには、管理者特権でのコマンド プロンプト ウィンドウから、次に示すコマンドを使用して World Wide Web サービスをリサイクルします。

net stop w3svc & net start w3svc

アプリケーション レベルの web.config への変更

アプリケーションレベルの web.config を開いているメモ帳のインスタンスを使用して、<applicationInitialization> 要素から remapManagedRequestsTo 属性を削除します。 <applicationInitialization> 構成セクションは次の構成スニペットのようになります。

<applicationInitialization skipManagedModules="true" >
  <add initializationPage="/default.aspx" />
</applicationInitialization>

<applicationInitialization> 要素は、要求を再マップする URL を定義しなくなったため、URL 書き換えルールのセットを追加します。 次に、"default.aspx" に対して行われた要求を明示的にマップする書き換えルールと、"Startup.htm" にルーティングするための "/" を追加します。 ルールが 2 つ必要なのは、URL 書き換えモジュールで既定のドキュメントのしくみが認識されないためです。 "/" は ASP.NET アプリケーションの "default.aspx" に相当するため、2 つの URL 書き換えルール (URL のバリエーションごとに 1 つのルール) が必要です。

これらの新しいルールが下に太字で示されています。 または、web.config ファイルの "演習 2 - 手順 2 要求をホーム ページにマッピングする" コメントで、事前設定された URL 書き換えルールのコメントを解除することもできます。

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
  </rules>
</rewrite>

これらのルールで注意すべき項目がいくつかあります。まず、stopProcessing 属性は <rule /> 要素で "true" に設定されています。 これは、後でキャッチオール URL 書き換えルールを追加するため、およびキャッチオール ルールを実行したくない default.aspx または "/" への要求のために必要です。

次に、<conditions /> 要素に URL 書き換え条件があることに注目してください。 この条件は、実質的に "アプリケーションが初期化状態にある場合にのみルールを適用する" ことを示しています。 サーバー変数 "APP_WARMING_UP" は、アプリケーションの初期化がアクティブであり、IIS がまだすべての初期化 URL を処理している場合に、IIS によって値が "1" に設定されます。

最後に、アクションが、アクティブな要求を書き換え、代わりに "Startup.htm" を実行するように定義されていることに注目してください。 このルールは、静的ファイル ハンドラーに要求を渡すよう IIS に指示し、静的ページ Startup.htm をレンダリングする効果があります。

次に、キャッチオール書き換えルールを追加します。 URL 書き換えモジュールをアプリケーションの初期化と組み合わせて使用する場合、前のルールにどれも一致しない場合に発生するキャッチオール ルールが必要です。 以下に示す太字のルールを、キャッチオール ルールとして書き換えセクションに追加します。 または、web.config で事前設定されたキャッチオール ルールのコメントを解除することもできます。これは、web.config ファイルの "演習 2 - 手順 2: キャッチオール ルールを設定する" コメントの下にあります。

<rewrite> 
  <rules>
    <rule name="Home Page-Expanded" stopProcessing="true">
      <match url="default.aspx" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="Home Page-Short" stopProcessing="true">
      <match url="^$" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <action type="Rewrite" url="Startup.htm" />
    </rule>
    <rule name="All Other Requests">
      <match url=".*" />
      <conditions>
        <add input="{APP_WARMING_UP}" pattern="1" />
      </conditions>
      <serverVariables>
        <set name="SKIP_MANAGED_MODULES" value="0" />
      </serverVariables>
      <action type="Rewrite" url="{URL}" />
    </rule>
  </rules>
</rewrite>

完了したら、変更を保存します。

新しいルールは、それに到達する URL と照合し、受信 URL に対して行われた要求の処理を続行するように IIS に指示します。 また、このルールでは、"SKIP_MANAGED_MODULES" というサーバー変数の値が "0" に設定されます。これは "false" に相当します。 この設定は、URL 書き換えからの書き換えられた要求を、要求が通常はネットワークから到着した場合と同じ方法で処理する必要があることを IIS に指示します。

アプリケーションの実行

管理者特権でのコマンド プロンプト ウィンドウで、次に示すコマンドを使用して World Wide Web サービスをリサイクルします。

net stop w3svc & net start w3svc

Internet Explorer の新しいインスタンスを使用して、もう一度次の場所に移動します。

http://localhost/appinit/default.aspx

URL 書き換えルールを使用してスプラッシュ ページ ロジックを定義するようになりましたが、最初のチュートリアルと同じ動作が表示されます。 最初は、灰色の背景の Startup.htm ページが表示されます。 ブラウザーを定期的に更新すると、約 8 秒後に再びページの背景が白に切り替わります。これは、アプリケーションの初期化が完了したことを示す "実際の" default.aspx ページが提供されていることを示します。

複雑なスプラッシュ ページ ルール

前のチュートリアルでは、URL "X" から URL "Y" への直接マッピングとして、アプリケーションの初期化を使用しました。 このチュートリアルでは、より複雑なアプリケーションの初期化シナリオを実装します。

ブラウザーで、次の URL の両方に移動します。

• http://localhost/appinit/ImageHandler.ashx?image=Lighthouse
• http://localhost/appinit/ImageHandler.ashx?image=Tulips

これらの URL は、動的に生成された静的コンテンツの例です。 このサンプル アプリケーションの場合、ImageHandler.ashx 内のコードは、クエリ文字列キー "image" を確認します。 そのクエリ文字列の値が "Lighthouse" または "Tulips" である場合、ASP.NET ハンドラーは、App_Data フォルダーにある対応する JPG を送信します。

イメージ ハンドラーはイメージを返すだけなので、アプリケーションの初期化中でも適切なイメージを返し続けることができるようにする必要があります。 これらのイメージを提供するしくみではマネージド コードを使用しますが、基になる ASP.NET アプリケーションの起動と初期化に時間がかかっている場合でも、事前に生成されたイメージを顧客に迅速に提供する必要がある場合があります。

アプリケーション レベルの web.config への変更

アプリケーションレベルの web.config を開いているメモ帳のインスタンスを使用して、最後のキャッチオール ルールの前に別の URL 書き換えルールを追加します。 追加する新しいスニペットを次に示します。 または、web.config で事前設定されたイメージ ハンドラー ルールのコメントを解除することもできます。これは、web.config ファイルの "演習 3 - 手順 1: 複雑なスプラッシュ ページ ルール" コメントの下にあります。

<rule name="Image Handler Remapping" stopProcessing="true">
  <match url="ImageHandler.ashx" />
  <conditions>
    <add input="{APP_WARMING_UP}" pattern="1" /> 
    <add input="{QUERY_STRING}" pattern="image=([A-Za-z]+)&amp;?" /> 
  </conditions>
  <action type="Rewrite" url="Images/{C:1}_static.jpg" appendQueryString="false" />
</rule>

完了したら、変更を保存します。

default.aspx と "/" の書き換えルールと同様に、このルールでは stopProcessing 属性が "true" に設定されているため、ImageHandler.ashx への要求がアプリケーションの初期化中に最終的なキャッチオール書き換えルールに誤ってフォールスルーされることがありません。

"ImageHandler.ashx" への要求の場合、書き換えルールは正規表現キャプチャ グループを使用して、クエリ文字列から要求されたイメージを抽出します。 一致パターン定義 pattern="image=([A-Za-z]+)&?" は、"image" クエリ文字列変数の値を抽出するように IIS に指示します。 その後、この値はアクション属性の URL 属性で使用されます (url="Images/{C:1}_static.jpg")。

action 要素の URL 属性は、アプリケーションの Images サブディレクトリ内のファイルをポイントするように ImageHandler.ashx 要求を書き換えるように URL 書き換えモジュールに指示します。 さらに、正規表現によってキャプチャされたクエリ文字列値は、最終的に Images サブディレクトリから提供されるファイルの名前を形成するのに役立ちます。 たとえば、ImageHandler.ashx?image=Tulips への要求は Images/Tulips_static.jpg に書き換えられます。

Windows エクスプローラーを使用して inetpub\wwwroot\appinit ディレクトリを参照し、Images サブディレクトリを見ると、2 つのファイルがあります。1 つは "静的" バージョンの Tulips.jpg を表し、もう 1 つは "静的" バージョンの Lighthouse.jpg を表します。 これらの静的イメージは、アプリケーションの初期化中に提供できる事前に生成されたコンテンツとして機能します。

アプリケーションの実行

管理者特権でのコマンド プロンプト ウィンドウで、次に示すコマンドを使用して World Wide Web サービスをリサイクルします。

net stop w3svc & net start w3svc

Internet Explorer を使用して、次のいずれかに移動します。

http://localhost/appinit/ImageHandler.ashx?image=Lighthouse

または

http://localhost/appinit/ImageHandler.ashx?image=Tulips

どちらの場合も、返されるイメージに、事前に生成された "静的" バージョンのイメージであることを示す透かしが含まれていることがわかります。 透かしとは、画像の上部にある "この画像は静的バージョン..." というテキストのことです。

約 10 秒後にブラウザーを更新すると、返された画像コンテンツが ImageHandler.ashx ハンドラーによって提供される "実際の" コンテンツに変わることがわかります。 透かしが削除されます。これは、アプリケーションの初期化が完了したため、ASP.NET ハンドラーによってコンテンツが動的に生成されたことを示しています。

[注: Internet Explorer が更新されていないと思われる場合は、アドレス バーの [破損したドキュメント] アイコンまたは更新アイコンをクリックして、Internet Explorer にページの再読み込みを強制します。]

まとめ

IIS 8.0 の Application Initialization 機能を使用すると、開発者と管理者は、IIS が "コールド" アプリケーションを初期化している間に、ブラウザーに静的コンテンツを返すことができます。 ブラウザーに静的コンテンツをすぐに提供すると、ユーザー エクスペリエンスが向上します。 ブラウザー ページが空白になったり、待機アイコンが回転したりするコールドスタート アプリケーションの代わりに、Application Initialization 機能を使用して、関連する静的コンテンツを提供しながら、基になるアプリケーションが負荷の高い初期化処理を完了できます。

初期化プロセスは、Web サーバーがオンラインまたはリサイクルされるたびに自動的に行われます。 サーバー管理者がアプリケーションを完全に初期化したくないシナリオでは、最初の要求が "コールド" アプリケーションに到着したときに、初期化プロセスをオンデマンドでトリガーできます。

グローバルのアプリケーションとローカルのアプリケーションの初期化のどちらの場合も、URL 書き換えモジュールを統合して、より豊富でより複雑な初期化規則を提供できます。 Application Initialization 機能と統合された URL 書き換えルールを使用すると、IIS がバックグラウンドでアプリケーションを起動し続けている間、さまざまな URL と仮想パスに対して、さまざまな種類の事前生成済み静的コンテンツを提供できます。

付録 - サンプル ASP.NET アプリケーションの設定

注 - 次の手順は、サーバーに IIS 8.0 のインストールと、IIS 8.0 での ASP.NET 4.5 の有効化の両方が既に行われていることを前提としています。

サンプル アプリケーションを展開する

サンプル ASP.NET アプリケーションは、次の .zip ファイルに含まれています。

ファイルを Web サーバー上の wwwroot フォルダーに解凍します。 たとえば、Web サーバーが C:\ ドライブに "既定の Web サイト" をインストールした場合は、ファイルのコンテンツを c:\inetpub\wwwroot\appinit に解凍します。

IIS 8.0 でアプリケーションを作成する

"appinit" サンプルをファイル システムに解凍したら、IIS 8.0 でフォルダーを ASP.NET アプリケーションとして構成する必要があります。 次のスクリーンショットは、IIS 8.0 でアプリケーションとして構成された appinit サンプル アプリケーションを示しています。 また、アプリケーションが ".NET v4.5" アプリケーション プールに割り当てられていることにもご注意ください。

URL 書き換えモジュールをインストールする

サンプル アプリケーションでは、URL 書き換えモジュールを使用して、Application Initialization 機能との高度な統合を行います。 URL 書き換えモジュールをサーバーにインストールする必要があります。これは https://www.iis.net/downloads/microsoft/url-rewrite からダウンロードできます。

URL 書き換えモジュールを構成する

URL 書き換えモジュールを Web サーバーにインストールしたら、IIS applicationHost.config ファイルを変更して、Application Initialization 機能でサポートされている SKIP_MANAGED_MODULES サーバー変数を使用できるようにする必要があります。

メモ帳などのテキスト エディターで、コンピューター全体の applicationHost.config ファイルを開きます。 たとえば、オペレーティング システムを C:\ ドライブにインストールした場合、applicationHost.config ファイルは C:\Windows\System32\inetsrv\config にあります。

ファイルを下にスクロールし、セキュリティ セクションを見つけます。 このセクションは、XML 要素 <security> で始まります。

<security> 要素の前に、次の XML 要素を入力します。

<rewrite>
  <allowedServerVariables>
    <add name="SKIP_MANAGED_MODULES" />
  </allowedServerVariables>
</rewrite>

applicationHost.config ファイルへの変更を保存します。