「dcdiagでエラーが出る。でも、ユーザーは普通にログインできている」。この状態で、最後に出た「合格しました」だけを見て点検を終えると、途中にある失敗を見落とします。
dcdiagの合格は、そこに書かれたテストの合格です。ドメイン全体への合格証ではありません。 一方、失敗行があっても、過去のイベントを拾った結果なのか、現在も通信や複製に失敗しているのかで、次に調べるものは変わります。
この記事は、無料動画「ドメインコントローラー正常性確認方法」と、メンバー限定の診断・複製の解説を素材に、結果の読み方を整理したものです。コマンドの仕様は2026年10月15日時点のMicrosoft Learnで確認しました。まずは設定を変えず、どのDCの、どのテストが、いつの何を見て失敗したかをつかみます。
最後の「合格」までスクロールして終わらない
管理対象のドメインコントローラー（DC）で、管理者として開いたコマンドプロンプトから次を実行します。
dcdiag /v/vは詳細表示です。出力のテスト名と、それに続く合格・失敗を一組ずつ読みます。対象DCの名前も確認してください。1台で良い結果が出ても、別のDCを点検したことにはなりません。
無料動画の37秒からは、最後の合格行だけでは判断できない理由を説明しています。1分39秒からには、途中にあるDFSR関連の失敗が登場します。どのテストの下に警告が出ているかは、この出力画面で追うと分かりやすくなります。
公式リファレンス「DCDiag」で、オプションと各テストの意味を確認できます。dcdiag /vを実行しても、すべての種類のテストが走るわけではありません。たとえばDNSテストは明示的な指定が必要です。DNSの確認に進むときは、ADがDNSでDCを探す仕組みも押さえると、名前解決を調べる理由がつながります。
repadminが成功しても、SYSVOLまで正常とは言えない
無料動画では、dcdiagでDFSR関連の失敗が見つかった後、4分23秒からの複製確認では成功が並びます。矛盾して見えるのは、別の仕組みを見ているからです。
ADのユーザーやグループなどのディレクトリ情報をDC間で渡す複製と、グループポリシーのファイルなどを置くSYSVOLの複製は、分けて確認します。現在のSYSVOLの複製を担うのはDFSRです。repadminの良い結果を、SYSVOLのファイルもそろっている証拠として使わないことが大切です。
メンバー限定の「SYSVOLとDFSR」の3分1秒からは、SYSVOLに置かれたファイルとグループポリシーの関係を、5分10秒からはファイルを複製する仕組みを説明します。ディレクトリ情報だけでは見えないファイルの側を、実際の共有と管理画面で確かめられます。未参加の場合はリンク先にメンバーシップの案内が出ます。
たとえば「ユーザーの変更は別のDCでも見えるが、ポリシーの動きがおかしい」なら、ADの複製結果だけで点検を終える理由はありません。症状を記録し、SYSVOL側のイベントや共有へのアクセスも調べる対象にします。
DFSREventの失敗には「いつ」を添える
ここで動画の説明に、仕様上の注意を足しておきます。DCDiagのDFSREventは、過去24時間のDFSRイベントログにある警告・エラーを調べます。失敗したという結果だけで、今この瞬間も複製が停止していると断定できません。
確認するのは、イベントID、発生時刻、メッセージ、関係する相手、その後にも同じ問題が出ているかです。直前のメンテナンス中に出たイベントなのか、現在も繰り返しているのかを区別します。過去のものだったとしても、原因と復旧を確認せず無視してよいわけではありません。
またSysVolCheckの合格はSYSVOLが準備済みであることの確認であり、共有へのアクセス確認の代わりにはなりません。テスト名が似ていても、確認範囲は違います。これらの定義は、公式「DCDiagの既知のテスト」で確認できます。
このため、点検メモを「DFSRが壊れている」だけで終わらせず、「DC02のDFSREventが失敗。イベントは何時、どの相手、どんな内容。その後の状態はどうか」と書くと、次の調査につながります。
ADの複製は「受け取るDC・相手・情報の区画」で読む
ディレクトリ情報の複製を見る入口は、次のコマンドです。
repadmin /showrepl出力では、対象DCがどの相手から情報を受け取るか、その情報の区画（名前付けコンテキスト／ディレクトリパーティション）、直近の試行結果を組にして読みます。ドメインの情報、構成、スキーマなどで行が分かれるため、成功行が1つあるだけでは確認を終えられません。
メンバー限定の「診断コマンド16選」の5分48秒からはrepadminの表示を、6分34秒からは受信方向の相手・パーティション・複製時刻の読み方を説明しています。自分の出力と比較するときは、この行の並びを画面で見てください。未参加の場合はリンク先にメンバーシップの案内が出ます。
複数DCを一覧として確認する方法は、Microsoftの「Diagnose Active Directory replication failures」にあります。
repadmin /showrepl * /csv > showrepl.csvこれは全体を確認する権限のある管理者向けです。単一DCの結果を全DCの結果として扱わず、対象を広げた場合も、取得できたDCと行を確認します。CSVでは、受け取る側と送信元、最後の成功時刻、失敗時刻・状態を追います。成功したという文字と、成功した時刻を一緒に読むのがポイントです。
「変更が見えない」は、同じDCを見ているかから
ユーザーやグループを変更したのに別の管理画面に反映されないときは、両方の画面がどのDCに接続しているかを確認します。意図した複製範囲やサイト間のスケジュールも関係するため、反映がすぐでないことだけでは障害と決められません。
メンバー限定の「複製ロジック」では、2分49秒から、管理ツールの接続先DCを確かめる操作を見られます。5分34秒からは、別サイトへ移したDCとサイトリンクの間隔を確認する場面です。動画内の「60分」は、その検証環境の設定値です。すべてのAD環境で60分待てばよい、という意味ではありません。画面で設定と反映を往復して見ると、待ち時間を症状だけで判断できない理由が分かります。
ADの複製障害がDCごとの不一致を生み、接続したDCによって結果が変わり得ることは、公式「Troubleshooting Active Directory Replication Problems」でも説明されています。
なお、複製ロジックの動画の6分33秒からでは、想定より早くグループが反映され、著者自身がその結果を確認しています。設定した間隔だけで一回の観測結果を説明し切らず、接続先と実際の複製時刻を合わせて見る、という教材として読んでください。
エラーを消す前に、調べる対象を絞る
ここまでで失敗が続いていると分かったら、イベントとrepadminのエラーを手がかりに進みます。Microsoftの「Active Directory replication troubleshooting guidance」は、計画的な切断や機器故障を確認したうえで、DNS、通信、認証、複製の構成などを調べる順序を示しています。
名前解決や通信が疑わしいときも、「pingが通ったから正常」で止めないでください。ping成功と必要なTCP接続の違いを踏まえ、失敗した通信の相手と経路を確認します。ただしADの複製は複数のポートやRPCを使うため、TCPポート1つへの接続成功だけで複製全体を検証したことにはなりません。
担当者へ渡す情報は、対象DC、取得日時、失敗したテスト名、複製相手とパーティション、最後の成功・失敗時刻、エラーとイベントの内容です。修正後は同じ対象を再確認し、元の症状も戻ったかを確かめます。
最初から強制同期やDCの再構築を選ぶと、原因を確かめる前に状態を変えてしまいます。この記事で紹介した出力の読み方を使い、合格した範囲、失敗した範囲、まだ確かめていない範囲を言える状態にする。それが「なんとなく動いているAD」の点検から抜け出す最初の一歩です。
