Active Directoryで複数のドメインコントローラーを運用している場合、レプリケーションが正常に行われているか確認したいことがあります。
そのときによく使用するコマンドが、
repadmin /replsummaryです。
実行するとドメインコントローラーごとに、
largest delta
fails/total
%%
errorなどが表示されます。
しかし、初めて見ると、
「Source DSAとDestination DSAは何が違う？」
「largest deltaが大きいと異常？」
「failsが0なら正常と判断していい？」
「1722や1256が表示されたらどうすればいい？」
など、結果の読み方が少し分かりにくいコマンドでもあります。
この記事では、repadmin /replsummaryの基本的な見方と、異常が見つかった場合の次の調査方法を説明します。
repadmin /replsummaryとは？
repadminは、Active Directoryのレプリケーション状態を確認・診断するためのコマンドです。
その中でも、
repadmin /replsummaryは、複数のドメインコントローラーのレプリケーション状況を一覧で確認したいときに便利です。
例えば、
DC01
DC02
DC03という3台のドメインコントローラーがある環境なら、
DC01 ←→ DC02
DC01 ←→ DC03
DC02 ←→ DC03といったレプリケーションの状態を大まかに確認できます。
そのため私は、
ADに何か問題がありそう
↓
repadmin /replsummary
↓
全体を見る
↓
異常なDCを見つける
↓
repadmin /showrepl
↓
詳細を調べるという使い方をします。
repadmin /replsummaryを実行する
ドメインコントローラーなどでコマンドプロンプトまたはPowerShellを開き、
repadmin /replsummaryを実行します。
例えば、次のような結果が表示されます。
Replication Summary Start Time: 2026-09-16 10:00:00
Beginning data collection for replication summary,
this may take awhile:
Source DSA largest delta fails/total %% error
DC01 05m:12s 0 / 10 0
DC02 04m:38s 0 / 10 0
DC03 05m:01s 0 / 10 0
Destination DSA largest delta fails/total %% error
DC01 05m:01s 0 / 10 0
DC02 05m:12s 0 / 10 0
DC03 04m:38s 0 / 10 0この場合は、
fails = 0なので、少なくともこの結果ではレプリケーション失敗は確認されていません。
Source DSAとは？
まず分かりにくいのが、
Source DSAです。
DSAは、
Directory System Agent
の略です。
ここでは大まかに、
レプリケーション元として見たDC
と考えると分かりやすいです。
例えば、
DC01
│
│ レプリケーション
▼
DC02なら、
Source
DC01です。
Source DSA側にエラーが表示されている場合は、
そのDCをレプリケーション元とする通信で問題が発生している
という視点で調査します。
Destination DSAとは？
一方、
Destination DSAは、
レプリケーション先として見たDC
です。
先ほどと同じ、
DC01
│
│ レプリケーション
▼
DC02なら、
Destination
DC02です。
したがってreplsummaryでは、
Source DSA
↓
「送る側」の観点
Destination DSA
↓
「受ける側」の観点という2方向からレプリケーション状況を見ることができます。
厳密な失敗箇所を特定するときは、この一覧だけで決めつけず、後述するrepadmin /showreplで詳細を確認します。
largest deltaとは？
次に重要なのが、
largest deltaです。
これは簡単にいうと、最後に成功したレプリケーションから経過している時間のうち、最も大きいものを見るための項目です。
例えば、
largest delta
05m:12sなら、約5分です。
一方、
largest delta
02h:35m:10sのように長くなっていたら、
「このDCでは長時間レプリケーションに成功していない接続があるのでは？」
と確認する材料になります。
largest deltaが大きい＝障害とは限らない
ここは注意が必要です。
例えば、
largest delta = 2時間だからといって、
AD障害と即断することはできません。
Active Directoryでは、
同一サイト
別サイト
サイトリンク
レプリケーションスケジュール
DCの停止
ネットワーク構成などによって、期待されるレプリケーション間隔が異なることがあります。
そのため、
largest deltaの数字そのものではなく、その環境で想定される時間と比較する
ことが重要です。
fails/totalを見る
障害調査で非常に分かりやすいのが、
fails/totalです。
例えば、
0 / 10なら、
10回中
失敗0です。
一方、
4 / 10なら、
10回中
4回失敗しています。
したがって、
fails/total
0 / xxなら問題がない可能性が高く、
fails/total
x / xxのように左側が0以外なら、詳しく調査します。
%%は失敗率
例えば、
fails/total %%
4 / 10 40なら、
40%が失敗
しています。
つまり、
fails/total
↓
失敗回数を見る
%%
↓
失敗率を見ると考えると分かりやすいです。
ただし、失敗率だけで障害の重大度を判断しない方がよいでしょう。
例えば、
1 / 100と、
1 / 1では、同じ1回失敗でも状況が違います。
error欄は必ず確認する
レプリケーションに失敗している場合、
error欄にエラー番号が表示されることがあります。
例えば、
1722です。
Windowsでは、
1722 (0x6ba)
The RPC server is unavailable.
RPC サーバーを利用できません。というエラーです。
この場合、
RPCサービス
DNS
ネットワーク
Firewall
RPC Endpoint Mapper
RPC動的ポートなどを調査します。
前回の記事、
「Active Directoryで『RPCサーバーを利用できません（1722）』が出たときの原因と確認方法」
も参考にしてください。
1256が出る場合もある
Active Directoryのレプリケーション調査では、
1256が表示されることもあります。
例えば、
1256 (0x4e8)
The remote system is not available.などです。
ここで重要なのは、1256だけを単独で原因と決めつけないことです。
同じDCに対する別のレプリケーションで、
1722など、より直接的な通信エラーが発生していないか確認します。
つまり、
1256発見
↓
1256だけ調査ではなく、
1256発見
↓
同じDCのほかのエラーを見る
↓
repadmin /showrepl
↓
最初に発生している失敗を確認という調査をします。
正常時は何を見ればいい？
私なら最低限、
fails/totalと、
largest deltaを見ます。
例えば、
Source DSA largest delta fails/total
DC01 05m:12s 0 / 10
DC02 04m:38s 0 / 10
DC03 05m:01s 0 / 10なら、
失敗
↓
0
最後の成功からの時間
↓
想定範囲なので、少なくともreplsummary上は大きな問題は見えていません。
異常時の例
例えば、
Source DSA largest delta fails/total %% error
DC01 05m:12s 0 / 10 0
DC02 04m:38s 0 / 10 0
DC03 08h:35m 5 / 10 50 1722だったとします。
明らかに、
DC03だけ違います。
DC01 → 正常
DC02 → 正常
DC03
↓
largest delta 8時間
fails 5
error 1722なので、次はDC03を中心に調査します。
ここでいきなりDC03を再起動するのではなく、
repadmin /showrepl DC03へ進みます。
replsummaryは「異常なDCを探す」ために使う
この考え方が重要です。
repadmin /replsummaryだけで、すべての原因を特定しようとしません。
役割としては、
repadmin /replsummary
↓
全体を俯瞰
↓
怪しいDCを見つけるです。
その後、
repadmin /showreplで詳細を確認します。
イメージとしては、
Active Directory
│
▼
repadmin /replsummary
│
┌──────────┼──────────┐
▼ ▼ ▼
DC01 DC02 DC03
OK OK ERROR
│
▼
repadmin /showrepl DC03
│
▼
詳細な原因調査
という使い方です。
repadmin /showreplで詳細を見る
異常なDCが見つかったら、
repadmin /showrepl DC03を実行します。
ここでは、
どのDCから受信しているか
最後に成功した時刻
最後に試行した時刻
連続失敗回数
エラーコードなどを確認できます。
例えば、
Last attempt @ 2026-09-16 10:30:00 failed,
result 1722 (0x6ba):
The RPC server is unavailable.なら、より具体的な調査へ進めます。
repadmin /showrepl * /csvも便利
DCが多い環境では、一台ずつ、
repadmin /showrepl DC01
repadmin /showrepl DC02
repadmin /showrepl DC03と確認するのは大変です。
その場合、
repadmin /showrepl * /csvを利用できます。
CSV形式で出力できるため、
repadmin /showrepl * /csv > repl.csvとして保存し、Excelなどで確認できます。
DCが多数ある環境では、
Source
Destination
Last Success
Last Failure
Failure Count
Errorなどを一覧化すると、異常なDCを見つけやすくなります。
repadmin /syncallはすぐ実行しない
レプリケーションエラーを見ると、
repadmin /syncallで強制的に同期したくなるかもしれません。
しかし私は、原因調査前にいきなり強制同期することはおすすめしません。
例えば、
DNSがおかしい
↓
RPC通信できない
↓
1722という状態なら、強制同期しても根本原因は解決しません。
まず、
replsummary
↓
showrepl
↓
DNS
↓
ネットワーク
↓
RPC
↓
原因特定という順番で確認します。
DCを停止している場合は注意
計画停止などでDCを停止している場合、
repadmin /replsummaryにエラーが表示されることがあります。
これは当然です。
例えば、
DC03
↓
停止中なのに、
DC01
↓
DC03へ通信しようとしても成功しません。
そのため、
1722が出たという事実だけで、
ADが壊れた
とは判断できません。
重要なのは、
「その時点で相手DCが利用可能な状態だったか」
です。
DC復旧後もエラーが残る場合
停止していたDCを起動したあとも、
largest deltaが大きかったり、
failsが残っている場合があります。
その場合は少し待って再度、
repadmin /replsummaryを実行します。
さらに、
repadmin /showrepl DC03で、
新しいレプリケーションが成功しているか
を確認します。
単に過去の失敗が表示されているのか、現在も失敗し続けているのかを区別することが重要です。
RODCがある環境でも使える
Read-Only Domain Controller（RODC）がある環境でも、レプリケーション確認にrepadminは有効です。
ただしRODCは通常の書き込み可能DCとは役割が異なるため、
Writable DC
↓
RODCというレプリケーションの方向なども意識して結果を確認します。
例えばRODCで問題が見つかった場合、
RODC
↓
どのWritable DCから
レプリケーションしている？
↓
その接続だけ失敗？
↓
複数RODCで同じ症状？という比較も有効です。
DCが多い環境では「共通点」を探す
例えばDCが多数存在していて、
DC01 OK
DC02 OK
DC03 OK
RODC01 ERROR
RODC02 ERROR
RODC03 ERRORとなっていたとします。
この場合、一台ずつ壊れたと考えるより、
同じ拠点？
同じネットワーク？
同じサイト？
同じ接続元DC？
同じ時間から発生？などの共通点を探します。
これはActive Directoryに限らず、障害調査で非常に有効です。
定期確認にも使える
repadmin /replsummaryは障害発生時だけでなく、定期的な確認にも利用できます。
例えば正常時の結果を保存しておけば、
正常時
largest delta
5～15分程度
fails
0だったものが、
障害時
largest delta
6時間
fails
8となった場合、変化がすぐ分かります。
つまり、
正常な状態を知っておくこと
も重要です。
結果をファイルへ保存する
障害調査では、コマンド結果を残しておくことをおすすめします。
例えば、
repadmin /replsummary > replsummary.txtです。
日時もファイル名へ入れて、
replsummary_20260916_1030.txtなどとしておけば、
障害発生時
↓
設定変更
↓
復旧後を比較できます。
「直った」で終わらず、何が変化したのか確認できるようになります。
私ならこの順番で確認する
ADレプリケーションに問題がありそうな場合は、
ADがおかしい？
↓
repadmin /replsummary
↓
failsは0？
┌──┴──┐
YES NO
│ │
│ ▼
│ 異常なDC特定
│ ↓
│ largest delta確認
│ ↓
│ error確認
│ ↓
│ repadmin /showrepl
│ ↓
│ DNS / RPC / NW等を調査
│
▼
大きな異常は
見えていないという流れにします。
repadminが正常ならADは完全に正常？
これも注意が必要です。
repadmin /replsummary
↓
fails = 0だからといって、Active Directory全体に問題がないことを保証するものではありません。
例えば、
DNS
SYSVOL
DFSR
Kerberos
Netlogon
GPO
時刻同期などは別途問題が発生する可能性があります。
したがって、
repadmin /replsummaryは正常
という結果は、
「少なくとも確認したADレプリケーションでは大きな失敗が見えていない」
と捉える方が安全です。
まとめ
Active Directoryのレプリケーション状態を確認するとき、
repadmin /replsummaryは非常に便利です。
まず見るのは、
largest delta
fails/total
%%
errorです。
特に、
fails/total
0 / xxならレプリケーション失敗は確認されていません。
一方、
fails/total
5 / 10
error
1722などが表示されていれば、次に、
repadmin /showrepl 対象DCで詳細を確認します。
考え方としては、
replsummary
↓
全体を見る
↓
異常なDCを発見
↓
showrepl
↓
どのレプリケーションが失敗？
↓
DNS / RPC / NW / DC等を調査です。
repadmin /replsummaryだけで原因を特定しようとするのではなく、
「どこを詳しく調べるべきかを見つけるコマンド」
として使うと、Active Directoryのトラブルを切り分けやすくなります。
関連記事
１．ADレプリケーション全体の確認方法については「repadmin /replsummaryの見方」
コメント