Windows Server 2012でMilestoneのVMSを運用していると、突然カメラが切断し、Webログインが「Login failed」になることがあります。イベントビューアーにはASP.NET 4.0.30319.0やIISのエラーが出て、再起動で一時復旧…。本記事では、原因の考え方と安全な切り分け手順、暫定回避と恒久対策を整理します。
起きている現象を整理する（Windows Server 2012／Milestone VMS／ASP.NET 4.0.30319.0）
今回の症状は、単なる「IISのエラー」ではなく、VMS（監視カメラシステム）全体の処理が詰まった結果としてWeb側にエラーが出ている可能性が高いパターンです。まずは事実を揃えることで、ベンダー調査も自力の切り分けも精度が上がります。
| 観測される症状 | 同時に起きやすいこと | 切り分けの方向性 |
|---|---|---|
| カメラが頻繁に切断（Offlineになりやすい） | 録画遅延、ライブ表示の途切れ、CPU/ディスクI/Oの上昇 | Recording/Media系サービス、ストレージ性能、ネットワーク、同時接続数の負荷を疑う |
| VMSへのログインが「Login failed」になる | ログイン画面が重い／認証後にエラーで戻る | 認証サービス、バックエンドの応答遅延、Webコンポーネントのハングを疑う |
| ブラウザーに「Invalid token」等が表示される | 再ログインしても失敗、別端末は通る/通らないが分かれる | トークン（セッション/クッキー）不整合、時刻ずれ、Web側の状態不良を疑う |
| イベントビューアーに「ASP.NET 4.0.30319.0」「IIS」関連のエラー | “Request timed out”系、アプリプール停止/リサイクル、応答不能 | エラー自体は“結果”のことが多いため、原因はVMS側ログと突合する |
| サーバー再起動で一時的に復旧する | しばらくは安定するが再発 | メモリリーク/ハンドル枯渇、サービスのハング、キャッシュ破損など「状態」に依存する不具合を疑う |
ポイントは、「ASP.NET 4.0.30319.0のイベント＝原因」と決め打ちしないことです。VMSのWebコンポーネントがIIS上で動いている場合、バックエンドのサービスが詰まると、表面上はIIS/ASP.NETが失敗ログを出しやすくなります。
最優先はMilestone（VMS）ベンダーに調査・対処を依頼すること
結論から言うと、まずはVMS（Milestone）ベンダーに調査・対処を依頼するのが最優先です。イベントがASP.NET/IISに見えても、実際はVMSの認証処理、内部サービス、DB/ストレージ、録画サービス、ライセンス管理など、VMS固有の領域が絡むことが多く、ベンダーが最も状況を把握しています。
ベンダー依頼が「丸投げ」にならないよう、次の情報をまとめて渡すと調査が一気に進みます。
| 渡す情報 | 具体例 | なぜ重要か |
|---|---|---|
| 発生時刻（分単位で） | 「12/30 10:12頃からログイン不可、10:25再起動で復旧」 | VMSログ、Windowsイベント、IISログの時刻突合に必須 |
| 対象コンポーネント | Management/Recording/Mobile/Webのどれか、同居/別サーバーか | 原因切り分け（Webのみ／録画も同時か）に直結 |
| イベントログの抜粋 | Application/System、該当エラーの本文、直前直後の関連イベント | “Request timed out”か、プロセス異常か、依存先障害かを判断できる |
| IISログ（該当時刻） | ステータスコード（例：500/503/504）、処理時間、URL | Web側が「落ちた」のか「遅くて間に合わない」のかが分かる |
| 負荷状況の証跡 | CPU/メモリ/ディスク使用率、同時接続、カメラ台数、録画ビットレート | 負荷起因（飽和）か、バグ/設定問題かを切り分けできる |
| 構成・バージョン | Milestone製品名/バージョン、OS、.NET、パッチ状況、SQLの有無 | サポート範囲・既知不具合・互換性の確認に必要 |
加えて、「再起動で復旧する」という情報は非常に重要です。これは多くの場合、設定ミスよりもプロセスのハング、内部キュー詰まり、リソース枯渇、キャッシュ/セッションの破損といった“状態依存”の障害を示唆します。
ASP.NET 4.0.30319.0 / IISのイベントが出る典型的な仕組み
イベントビューアーの「ASP.NET 4.0.30319.0」は、.NET Framework 4系（CLR 4）のASP.NET実行環境を示す表記です。IIS上で動くVMSのWebコンポーネント（Web Client、Mobileアクセス、管理用Webなど）が.NETで実装されている場合、次のような流れでエラーが表面化します。
- ユーザーがブラウザーからログイン要求を送る（認証API呼び出し）
- IIS（w3wp.exe）が要求を受け取り、ASP.NETアプリが処理を開始する
- ASP.NETアプリがVMSの内部サービスやDBへ問い合わせる
- 内部サービスが遅い/停止/応答なし → Web要求が待たされる
- 一定時間を超えるとタイムアウト → IIS/ASP.NETにエラーが記録され、画面は「Login failed」や「Invalid token」になる
つまり、「IISが悪い」のではなく、IISが“詰まり”を検知してログを残しているだけ、というケースが珍しくありません。もちろんIIS側の設定やアプリプールの状態が原因になることもありますが、まずはVMSのバックエンドが健全かを同時に見ていくのが近道です。
復旧手順は「影響が小さい順」で設計する（再起動の前にできること）
運用上、毎回サーバー再起動で復旧させると、録画欠損や監視断が増え、復旧時間も長くなります。可能であれば、影響範囲の小さい操作から試す“復旧の階段”を用意しておくと、現場対応が安定します（ただし、変更や操作は必ずベンダー推奨を優先してください）。
| 復旧操作（影響が小→大） | 狙い | 注意点 |
|---|---|---|
| ブラウザーの再ログイン／別ブラウザーで再現確認 | クッキー/セッションの不整合を排除する | 一時的に通っても根本は未解決。再現条件の切り分けに使う |
| VMSのWeb関連サービス再起動 | Webコンポーネントのハングを解消する | サービス名は構成で異なる。録画系と混同しない |
| IISアプリケーションプールのリサイクル | Webプロセス（w3wp）の状態を初期化する | セッションが切れる可能性。実施時刻と影響範囲を記録 |
| IISの再起動（iisreset等） | IIS全体の固着を解消する | 同一サーバー上の他Webにも影響。実行可否は運用で判断 |
| VMSの主要サービス再起動 | 認証/管理/録画などバックエンドの詰まりを解消する | カメラ断や録画停止が起き得る。手順書と周知が必須 |
| サーバー再起動 | OS含めて状態を全リセットする | 復旧まで時間がかかり、録画欠損リスクが最大 |
この「復旧の階段」は、障害対応を標準化するのに役立ちます。特に“再起動で直る”系の障害は再発しやすいため、どの段で復旧するのかを記録していくと、原因が見えやすくなります。
IISのタイムアウト延長は“効くこともあるが、隠すだけになることもある”
イベントが“Request timed out”（要求のタイムアウト）系であれば、IISやASP.NETのタイムアウト値が短すぎて、重い処理に耐えられていない可能性があります。たとえば、カメラ台数増加や同時アクセス増加、ストレージ逼迫などで処理が遅くなったとき、Web要求が間に合わず「Login failed」やエラーイベントにつながることがあります。
ただし、タイムアウト延長は根本原因（遅い/止まる）を解消するものではありません。むしろ「タイムアウトで切れていたものが、長時間ぶら下がる」ことで、別の詰まりを誘発する場合もあります。実施するなら、次の考え方が安全です。
| 判断基準 | タイムアウト延長を検討してよいケース | 先に疑うべきケース |
|---|---|---|
| 発生条件 | 高負荷時だけ発生し、処理が遅いだけ（最終的には返る） | 低負荷でも突然発生、再起動まで戻らない（ハング） |
| IISログ | 処理時間がタイムアウト閾値付近で揺れる | 短時間で503/500が連発、プロセス再起動痕跡がある |
| 運用目的 | 恒久対策（性能改善/構成見直し）までの暫定回避 | 原因未調査のまま延命したい（後で大きく悪化しやすい） |
IISマネージャーで触れる設定は環境により異なりますが、代表的には次の要素が関係します。
- 接続タイムアウト：サイトやアプリの接続保持
- 要求実行タイムアウト：ASP.NET処理が一定時間を超えたときの扱い
- アプリケーションプール設定：Idle Time-out、Ping、Rapid-Fail Protectionなど
設定変更をする場合は、必ず変更前の値を記録し、変更後の再発頻度とイベント/ログの変化をセットで追いかけてください。ベンダーの推奨値や既知不具合により、触るべき設定が限定されることがあります。
「Invalid token」が出るときの切り分けポイント
「Invalid token」は、ざっくり言うとサーバーが受け取った認証情報（トークン/セッション）が正しく解釈できない状態です。原因は一つではなく、同じ表示でも複数の要因が混ざります。以下の表を“当たりを付ける地図”として使うと、調査が進みます。
| よくある要因 | 現場での見え方 | 確認ポイント（例） |
|---|---|---|
| サーバー時刻のずれ（NTP/ドメイン時刻） | ある時刻を境に全員がログイン不可、再起動後しばらく復旧 | サーバー時刻とクライアント時刻、時刻同期状態、ドメイン参加環境ならDCとの同期 |
| Web側のセッション/クッキー不整合 | 特定端末だけ失敗、別ブラウザーだと通る | Cookie削除、シークレットウィンドウ、別端末で再現するか |
| Webプロセスの不調（アプリプール固着） | ログイン画面が重い、API呼び出しがタイムアウト | w3wpのCPU/メモリ、IISログの応答時間、アプリプールのリサイクルで改善するか |
| バックエンド認証サービスの応答不良 | ログインだけ失敗、録画/カメラ切断も同時に起きる場合あり | VMSサービスの稼働状態、サービスログ、依存するDB/AD/証明書の状態 |
| 証明書/TLSの問題（期限・チェーン・暗号スイート） | 特定ブラウザーや端末だけ失敗、更新を境に再発 | サーバー証明書の有効期限、チェーン、OS更新後の暗号設定変更の有無 |
時刻ずれは盲点になりやすいので、確認だけでもしておく価値があります。例として、Windowsでの確認コマンドは次のようになります。
w32tm /query /status
w32tm /query /configurationまた、アプリプールのリサイクルやIIS再起動で「Invalid token」が収まる場合、セッションを保持しているプロセス側の状態不良が疑われます。この場合も「なぜ状態が悪化したのか（負荷/リーク/依存先障害）」が本丸です。
再起動で一時復旧する障害で疑うべき“3つの大分類”
Windows Server 2012で、再起動を境に一旦安定し、時間が経つと再発する障害は、経験上次の3カテゴリに収束しやすいです。
リソース枯渇（メモリ/ハンドル/スレッド/ディスクI/O）
監視カメラVMSは、録画・配信・解析などで常に負荷がかかり、台数やビットレート増加がじわじわ効いてきます。表面上はIIS/ASP.NETのエラーに見えても、実際はディスクI/O飽和やメモリ逼迫でバックエンドが遅くなり、結果としてWeb要求がタイムアウトすることがあります。
プロセスのハング（内部キュー詰まり、待ち状態が解けない）
CPUやメモリが余っているのに応答がなくなる場合、内部でロック待ち、外部接続待ち（DB/AD/ネットワーク）、スレッド枯渇などが起きていることがあります。再起動で直るのは、詰まった状態がリセットされるからです。
キャッシュ/セッション/一時ファイルの破損や肥大化
Webコンポーネントはトークンやセッションを保持します。破損や不整合が蓄積すると「Invalid token」やログイン失敗に見えることがあります。これも再起動（またはアプリプール再起動）で一旦戻ります。
この3カテゴリのどれに近いかを見極めるには、発生直前の負荷データが重要です。可能なら、次の観測点を用意します。
| 観測項目 | 見る場所 | 異常の目安（例） |
|---|---|---|
| CPU使用率 | タスクマネージャー/PerfMon | 長時間高止まり、w3wpやVMSプロセスが占有 |
| メモリ使用量 | タスクマネージャー/PerfMon | 空きが極端に少ない、特定プロセスが増え続ける |
| ディスクI/O | リソースモニター/PerfMon | 待ち行列が大きい、書き込みが詰まり録画遅延が出る |
| ネットワーク | スイッチ/サーバー側統計 | 瞬間的な輻輳、パケットロス、NICドライバエラー |
| IIS応答時間 | IISログ | 処理時間が急増し、エラーコードが増える |
「何が起きたか」を数字で押さえると、ベンダーに伝える情報の質も上がり、恒久対策（性能改善/構成見直し）にもつながります。
イベントビューアーを見るときのコツ（エラーだけ追わない）
イベントビューアーを確認するときは、エラー行だけでなく、同じ時刻帯の“前後関係”を必ず見てください。ASP.NET/IISのエラーは、原因ではなく“最後に表に出た失敗”のことが多いからです。
- Applicationログ：.NET Runtime、ASP.NET、アプリケーション固有ログ、SQL関連
- Systemログ：ディスク、NIC、サービス停止、時間同期、再起動関連
- Windowsログ以外：VMS独自ログ、インストール先ログ、DBログ
さらに、IISが関係する場合は、イベントログ＋IISログのセットが強力です。IISログに「その瞬間のURL」「ステータスコード」「処理時間」が残ると、ログイン画面の裏で何が詰まったかが見えてきます。
暫定回避としての運用設計（“再発前提”で守りを固める）
恒久対策がすぐに難しい場合、再発前提で「被害を小さくする」運用設計も重要です。たとえば次のような考え方です。
- 復旧操作の標準化：誰が対応しても同じ順番・同じログが残る
- 復旧のトリガー条件を決める：何分ログイン不可ならどの段を実施するか
- 録画欠損を最小化：再起動の時間帯や影響範囲を事前に把握する
- ログ採取を自動化：発生時刻のイベントログ/IISログを確実に保存する
特に「サーバー再起動」でしか戻らない状況は、運用の負担が大きくなります。上で紹介したサービス再起動／アプリプールのリサイクルで復旧できるかどうかを確認できると、録画システムへの影響を抑えられる可能性があります（ただし、実施は必ずベンダー推奨の範囲で）。
恒久対策の方向性（原因を潰し、再発しない状態へ）
根本的には、次のいずれか（または複合）が恒久対策になります。環境により優先順位は変わるため、ベンダーの見解と突合しながら進めるのが安全です。
VMSのバージョンアップ／既知不具合の解消
Milestone側で、特定バージョンのWebコンポーネントや認証周りに不具合がある場合、アップデートが最短の解決策になります。Windows Server 2012は世代的に古く、組み合わせによってはサポート条件が厳しくなることもあるため、サポート対象の組み合わせを確認したうえで進めるのが重要です。
役割分離（Web/管理/録画/DBを同居させない）
1台にすべて載せる構成は管理が楽ですが、負荷が集中するとカメラ切断とWebログイン障害が同時に起きる典型パターンになります。可能なら、Web（IIS）と録画（I/O負荷が大きい）を分ける、DBを別にするなど、ボトルネックを分離すると安定しやすくなります。
ストレージ/ネットワークのボトルネック解消
録画系はディスクI/Oの影響を強く受けます。I/Oが詰まるとサービス応答も遅くなり、Web側がタイムアウトしやすくなります。ディスク構成（RAID、キャッシュ、空き容量、断片化、コントローラ）、ネットワーク（帯域、マルチキャスト/ユニキャスト、NIC設定）を見直すことで、症状が消えることもあります。
監視とアラートの整備（“落ちる前に気づく”）
「気づいたらログイン不可」では復旧が後手になります。CPU/メモリ/ディスクI/O、IIS応答、VMSサービス状態を監視し、閾値超過で通知するだけでも、障害の頻度と影響を減らせます。ログイン障害の前に“兆候”が出るケースは少なくありません。
よくある質問（現場で迷いやすいポイント）
ASP.NET 4.0.30319.0のエラーが出ているので、.NETを再インストールすべき？
いきなり再インストールはおすすめしません。VMSのサポート条件により、.NETやWindows更新の当て方に制約がある場合があります。まずはベンダー推奨のバージョン/更新方針を確認し、イベントが「原因」なのか「結果」なのかを見極めるのが安全です。
IISのタイムアウトを伸ばしたら直る？
“Request timed out”系で、処理が単に遅いだけなら改善することがあります。一方で、バックエンドが止まっている場合は改善しません。タイムアウト延長は暫定策として扱い、同時に遅くなる原因（負荷/ストレージ/サービス不調）を潰すのが王道です。
再起動以外で復旧できるとしたら何を試す？
影響が小さい順に、VMSのWeb関連サービス再起動 → IISアプリプールのリサイクル → IIS再起動の順で試せるかを検討します。ただし、実施可否や手順は構成とベンダー方針に左右されるため、運用前に必ず確認してください。
まとめ：IIS/ASP.NETのイベントは“手がかり”。原因はVMS側ログとセットで詰める
Windows Server 2012で、MilestoneのVMS運用中に「ASP.NET 4.0.30319.0 / IISのイベントが出る」「Login failedでログインできない」「Invalid tokenが出る」「カメラが切断する」「再起動で一時復旧する」といった症状が重なる場合、IIS/ASP.NETは“結果としてエラーを出している”可能性が高いです。
最短で解決に近づくためには、ベンダーへの調査依頼を最優先にしつつ、発生時刻・イベントログ・IISログ・負荷状況を揃えて突き合わせること。暫定回避としては、サーバー再起動の前にVMSサービス再起動やIIS（アプリプール）のリサイクルで復旧できるかを確認し、運用の被害を小さくすることが有効です。
そして、恒久対策は「設定値をいじる」よりも、VMSのログに基づいた原因特定（不具合/負荷/構成）→バージョン更新や構成改善の順で進めるのが、結果的に安全で確実です。
コメント