none
ディレクトリの参照設定が勝手に無効になる? RRS feed

  • 質問

  • お世話になります。
    社内イントラにて、基幹システムから日次生成したPDFファイルを公開するため、IIS7.5で以下の運用を行っています。

    ・Default Web Site配下に仮想ディレクトリを2つ(仮にA,B)作成
    ・いずれも[ディレクトリの参照]機能を"有効"に設定
    ・いずれも[既定のドキュメント]は、"無効"に設定
     (サーバ内の物理ディレクトリに保存しているPDFファイルを表示するのが目的のため、[既定のドキュメント]設定は無効にしています。)

    この状況で、仮想ディレクトリAの方でのみ、しばしば、クライアントブラウザで表示すると403.14エラーとなり、
    ページの表示ができなくなってしまう現象が発生しています。(朝出社するとユーザからの問合せで判明)
    IISの設定を見てみると、いずれのケースも[ディレクトリの参照]機能がいつの間にか"無効"に設定が変わっていました。

    私はもちろん、ほかの管理者に聞いてみても設定は変更していないとのことで、現象発生のトリガーが全く分からず根本原因の解消には至っていません。
    このように、(勝手に?)ディレクトリ参照の設定が変わってしまうことがあるのでしょうか。



    • 編集済み pekope 2015年8月21日 6:53
    2015年8月21日 6:50

回答

  • 仮想ディレクトリA 配下に存在するIISの構成ファイル「web.config」ファイルを、何らかの処理で誤って削除されていませんか?

    当方でも類似の事象が発生し、調べたところ、対象仮想ディレクトリのルート配下の全ファイルを

    定期的に削除する業務タスクが稼働しており、それが影響していた事例がありました。

    • 回答としてマーク 佐伯玲 2015年10月8日 5:03
    2015年9月30日 10:33

すべての返信

  • >このように、(勝手に?)ディレクトリ参照の設定が変わってしまうことがあるのでしょうか。
    通常はありません。

    朝に現象を確認というあたりから Windows Update か何か夜間処理で異常が発生し予期しないロールバックやリブートが発生しているのではないか、など色々邪推は出来ますが、情報が少なすぎるので思いつきでしか無く何とも言えません。
    システムログから何が起きているのかを追うというのと、想定外のユーザーのログインが発生していないか、両面から確認を進めたほうがよろしいかと思います。


    MCITP(Database Developer/Database Administrator)

    • 回答の候補に設定 佐伯玲 2015年8月27日 0:56
    • 回答としてマーク 佐伯玲 2015年9月2日 4:49
    • 回答としてマークされていない 佐伯玲 2015年9月15日 6:14
    2015年8月26日 4:44
  • コメントいただき、ありがとうございます。
    本日、当該現象が発生しました。
    そこで、nagino-引退エンジニア様からのアドバイスに沿い、前回発生時と今回発生時の検証を行い、情報を整理しました。
    しかし、いずれも原因の特定には至っていません。
    追加で確認する点や検証視点が誤っている部分がありましたら、ご指摘いただけませんでしょうか。


    ■検証ポイント
    ①Windows Update
    該当仮想ディレクトリの最終アクセス時間から現象発生直前までのシステムイベントログでは、WindowsUpdate関連のログは未発生。
    また、WndowsUpdateClientイベントログも確認しましたが、Windows Updateエージェントによる更新プログラムの確認が行われているだけで、結果は「0件の更新プログラムが見つかりました」のみ。
    そして、随時「Windows Update の正常性に変化がありました。」ログが残されていましたが、関連性は低いかと。

    ②システムイベントログ全体
    該当仮想ディレクトリの最終アクセス時間から現象発生直前までのシステムイベントログを確認したところ、レベル=エラーのログはなし。特記するとすれば以下です。
    ・Application Experience サービス
     →停止と実行が随時実施(403.14エラー発生時は実行状態)
    ・WinHTTP Web Proxy Auto-Discovery Service サービス
     →停止と実行が随時実施(403.14エラー発生時は停止状態)
    ・アプリケーション プール 'DefaultAppPool' で使用されている '1960' のプロセス ID のワーカー プロセスは、アクティブでなかったためシャットダウンされました。アプリケーション プール タイムアウト構成は、20 分に設定されました。新しいワーカー プロセスは必要なときに開始されます。
     →毎日同時間帯に発生しており、関連性は低いかと。

    ③想定外のユーザーのログイン発生有無
    ローカルドライブのinetpub\logs\LogFilesにあるログを確認しましたが、該当仮想ディレクトリの最終アクセス時間から403.14エラー発生タイミングまでの間、社内IPアドレス以外からのアクセスはありませんでした。
    そして、403.14エラーの発見者となったUserも社内利用者のIPでした。

    ④タスクスケジューラーのタスク確認
    タスクスケジューラーライブラリ内(全ディレクトリ)にあるすべてのタスクを確認しましたが、前回と今回の403.14エラー発生日に実行されているタスクは発見できず。

    2015年9月15日 4:55
  • 仮想ディレクトリA 配下に存在するIISの構成ファイル「web.config」ファイルを、何らかの処理で誤って削除されていませんか?

    当方でも類似の事象が発生し、調べたところ、対象仮想ディレクトリのルート配下の全ファイルを

    定期的に削除する業務タスクが稼働しており、それが影響していた事例がありました。

    • 回答としてマーク 佐伯玲 2015年10月8日 5:03
    2015年9月30日 10:33
  • hsskt様
    コメントいただき、ありがとうございます。
    web.configファイルが削除されているという視点で再確認しました。

    ■確認結果
    基幹システムからPDFファイルを日次生成する処理の中で、Export先である仮想ディレクトリAの物理フォルダに保存されているファイルのうち、更新日時が既定日以前のファイルを削除する処理を発見しました。
    同処理を検証したところ、web.configファイルの更新日時も既定日を過ぎてしまうと削除され、その結果、403.14エラーになることが確認できました。
    (削除ファイルをPDFに限定したり、web.configファイルは除くなどの回避措置は記述されていませんでした。。。)

    本日、原因となっていたファイル削除処理の対応を行いましたので、既定日を過ぎても403.14エラーが出なければ、解決とさせていただきます。
    有益な情報をいただき、ありがとうございました。

    2015年10月7日 2:53
  • 上記の件、web.configファイル削除除外処理を講じた結果、本番環境で403.14エラーを回避することに成功しましたので、回答済みとしてマークさせていただきます。

    nagino-引退エンジニア様、hsskt様、アドバイスをいただき、誠にありがとうございました。

    • 回答としてマーク pekope 2015年10月19日 0:09
    • 回答としてマークされていない pekope 2015年10月19日 0:09
    2015年10月19日 0:09