MID ServerがDownのまま戻らない。インストールしたのにValidatedにならない。StatusはUpなのにDiscoveryが一向に始まらない——「MID Serverが接続できない」と調べるとき、実際に起きているのはだいたいこの3パターンのどれかです。そして厄介なことに、この3つは原因の層が違うため、見るべき画面も対処もそれぞれ別物です。層を意識せずにMID Serverの再起動だけを繰り返すと、直った理由も分からないまま翌週また止まります。
この記事は、MID Serverの接続トラブルを①ホストの稼働 → ②インスタンスへの経路 → ③認証 → ④検証と仕事の割り当ての4層で切り分けられるようになるための判断ガイドです。まず「通信は外向き一方向」という大前提を押さえ、症状別の早見表で当たりを付け、原因別の対処、落ちてから気づかないための予防設定、最後にCIS-Discovery試験でこの領域がどう問われるかまで、この順で進みます。
要点まとめ
- MID Serverの通信は、常にMID側からインスタンスへの外向きHTTPSです。インスタンス側からMID Serverへ接続しに行く経路はそもそも存在しません。
- 状態確認の場所は3つ。MID Server一覧（StatusとValidated）／ECC Queue（仕事の受け渡し台帳）／ホスト側のagentログです。
- 「Down」「Not Validated」「UpなのにDiscoveryが動かない」は別の層の問題です。層の浅い順（ホスト→経路→認証→割り当て）に確認すると、原因に最短で届きます。
MID Server・接続系の理解をCIS-Discovery無料模試で確認する
この記事で扱う切り分けの判断は、模試のDiscovery分類・実務パターン特訓でそのまま出題形式として確認できます。
大前提：MID Serverの通信は「外向き一方向」
切り分けを始める前に、MID Serverの構成で一番大事な事実を1つだけ押さえます。通信を開始するのは常にMID Server側で、社内ネットワークに置かれたMID Serverが、インスタンスへHTTPS（443番ポート）でポーリングし続ける、という向きです。インスタンスがファイアウォールを越えて社内のMID Serverに接続しに来ることはありません。
この一方向性を知っていると、調査の空振りが激減します。たとえば「インスタンスからMIDへの疎通を確認してほしい」という依頼は、確認する対象が最初から存在しません。逆に、社内側で見るべきは「MID Serverのホストから、インスタンスのURLへ外向き443が通るか」の一点に絞られます。プロキシ経由の環境なら、プロキシの設定と認証がこの経路上に乗ります。
仕事の受け渡しはECC Queue（ecc_queueテーブル）で行われます。インスタンスが「この探索をやってほしい」という指示をoutputレコードとして積み、MID Serverがポーリングで取りに来て実行し、結果をinputレコードとして返す——この台帳を読めるようになると、「指示がそもそも出ていない」のか「指示は出たがMIDが取りに来ていない」のか「実行したが結果がエラー」なのかを、レコードの向きと状態から判別できます。
状態を確認する場所は3つ
- MID Server一覧（MID Server > Servers）：各MID ServerのStatus（Up/Down）とValidated（検証済みかどうか）を最初に見ます。ここが起点です。
- ECC Queue：仕事の流れを見ます。outputがready（未処理）のまま溜まっていればMIDが取りに来ておらず、inputにエラー応答が並んでいれば実行側の失敗です。
- ホスト側のagentログ：MID Serverをインストールしたサーバーの、インストールフォルダ配下 agent/logs にあるログ（agent0.log.0など）です。認証失敗・プロキシエラー・証明書エラーといった「外に出られない理由」はここに残ります。
症状から当たりを付ける判断早見表
実際のトラブルでは、症状から逆引きするのが最短です。よくある症状と、最初に見る場所・典型原因を対応させた早見表を先に置きます。
横にスクロールできます
| 症状 | 最初に見る場所 | 典型的な原因 |
|---|---|---|
| 全MID Serverが一斉にDown | ネットワーク・プロキシの変更履歴 | プロキシ設定変更、証明書更改、ファイアウォールルール変更で外向き443が遮断 |
| 特定の1台だけDown | そのホストのサービス稼働状況 | Windowsサービス停止、ホスト再起動後の起動失敗、リソース枯渇 |
| agentログに認証エラーが繰り返し出る | MID Serverユーザーのアカウント状態 | パスワード期限切れ・ロック、mid_serverロールの剥奪 |
| UpだがNot Validatedのまま | MID Serverレコードの検証状態 | 初期構築・再インストール後に検証（Validate）が未実施 |
| Up・Validated済みだがDiscoveryが始まらない | Discoveryスケジュールの MID割り当て | IPレンジ・アプリケーションの割り当てが合わず、仕事がそのMIDに配られない |
| 実行はされるが途中で止まる・結果が返らない | ECC Queueの滞留状況 | outputのready滞留（取得側の詰まり）、同時実行数の上限、MIDホストの性能不足 |
| インスタンスのアップグレード直後にDown | MID Serverのバージョン表示 | 自動アップグレードの失敗。バージョン不整合のまま停止 |
この表の背後にあるのが、冒頭で挙げた4層です。①ホストでプロセスが動いているか → ②インスタンスまで経路が通っているか → ③MID Serverユーザーとして認証できているか → ④検証済みで、仕事が割り当たる設定になっているか。下の層が死んでいれば上の層は全部止まるので、必ず浅い層から順に確認します。①②③のどれかが原因ならStatusはDownになり、④が原因ならStatusはUpのまま「動かない」という見え方になります。症状がDownかUpかで、調べる層を最初から絞れるということです。
Status: Down のときの切り分けと対処
Downは「MID Serverからの生存報告（ハートビート）がインスタンスに届いていない」状態です。①ホスト、②経路、③認証のどこかが折れています。
層①：ホストでサービスが動いているか
最初に確認するのは、MID Serverをインストールしたサーバー自体です。Windowsならサービス一覧でMID Server名を含むサービスが「実行中」か、Linuxならプロセスが生きているかを見ます。ホストのOS再起動後にサービスの自動起動設定が漏れていて、そのまま止まっていた——という原因は、拍子抜けするほど多いです。ディスクフルやメモリ枯渇でJavaプロセスが落ちるケースもここに含まれます。サービスを起動して数分待ち、Statusの回復を確認します。
層②：インスタンスへ外向きに出られるか
サービスは動いているのにDownのままなら、経路を疑います。MID Serverの接続先やプロキシ設定は、インストールフォルダ内のconfig.xmlに定義されています。確認の観点は3つです。
- ホストからインスタンスURLへ、外向きHTTPSが実際に通るか（ブラウザやコマンドでインスタンスURLに到達できるか）
- プロキシ経由の構成なら、config.xmlのプロキシ設定が現行のプロキシと一致しているか。プロキシ側の設定変更・証明書更改は、複数のMID Serverを同時にDownさせる代表的な原因です
- agentログにSSL/証明書系のエラーが出ていないか。社内でTLS検査（HTTPS復号）を挟む構成に変わった場合、ここで折れます
層③：MID Serverユーザーとして認証できているか
経路が通っていても、インスタンスに「誰として」接続するかで折れることがあります。MID Serverはインスタンス上の専用ユーザー（mid_serverロールを持つユーザー）で認証します。このユーザーのパスワード期限切れ・アカウントロック・ロール剥奪が起きると、agentログに認証エラー（401系）が繰り返し記録されます。ユーザー棚卸しで「使っていないアカウント」と誤認されて無効化される事故は、現場で実際に起きがちです。アカウントを復旧し、パスワードを変更した場合はMID Server側の設定も更新します。
UpなのにDiscoveryが動かないときの切り分け
StatusがUpで層①〜③が健全でも、Discoveryが動かないことがあります。ここからは④「検証と仕事の割り当て」の層です。
Not Validated のまま使おうとしていないか
新規インストールや再インストールの直後、MID Serverは接続に成功していても未検証（Not Validated）の状態です。検証が済んでいないMID ServerにはDiscoveryなどの処理が割り当てられません。MID Serverレコードを開いて検証（Validate）を実行し、Validatedになったことを確認します。「Upになったから完了」と思って検証を忘れる——初期構築でつまずく定番ポイントで、CIS-Discovery試験でもこの前提はよく問われます。
仕事がそのMID Serverに配られる設定になっているか
DiscoveryスケジュールがどのMID Serverを使うかは、スケジュール側の指定と、MID Server側のIPレンジやアプリケーションの割り当てで決まります。自動選択に任せている場合、探索対象のIPレンジがどのMID Serverの担当範囲にも入っていなければ、エラーらしいエラーも出ないまま「何も起きない」ように見えます。対象IPレンジと、各MID Serverの割り当て範囲を突き合わせて、担当が存在するかを確認してください。担当不在は、Down系の障害よりも発見が遅れやすい落とし穴です。
ECC Queueで仕事の流れを読む
割り当ても正しいのに動かない・途中で止まる場合は、ECC Queueを時系列で見ます。読み方の要点はこうです。
- outputレコードが作られていない：インスタンス側がそもそも指示を出していません。スケジュールの起動条件や対象定義を見直します
- outputがreadyのまま滞留：指示は出たがMID Serverが取りに来ていません。対象MIDの状態か、処理能力の飽和（同時実行の上限に張り付いている）を疑います
- inputにエラー応答が返っている：MID Serverは動いており、実行段階で失敗しています。エラー内容を読んで対象側の問題（到達性・資格情報）へ進みます
なお、対象機器側の資格情報（SSH/SNMP/WMI）や到達性の問題は、MID Serverの接続トラブルとは層が別です。そちらの全体像はDiscoveryとMID Server・CMDB・CSDMの役割整理の記事で扱っているので、本記事では「MID Serverまでは健全」を確定させるところまでを守備範囲とします。
インスタンスのアップグレード直後は「バージョン」を見る
インスタンスをアップグレードすると、MID Serverは対応バージョンへ自動アップグレードされます。この自動アップグレードがダウンロード失敗や権限不足で転ぶと、バージョン不整合のまま停止し、Downや不安定な挙動として現れます。アップグレード直後にMID Serverだけ調子が悪いときは、まずMID Serverレコードのバージョン表示がインスタンスと整合しているかを確認し、必要なら手動での再起動・再インストールで復旧します。「インスタンスのアップグレード計画にMID Serverの確認を含める」のが予防側の定石です。
典型パターン：プロキシ更改の月曜日
切り分けの流れを、現場でよくある典型例で通してみます。月曜の朝、Discoveryの結果が金曜から更新されていないことに気づく。MID Server一覧を見ると、社内に3台あるMID Serverが全部Down。全台一斉という時点で、個々のホスト障害（層①）ではなく共通経路（層②）が本命です。agentログを見るとプロキシ認証エラーが金曜夜から連続している。ネットワークチームに確認すると、週末にプロキシの証明書と認証方式が更改されていた——config.xmlのプロキシ設定を新環境に合わせて更新し、順次復旧。ECC Queueに滞留していたoutputが流れ始め、Discoveryが再開する。
このケースで怖いのは、障害そのものより放置した場合の二次被害です。MID Serverが止まっている間、CMDBは更新されず古い構成情報のまま残ります。その状態で変更作業の影響分析やインシデントの原因調査をすると、「実態と違う地図」を信じて判断することになります。Discoveryの停止は「発見の停止」ではなく「CMDBの鮮度劣化」として効いてくる——ここがMID Server監視を軽視できない理由です。
予防：落ちてから気づかない構成にする
切り分けが速くなったら、次は「そもそも気づける・止まらない」構成に寄せます。優先度の高い順に3つです。
- Downの通知を仕込む：MID ServerのStatusがDownに変わったら通知が飛ぶようにしておきます。今回の典型例のように「月曜に気づく」のは、監視がなければ当然の結果です。
- 複数台で冗長化する：重要な探索範囲を1台のMID Serverに依存させず、複数台に同じ範囲を担当させて片系停止に耐える構成にします。1台構成は「そのホストの再起動＝Discovery全停止」を意味します。
- 運用イベントをカレンダー化する：MID Serverユーザーのパスワード期限、プロキシ・証明書の更改予定、インスタンスのアップグレード日程。この記事で挙げた原因の多くは「予定された変更」の副作用なので、予定に紐づけてMID Serverの事前・事後確認を入れるだけで大半を未然に防げます。
PDIでどこまで確認できるか
MID Serverは「社内ネットワークに置く実行役」なので、PDI（開発者インスタンス）だけでは体験しづらい領域です。それでも次の使い分けで、試験対策として必要な画面感覚は得られます。
- PDIで見られるもの：MID Server一覧の画面構成、ECC Queueテーブルの構造、Discoveryスケジュールの設定項目。レコードが空でも「どこに何があるか」は確認できます
- 手元のPCをMID Serverにする：インスタンスからMID Serverのインストーラーを取得し、自分のPCに入れてPDIへ接続することも可能です。Up/Downの変化、検証の手順、ECC Queueにレコードが流れる様子まで実体験できます。ただしPDIは一定時間で休止するため、休止明けはMID Server側の再接続を待つか再起動する前提で使ってください
- 公式ドキュメントで補う：ネットワーク要件やサイジングの正確な仕様は、ServiceNow DocumentationのMID Server節で最終確認します
CIS-Discovery試験ではこう問われる
CIS-Discovery試験では、MID Serverは「概念の暗記」ではなく切り分けの判断として出題されます。たとえば「StatusがDownのとき最初に確認すべきものは」「未検証のMID Serverに起きることは」「探索対象のIPレンジに担当MID Serverがいない場合の挙動は」——本記事の4層と早見表は、そのままこの種の設問の判断軸になります。
当サイトのCIS-Discovery模試（全597問）には、MID Serverの接続・検証・ECC Queueまわりの切り分けを問う問題を、Discovery分類と実務パターン特訓に収録しています。解き終えると分類別の正答率と推定得点が出るので、この領域が弱点として残っていないかを数字で確認できます。
CIS-Discovery無料模試でMID Server領域の理解度を測る
間違えた問題は解説と分類別の弱点表示で復習できます。試験全体の学習順はCIS-Discovery対策ハブからどうぞ。
まとめ
- MID Serverの通信はMID側からの外向きHTTPS一方向。切り分けはこの前提から始まります。
- 確認場所はMID Server一覧（Status/Validated）・ECC Queue・agentログの3つ。
- 切り分けはホスト→経路→認証→検証と割り当ての4層を浅い順に。Downなら層①〜③、Upで動かないなら層④です。
- 予防はDown通知・複数台冗長化・変更カレンダー連動の3点。MID Server停止の実害は「CMDBの鮮度劣化」として現れます。
よくある質問
MID ServerのStatusがDownのとき、最初に何を確認すべきですか？
ホスト側でMID Serverのサービス（プロセス）が動いているかを最初に確認します。動いているのにDownなら、インスタンスへの外向きHTTPS経路（プロキシ・証明書・ファイアウォール）、次にMID Serverユーザーの認証状態（パスワード期限・ロック・mid_serverロール）の順で切り分けます。複数台が同時にDownした場合は、共通経路であるネットワーク・プロキシ側の変更を先に疑うのが近道です。
Not Validated（未検証）のままだと何が起きますか？
接続がUpでも、未検証のMID ServerにはDiscoveryなどの処理が割り当てられません。新規インストールや再インストールの後は、MID Serverレコードから検証（Validate）を実行し、Validatedになったことを確認してから使います。「Upになったので完了」と判断して検証を忘れるのが、初期構築で最も多いつまずきです。
ECC Queueでは何が分かりますか？
ECC Queueはインスタンスと MID Serverの仕事の受け渡し台帳です。インスタンスからの指示（output）とMID Serverからの結果（input）がレコードとして残るため、「指示が出ていない」「指示は出たが取りに来ていない（readyのまま滞留）」「実行したがエラーで返ってきた」のどれが起きているかを、レコードの向きと状態から判別できます。UpなのにDiscoveryが進まないときの切り分けに特に有効です。
関連記事・公式確認先
- ServiceNowのDiscoveryとは｜MID Server・CMDB・CSDMの役割整理と試験対策
- CIS-Discovery対策ハブ（学習順・模試の使い方）
- CIS-Discovery無料模試（全597問・分類別ドリル）
受験条件・試験範囲・製品仕様は変わる可能性があります。最終確認は必ず公式で行ってください。
