IIS 8 を新しく構築したあと、Classic ASP（VBScript）のページだけが「HTTP Error 500.24」で真っ白になり、原因が分からず悩むケースは少なくありません。この記事では、エラー 500.24 が発生する典型的な原因と、その中でももっとも安全で現場で再現性の高い解決方法を、画面操作とコマンドの両方から詳しく解説します。運用中のサーバーでの注意点やトラブルシュートのコツもあわせてまとめます。
HTTP Error 500.24 とは何か？まずはエラーの正体を押さえる
Classic ASP ページを開いたときに、ブラウザに次のような画面が表示されることがあります。
HTTP Error 500.24 - Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
英語のメッセージですが、要点は以下のとおりです。
- 「ASP.NET の設定が、統合パイプライン モードでは使えない」と IIS に怒られている
- エラーコードは 500.24（内部サーバーエラーの一種）
- Classic ASP の問題に見えて、じつは アプリケーション プールのパイプライン モードと web.config の組み合わせの問題
HTTP 500 番台のエラーは「サーバー側の設定・アプリケーションに問題がある」ことを意味します。その中でも 500.24 は、【アプリケーション プールが統合パイプライン（Integrated）なのに、Classic モード専用の設定が web.config に書かれている】というパターンで発生します。
代表的な「統合パイプラインでは使えない、あるいは注意が必要な設定」として、次のようなものがあります。
<identity impersonate="true" /><authentication mode="Windows" />の組み合わせによる高度な偽装設定- 古い ASP.NET 用のモジュール設定（Classic モード前提）
これらが web.config に記述されている状態で、アプリケーション プールが「統合パイプライン」のままだと、IIS が構成を検証した段階で 500.24 を返します。その結果、Classic ASP（VBScript）のページも巻き添えで動かなくなってしまいます。
500.24 が示していることを整理
| 項目 | 内容 |
|---|---|
| HTTP ステータス | 500.24（内部サーバーエラー） |
| 主な原因 | 統合パイプライン モードで使えない構成要素が web.config に含まれている |
| 影響範囲 | 該当サイト／アプリケーション配下のすべてのリクエスト（Classic ASP も含む） |
| 真の問題の所在 | アプリケーション プールのパイプライン モードと web.config の不整合 |
ここまで整理すると、Classic ASP のコードや VBScript 自体が悪いわけではなく、IIS の構成の問題だということが見えてきます。
なぜ Classic ASP なのに ASP.NET のエラーが出るのか
「ASP.NET の設定が……」と言われると、ASP.NET アプリケーションを動かしていないのに、おかしいと感じるかもしれません。しかし IIS 7 以降（IIS 8 を含む）は設計が大きく変わり、統合パイプライン（Integrated）モードでは ASP.NET と IIS が密接に統合されています。
そのため、Classic ASP のリクエストであっても、サイトに置かれた web.config の ASP.NET 向け設定が、アプリケーション全体の構成として検証されます。そして統合パイプラインでは不正な設定が含まれていると、IIS はリクエスト処理を開始する前に 500.24 を返します。
逆に Classic モード（クラシック パイプライン モード）のアプリケーション プールでは、旧来の IIS 6 に近い動作となり、この種の検証が厳密には行われません。そのため、Classic ASP を中心としたレガシー環境との相性が良く、500.24 の回避にもつながります。
統合パイプラインとクラシック パイプラインの違い
| 項目 | 統合パイプライン（Integrated） | クラシック（Classic） |
|---|---|---|
| 主な用途 | ASP.NET を中心とした新規アプリケーション | レガシーな Classic ASP / ISAPI 等 |
| パイプライン構造 | IIS と ASP.NET が完全統合 | IIS と ASP.NET が分離（旧 IIS 6 互換） |
| 構成検証 | web.config の ASP.NET 設定も厳密に検証 | 一部の設定は検証対象外で動作 |
| Classic ASP との相性 | web.config 次第で 500.24 が発生しやすい | Classic ASP に適した互換モード |
結論として、Classic ASP を主軸としたサイトを IIS 8 に載せる場合は、アプリケーション プールを Classic モードにするほうが安全です。これがこの記事で紹介する、もっとも確実な解決策です。
もっとも安全な解決策：アプリケーション プールを Classic モードに変更する
HTTP Error 500.24 が出て Classic ASP ページが動かない場合の、基本かつ推奨される対応は次のとおりです。
- 問題が発生しているサイトがどのアプリケーション プールを使用しているか確認する
- そのアプリケーション プールのパイプライン モードを Classic に変更する
- IIS を再起動し、動作確認用の最小 ASP ページで検証する
使用中のアプリケーション プールを確認する手順
まずは対象サイトがどのアプリケーション プールで動いているかを把握します。
- IIS マネージャー（inetmgr） を起動します。
- 左ペインでサーバー名を展開し、「サイト」 をクリックします。
- 中央ペインで該当サイトを選択し、右の 「操作」→「基本設定…」 をクリックします。
- 表示されたダイアログ内の 「アプリケーション プール」 に、現在割り当てられているプール名が表示されます（例：
DefaultAppPool）。
このプール名を控えておき、その設定を変更していきます。
アプリケーション プールのパイプラインモードを Classic に変更する（GUI）
- IIS マネージャー左ペインで 「アプリケーション プール」 をクリックします。
- 中央ペインの一覧から、先ほど確認したプール（例：
DefaultAppPool）を選択します。 - 右ペインの 「操作」→「基本設定…」 をクリックします。
- 「マネージド パイプライン モード」 のドロップダウンから、「Classic」 を選択します。
- 「OK」 をクリックしてダイアログを閉じます。
設定を反映するため、IIS 全体を再起動しておくと確実です（他サイトへの影響が問題になる場合は、該当アプリケーション プールのみの再起動でも構いません）。
iisreset
注意： iisreset はサーバー上のすべてのサイト・アプリケーションに影響するため、本番環境ではメンテナンス時間帯に実施してください。単一プールのみ再起動する場合は、IIS マネージャーのアプリケーション プール画面で対象プールを右クリックし、「再起動」 を選択します。
コマンドで一気に設定する方法（AppCmd）
サーバーの構成管理をスクリプト化したい場合や、複数台への展開を自動化したい場合は AppCmd.exe を使うのが便利です。管理者権限のコマンド プロンプトで次のように実行します。
%windir%\system32\inetsrv\appcmd set apppool "DefaultAppPool" /managedPipelineMode:Classic
"DefaultAppPool" の部分は、実際に使用しているプール名に置き換えてください。エラーなく完了すれば、対象アプリケーション プールのパイプライン モードが Classic に切り替わります。
Classic ASP ページの動作確認
設定変更後は、まずは極力シンプルな ASP ページで動作確認を行います。
- アプリケーションのルート フォルダーに
test.aspを作成します。 - 内容を次のようにします。
<% Response.Write("ASP OK: " & Now()) %>
ブラウザから http://サーバー名/仮想ディレクトリ名/test.asp にアクセスし、現在日時が表示されれば、Classic ASP 自体は正常に動作しています。
代替策：検証を抑止して統合パイプラインのまま動かす（推奨度低）
何らかの事情でアプリケーション プールを統合パイプライン（Integrated）から変更できない場合、一時的な回避策として、IIS に対する構成検証を抑止する方法があります。
具体的には、サイトルートの web.config に次のような設定を追加します。
<configuration>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
</configuration>
この設定を入れると、統合パイプライン モードでも、Classic モード専用の設定を含む構成を受け入れるようになります。その結果として 500.24 は出なくなりますが、以下の点から根本解決とは言えません。
- 構成の妥当性チェックを抑止するため、将来的なトラブルを見逃す可能性がある
- ASP.NET アプリケーションと Classic ASP が同居している場合、意図しない副作用が出るリスクがある
- サーバー全体の運用方針として、あまり推奨されない構成となる
そのため、本番運用では「アプリケーション プールを Classic に切り替える」のが第一候補であり、この validateIntegratedModeConfiguration="false" は「どうしても Integrated のままにしないといけない」状況での最後の手段と考えるのが無難です。
Classic ASP が動作するための前提条件をチェックする
HTTP Error 500.24 を解消したつもりでも、そもそも Classic ASP 機能がインストールされていない・ハンドラが有効になっていない、というケースもよくあります。ここでは、Classic ASP を IIS 8 で動かすうえでの前提条件を整理しておきます。
Classic ASP 機能がインストールされているか確認
- サーバー マネージャー を開きます。
- 左ペインで 「役割と機能」 を選択し、「役割と機能の追加」 を実行します。
- ウィザードで 「役割ベースまたは機能ベースのインストール」 を選択し、対象サーバーを指定します。
- 「サーバーの役割」→「Web サーバー（IIS）」→「Web サーバー」→「アプリケーション開発」 を展開します。
- 一覧の中にある 「ASP」 にチェックが入っているか確認し、入っていなければチェックを付けてインストールします。
インストール後は、IIS を再起動しておきましょう。
ハンドラ マッピングで「*.asp – Active Server Pages」が許可されているか
- IIS マネージャーで対象サイトを選択します。
- 中央ペインで 「ハンドラ マッピング」 をダブルクリックします。
- 一覧の中から 「*.asp – Active Server Pages」 を探します。
- 状態が「許可」になっているか確認します。もし「禁止」になっている場合は右ペインから 「許可」 を選択します。
ハンドラ マッピングが無効のままだと、500.24 を解消できても ASP ページが単なるダウンロード扱いになったり、別のエラーコードが表示されたりします。Classic ASP の基本設定として必ず確認しておきましょう。
前提条件チェックのまとめ
| チェック項目 | 確認すべき状態 |
|---|---|
| Classic ASP 機能 | サーバー マネージャーの「ASP」役割がインストール済み |
| ハンドラ マッピング | 「*.asp – Active Server Pages」が「許可」になっている |
| アプリケーション プール | Classic モードで動作している（もしくは最終手段として validation 抑止） |
web.config の見直しポイント：<identity impersonate=”true” /> は本当に必要？
HTTP Error 500.24 のきっかけになりやすい設定の代表例が、次の一行です。
<identity impersonate="true" />
これは古い ASP.NET アプリケーションなどで使われていた、要求元ユーザーを偽装して処理を行うための設定です。しかし、以下の理由から、現在では安易な使用は推奨されません。
- 統合パイプライン モードとの相性が悪く、500.24 の原因になりやすい
- 最小権限の原則に反し、意図せぬ権限でファイル・DB へアクセスしてしまう可能性がある
- トラブルシュートや監査の観点からも、挙動が複雑になりやすい
Classic ASP のみを扱うサイトであれば、この設定を削除してしまって問題ないケースがほとんどです。もしどうしても偽装が必要な場合は、「最小権限の専用アカウント」を用意して、そのアカウントでアプリケーション プールを実行する、といった手法に置き換えることを検討しましょう。
不要な設定を削ったシンプルな web.config の例
Classic ASP だけのサイトであれば、web.config は極力シンプルにするほうがトラブルが少なくなります。例として、次のような構成が考えられます。
<configuration>
<system.web>
<!-- Classic ASP だけなら、identity impersonate や複雑な authentication は不要 -->
<customErrors mode="Off" />
</system.web>
<system.webServer>
<!-- 必要に応じてログや詳細エラー設定を追加 -->
</system.webServer>
</configuration>
もし既存の ASP.NET アプリケーションと共存しており、web.config の整理が難しい場合は、Classic ASP 用の専用アプリケーション（あるいは専用サイト）を切り出し、アプリケーション プール・ルートフォルダー・web.config を分離するのも有効な戦略です。
開発環境のみ詳細エラーを表示して原因を特定する
原因調査のためには、ブラウザに詳細なエラーメッセージが表示されると非常に便利です。IIS 8 では、Classic ASP の設定から詳細エラーを制御できます。
Classic ASP のエラー送信設定を変更する手順
- IIS マネージャーで該当サイトを選択します。
- 中央ペインから 「ASP」 をダブルクリックします。
- プロパティグリッドの中から 「デバッグのプロパティ」 → 「エラーの送信先」 を探します。
- 値を 「詳細エラーをクライアントに送信」 に変更します。
これにより、Classic ASP 内で発生したエラー内容が、ブラウザに直接表示されるようになります。ただし、本番環境で詳細エラーをそのままクライアントに返すのはセキュリティ上好ましくありません。
| 環境 | エラー表示の推奨設定 |
|---|---|
| 開発環境 | 詳細エラーをクライアントに送信 |
| テスト環境 | 必要に応じて限定的に詳細エラー表示 |
| 本番環境 | ユーザー向けにはカスタムエラーページ、詳細はログのみ |
500.24 の場合は、IIS 側の構成エラーなので、ASP のエラー設定だけでは見えないこともあります。その場合はイベント ビューアー（Windows ログ → アプリケーション）もあわせて確認すると手掛かりが得られます。
Classic ASP の最小テストページで切り分ける
設定を変更したあと、「アプリケーション固有の問題なのか、それとも IIS の構成問題なのか」を切り分けることが重要です。そのために役立つのが、先ほど紹介した最小テストページです。
最小テストページの例
<%
Response.Charset = "UTF-8"
Response.Write("ASP OK: " & Now())
%>
このページで確認できることは、次のとおりです。
- IIS が
.asp拡張子を正常に処理しているか - Classic ASP ランタイムが正しく動作しているか
- アプリケーション プールの権限で現在時刻を取得できるか
もしこのページが正常に表示されるのに本番の ASP ページだけがエラーになる場合は、アプリケーション固有のコードまたは web.config の中身に問題がある可能性が高くなります。逆に test.asp もエラーになる場合は、アプリケーション プールやハンドラマッピングなど IIS の設定を再確認すべきです。
よくある質問（FAQ）と落とし穴
Q1. ASP.NET を使っていないのに、なぜ ASP.NET 関連のエラーが出るの？
統合パイプライン モードでは、サイト配下の web.config に書かれている ASP.NET 設定も含めて、アプリケーション全体の構成として検証が行われます。たとえ ASP.NET ページ（.aspx）が存在しなくても、web.config 内に ASP.NET 用の設定（<system.web> セクションなど）が書かれていれば、その内容が検証され、結果として 500.24 が出ることがあります。
Q2. すべてのサイトを Classic モードにしてしまっても問題ない？
Classic ASP だけを動かすのであれば、大きな問題にはなりません。しかし、ASP.NET MVC や Web API などの新しい ASP.NET アプリケーションは統合パイプラインを前提としているものが多く、Classic モードでは機能が制限されたり、動作しなかったりする可能性があります。そのため、Classic ASP 用サイトと ASP.NET 用サイトは、別のアプリケーション プールに分けるのがベストプラクティスです。
Q3. validateIntegratedModeConfiguration=”false” を本番でも使ってよい？
使えなくはありませんが、あくまで最終手段として扱うべきです。構成検証を抑止する設定のため、後から設定を変更した際に問題を見逃すリスクが高まります。本番環境では、できるだけアプリケーション プールを Classic モードに分離し、web.config も整理したうえで運用することをおすすめします。
Q4. Classic ASP からファイルやデータベースにアクセスできない
500.24 を解消しても、ファイルアクセスや DB 接続でエラーになる場合があります。これは アプリケーション プールの実行ユーザーに必要な権限が付与されていないことが原因です。IIS 8 では通常、アプリケーション プールごとに専用の ID（ApplicationPoolIdentity）が割り当てられるため、対象フォルダーやデータベースに対して、適切な読み取り／書き込み権限を付与する必要があります。
Q5. IIS 8 から別サーバーに移行する場合、この設定はそのまま流用できる？
IIS 10 など新しいバージョンでも、統合パイプラインとクラシック モードという概念自体は変わりません。したがって、「Classic ASP 用サイトは Classic モードのアプリケーション プールで動かす」「web.config の不要な設定は整理する」といった考え方はそのまま有効です。ただし、OS のバージョンによって既定のセキュリティポリシーや暗号化設定が異なるため、移行時には必ずテスト環境で事前検証を行ってください。
チェックリストで再確認：HTTP Error 500.24 解消までの流れ
最後に、HTTP Error 500.24 が出たときに確認すべきポイントをチェックリストとしてまとめます。
| ステップ | 確認内容 | OK の状態 |
|---|---|---|
| 1 | 対象サイトのアプリケーション プール | どのプールを使用しているか把握している |
| 2 | パイプライン モード | Classic モードに切り替えている（または意図的に Integrated を維持） |
| 3 | Classic ASP 機能 | サーバー マネージャーで「ASP」役割が有効 |
| 4 | ハンドラ マッピング | 「*.asp – Active Server Pages」が「許可」 |
| 5 | web.config | <identity impersonate="true" /> など不要な設定を削除済み |
| 6 | 検証用 test.asp | ASP OK: <日時> が表示される |
| 7 | 本番ページの動作 | Classic ASP ページが正常に表示され、500.24 が出ない |
まとめ：Classic ASP は「Classic モード」で動かすのが最も確実
この記事では、IIS 8 上で Classic ASP（VBScript）が動作せず、HTTP Error 500.24 – Internal Server Error が発生する場合の原因と解決策を解説しました。
- 500.24 は、統合パイプライン モードで許可されていない web.config の設定が原因で発生する
- Classic ASP を IIS 8 で安定して動かすには、アプリケーション プールを Classic モードに変更するのがもっとも安全で確実
- どうしても統合パイプラインを維持したい場合は
validateIntegratedModeConfiguration="false"で回避できるが、最終手段と考える - Classic ASP 機能とハンドラ マッピングが有効になっているか、web.config に不要な設定が含まれていないかも合わせて確認する
- 最小の
test.aspで動作確認し、環境の問題かアプリケーションの問題かを切り分けることが重要
これらのポイントを押さえておけば、IIS 8 への Classic ASP 移行や既存環境のトラブルシュートの際に、HTTP Error 500.24 で足止めされる時間を大幅に減らすことができます。レガシーな Classic ASP であっても、適切な設定を行えば、最新の Windows Server 上でも安定して運用することが可能です。
コメント