IIS7で新しいサイトを作成し、そのサイトの下に新しいアプリケーションを追加しました。次に、この新しいアプリケーションの下に格納されているASP.NET Webサービスを使用しようとすると、HTTP500内部サーバーエラーが発生します。
イベントログIIS Logsを調べて、「Failed Request Tracing」を設定しようとしましたが、何もトレースされていないようです。すべてのコンテンツをチェックするように設定しています。詳細エラーロギング、および400〜600の範囲のHTTPエラー。ただし、FailedReqLogFilesフォルダーの下には何もログに記録されません。このIIS構成の他のサイトは、失敗した要求を正常にトレースしているようです。
HTTPGETリクエストがそのサイトのIISログに記録されているのを確認できますが、リクエストが500エラーを返しているだけなので、明らかにあまり役に立ちません。
Explorerでサイトフォルダーのアクセス許可を確認し、匿名アクセスがオンになっていて、アプリプールIDがフォルダーのコンテンツにもアクセスできることを確認しました。
何か案は?問題について十分な情報を提供しましたか?あなたが与えることができるどんな助けまたは提案にも前もって感謝します。
Failed Request Tracingでは、ルールを設定する必要がありますが、別の手順としてルールをオンにする必要があります。失敗したリクエストのトレースで、右側の[アクション]ペインを確認します。これには、それを有効にするオプションがあります。これが、トレースが機能しない理由についての私の推測です。
アプリプールごとに1つのサイトがある、またはすべてのサイトが相互に信頼し、サイトが安定しているIIS7の構成に関する私の推奨事項は、アプリプールのIDを使用するように匿名認証を設定することです。これにより、処理するユーザーが1人少なくなります。次に、アプリプールIDにディスク上のアクセス許可が付与されていることを確認します。
サブフォルダーでは機能しないとおっしゃっています。サブアプリケーションに異なる権限または異なるアプリプールを使用することができます。使用されているアプリプールと匿名認証設定を再確認してください。
最後に、Colinが提案したようにProcessMonitorを使用します。 www.sysinternals.comから入手してください。本番サーバーで実行するのは無料で安全であり、10分以内に理解できます。これにより、どのユーザーがどのフォルダー(またはレジストリキー)へのアクセスを拒否されているかが正確にわかります。
Process Monitor を実行して、IISにFRTログを書き込むための適切なアクセス許可があるかどうかを確認しましたか?
Web.configを確認してください。偽装= trueはありますか?
この場合、IISで匿名アクセスを使用すると、アプリケーションプールユーザーではなく、IIS匿名ユーザーがweb.configを読み取ろうとします。
すべての提案とは別に、Chrome Dev Tool [F12を押す]を試して、手がかりが得られるかどうかを確認することもできます。同様に、IE [F12を押す]クロームが使えない場合も同様です。
https://developer.chrome.com/devtools 詳細については、ネットワークとコンソール領域をご覧ください。
Web.configは、Webアプリケーションフォルダーのルートにある必要があります。そうしないと、あらゆる種類のエラーが発生します。