Active Directoryのレプリケーション障害を調査するとき、最初に
repadmin /replsummaryを実行すると、ドメインコントローラー全体のレプリケーション状態を確認できます。
しかし、replsummaryで分かるのは主に、
「どのDCでレプリケーションエラーが発生しているか」
という全体像です。
実際に、
どのDCとのレプリケーションが失敗しているのか
最後に成功したのはいつか
何回連続で失敗しているのか
どんなエラーが発生しているのか
まで調べたい場合は、
repadmin /showreplを使用します。
この記事では、repadmin /showreplの結果の見方と、エラーが見つかった場合の切り分け方法を紹介します。
repadmin /showreplとは？
repadmin /showreplは、ドメインコントローラーがどのレプリケーションパートナーからActive Directory情報を受信しているかと、その受信レプリケーションの状態を確認するコマンドです。
例えば、
DC01
↓
DC02
↓
DC03という単純な順番を見るものではありません。
Active DirectoryではNaming Context（ディレクトリパーティション）ごとにレプリケーションが行われます。
そのためshowreplでは、
DC=example,DC=local
CN=Configuration,DC=example,DC=local
CN=Schema,CN=Configuration,DC=example,DC=local
DC=DomainDnsZones,DC=example,DC=local
DC=ForestDnsZones,DC=example,DC=localなどについて、レプリケーション状況が表示されます。
まずrepadmin /replsummaryで全体を見る
いきなりshowreplを見るより、最初に、
repadmin /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だったとします。
この結果から、
DC01 → 大きな異常なし
DC02 → 大きな異常なし
DC03
↓
失敗あり
↓
1722ということが分かります。
そこで次に、
repadmin /showrepl DC03を実行してDC03を詳しく調査します。
つまり、
replsummary
↓
全体から異常なDCを探す
↓
showrepl
↓
そのDCを詳しく調べるという使い分けです。
repadmin /showreplを実行する
対象DCで、
repadmin /showreplを実行します。
別のDCから対象DCを指定する場合は、
repadmin /showrepl DC03のように実行できます。
実際の出力は環境によって異なりますが、例えば次のような情報が表示されます。
DC=example,DC=local
Site-A\DC01 via RPC
DSA object GUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Last attempt @ 2026-09-16 10:30:00 was successful.エラーが発生している場合は、
Last attempt @ 2026-09-16 10:30:00 failed,
result 1722 (0x6ba):
The RPC server is unavailable.などと表示されます。
ここから詳しく見ていきます。
最初に「どのDCを見ているか」を確認する
showreplの結果を見るとき、最初に確認したいのが、
どのDCの受信レプリケーションを表示しているのか
です。
例えばDC03を指定して、
repadmin /showrepl DC03を実行したのであれば、基本的には、
DC01
│
│ Active Directory情報
▼
DC03というDC03側から見た受信レプリケーションを調べています。
ここを理解していないと、
「DC01が悪いのか、DC03が悪いのか」
を取り違えやすくなります。
Naming Contextを見る
showreplでは、最初に、
DC=example,DC=localなどが表示されます。
これはNaming Context（NC）と呼ばれるもので、Active Directoryでレプリケーションされる領域を表します。
代表的なものとして、
DC=example,DC=localはドメインパーティションです。
また、
CN=Configuration,DC=example,DC=localはConfigurationパーティション、
CN=Schema,CN=Configuration,DC=example,DC=localはSchemaパーティションです。
DNS統合ゾーンを使用している場合は、
DC=DomainDnsZones,DC=example,DC=local
DC=ForestDnsZones,DC=example,DC=localなども表示されます。
ここで重要なのは、
一部のNaming Contextだけ失敗しているのか、複数がまとめて失敗しているのか
を見ることです。
レプリケーション元DCを確認する
例えば、
Site-A\DC01 via RPCと表示されていれば、DC01がレプリケーションパートナーです。
イメージとしては、
DC01
│
│ レプリケーション
▼
DC03です。
DC03のshowreplを見ていて、
Site-A\DC01 via RPCの下にエラーが表示されているなら、
DC03がDC01から情報を受信するレプリケーションで失敗している
と考えます。
これだけでもreplsummaryよりかなり具体的になります。
Last attemptを見る
非常に重要なのが、
Last attemptです。
例えば、
Last attempt @ 2026-09-16 10:30:00 was successful.なら、
10時30分のレプリケーション試行は成功
しています。
一方、
Last attempt @ 2026-09-16 10:30:00 failed,
result 1722 (0x6ba):
The RPC server is unavailable.なら、
10時30分の試行は失敗
しています。
つまり、
Last attempt
↓
一番最近のレプリケーション試行結果を見る項目です。
「現在も失敗しているか」を確認する
ここは障害調査で重要です。
例えば、過去にDCが停止していたとします。
09:00
DC01停止
↓
レプリケーション失敗
10:00
DC01起動
10:15
レプリケーション成功この場合、過去にエラーがあったとしても、現在は復旧している可能性があります。
したがって、
エラーが一度あった
だけでなく、
直近のレプリケーションが成功しているか
を確認します。
Last successを見る
環境や出力内容によって確認方法は異なりますが、障害調査では最後に正常なレプリケーションが成功した時刻が非常に重要です。
例えば、
Last Success
2026-09-16 10:15だったとします。
現在が10:30なら、
15分前まで正常です。
一方、
Last Success
2026-09-10 03:15なら、
約6日間
正常レプリケーションなしということになります。
同じ1722でも、
数分前から1722と、
数日間1722では状況が大きく違います。
連続失敗回数を見る
レプリケーションが失敗し続けている場合は、連続した失敗回数にも注目します。
例えば、
5 consecutive failure(s).なら、
5回連続で失敗
しています。
考え方としては、
1回だけ失敗
↓
一時的な通信障害の可能性もある
数十回連続失敗
↓
継続的な問題を疑うとなります。
ただし、回数だけで原因は判断できません。
重要なのは、
最後の成功時刻
+
連続失敗回数
+
エラーコードを組み合わせて見ることです。
resultのエラーコードを見る
失敗している場合、例えば、
result 1722 (0x6ba):
The RPC server is unavailable.のような結果が表示されます。
ここで重要なのが、
1722というエラー番号です。
日本語環境では、
RPC サーバーを利用できません。などと表示されます。
この場合は、
DNS
ネットワーク
TCP/135
RPC動的ポート
Firewall / ACL
対象DCの状態などを調査します。
詳しい切り分けについては、関連記事、
「Active Directoryで『RPCサーバーを利用できません（1722）』が出たときの原因と確認方法」
も参考にしてください。
1722以外のエラーもある
showreplで表示されるエラーは1722だけではありません。
例えば、
1256など、別のエラーが表示されることがあります。
ここで大切なのは、
エラー番号だけを見て原因を決めない
ことです。
例えば同じDCについて、
Domain NC
↓
1722
Configuration
↓
1256
Schema
↓
1256のようになっていた場合、1256だけを個別に追いかけるより、最初に発生している通信障害との関係を調べた方がよい場合があります。
「どこからどこへ」を整理する
showreplの結果が長い場合は、私は次のように整理します。
確認対象
DC03
レプリケーション元
DC01
Naming Context
DC=example,DC=local
最後の試行
失敗
エラー
1722
最後の成功
8時間前
連続失敗
5回これだけ整理すると、
DC01
│
│ RPCレプリケーション
│ ×
▼
DC03という調査対象が見えてきます。
この状態になって初めて、
DC01は起動している？
DNSでDC01を正しく引ける？
DC03→DC01のTCP/135は通る？
Firewallは？と具体的な通信確認へ進めます。
DNSを確認する
Active Directoryのレプリケーション障害ではDNS確認が重要です。
例えばDC03から、
nslookup DC01を実行します。
FQDNでも、
nslookup DC01.example.localを確認します。
期待したIPアドレスが返るか確認します。
さらにAD用のSRVレコードについて、
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.localなども確認できます。
単純に、
ping DC01が成功しただけでDNSやAD通信全体が正常とは判断しません。
RPCのTCP/135を確認する
1722などRPC関連のエラーなら、PowerShellから、
Test-NetConnection DC01 -Port 135を実行できます。
正常なら、
TcpTestSucceeded : Trueとなります。
失敗なら、
TcpTestSucceeded : Falseです。
ただし、RPCではTCP/135だけでなく動的RPCポートも使用されるため、
135番が成功＝RPCレプリケーションが完全に正常
ではありません。
showreplの結果とイベントログの時刻を合わせる
原因が分からない場合は、イベントビューアーも確認します。
例えばshowreplで、
Last attempt
2026-09-16 10:30に失敗していたなら、イベントログでも、
10:25～10:35付近を重点的に確認します。
特に、
Directory Service
System
DNS Server
DFS Replicationなどを確認します。
こうすると、
10:30 repadmin失敗
↓
10:30 DNS関連エラー
↓
10:30 ネットワークエラーなど、関連するイベントが見つかることがあります。
全DCを確認したい場合
DCが複数ある場合、
repadmin /showrepl *で複数DCの情報を確認できます。
さらにCSV形式なら、
repadmin /showrepl * /csvです。
ファイルへ保存するなら、
repadmin /showrepl * /csv > showrepl.csvとできます。
DCが多い環境では、CSVにしてExcelで、
Source DSA
Destination DSA
Last Success Time
Number of Failures
Last Failure Statusなどを確認すると便利です。
DCが多い場合は1台ずつ追わない
例えば多数のRODCがある環境で、
RODC01 → 1722
RODC02 → 1722
RODC03 → 正常
RODC04 → 1722となっていたとします。
一台ずつ、
RODC01が壊れた？
RODC02も壊れた？
RODC04も壊れた？と考えるより、
同じ拠点か？
同じネットワーク経路か？
同じADサイトか？
同じレプリケーション元か？
同じ時間から発生したか？という共通点を探す方が原因へ早く近づける場合があります。
手動レプリケーションで確認する方法
原因を修正したあと、レプリケーションが正常になったか確認したい場合があります。
Active Directory Sites and Servicesなどからレプリケーションを実行する方法もあります。
repadminにも同期関連のコマンドがありますが、本番環境では、
エラーが出ているから、とりあえず強制同期する
という使い方は避けた方が安全です。
まず、
原因調査
↓
原因修正
↓
レプリケーション実行
↓
showreplで確認という順番にします。
復旧したか確認する
原因を修正したら、もう一度、
repadmin /showrepl DC03を実行します。
例えば、
Last attempt @ 2026-09-16 11:30:00 was successful.となれば、直近のレプリケーションは成功しています。
さらに、
repadmin /replsummaryも実行します。
つまり、
showrepl
↓
個別の通信が復旧した？
replsummary
↓
全体として失敗が残っていない？という2段階で確認します。
replsummaryとshowreplの違い
この2つはセットで覚えると分かりやすいです。
| コマンド | 主な目的 |
|---|---|
repadmin /replsummary | ADレプリケーション全体を確認 |
repadmin /showrepl | 特定DCの受信レプリケーションを詳しく確認 |
イメージとしては、
Active Directoryで問題発生
↓
repadmin /replsummary
↓
「DC03がおかしい」
↓
repadmin /showrepl DC03
↓
「DC01からDC03への受信で1722」
↓
DNS / RPC / Networkを調査です。
この使い分けが分かるだけでも、ADレプリケーション障害の調査がかなりしやすくなります。
showreplが正常ならSYSVOLも正常？
ここは注意が必要です。
repadmin /showrepl
↓
成功だからといって、
SYSVOLも正常とは限りません。
repadminで確認しているActive Directoryのレプリケーションと、現在のWindows ServerでSYSVOLに使われるDFSRのレプリケーションは分けて考える必要があります。
例えば、
ADレプリケーション
↓
正常
SYSVOL / DFSR
↓
異常ということもあり得ます。
GPOが反映されない場合などは、
\\DC01\SYSVOL
\\DC02\SYSVOLの内容や、DFSRの状態も別途確認します。
これは次の記事で詳しく扱います。
私ならこの順番で調査する
Active Directoryのレプリケーション障害なら、次のように進めます。
ADレプリケーションがおかしい
↓
repadmin /replsummary
↓
異常なDCを特定
↓
repadmin /showrepl 対象DC
↓
どのレプリケーション元？
↓
どのNaming Context？
↓
Last attempt
↓
最後の成功時刻
↓
連続失敗回数
↓
エラーコード
↓
DNS / Network / RPC等を調査
↓
原因修正
↓
showreplで再確認
↓
replsummaryで全体確認重要なのは、
エラー番号を見る前に「どこからどこへのレプリケーションなのか」を把握する
ことです。
まとめ
Active Directoryのレプリケーションエラーを調査するとき、
repadmin /showreplは非常に便利なコマンドです。
特に確認したいのは、
確認対象DC
レプリケーション元DC
Naming Context
Last attempt
最後の成功時刻
連続失敗回数
エラーコードです。
最初に、
repadmin /replsummaryで全体を確認し、
どのDCがおかしい？を見つけます。
次に、
repadmin /showrepl 対象DCで、
誰から
↓
何を
↓
いつから
↓
何のエラーで
↓
受信できていない？まで掘り下げます。
例えば1722が確認されたら、その時点でDNS、RPC、ネットワーク、ファイアウォールなどの調査へ進みます。
repadmin /showreplは、
「ADレプリケーションが失敗している」という漠然とした状態を、「DC01からDC03へのレプリケーションが1722で失敗している」という具体的な状態へ変える
ためのコマンドと考えると分かりやすいでしょう。
関連記事
１．ADレプリケーション全体の確認方法については「repadmin /replsummaryの見方」
コメント