Active Directoryのドメインコントローラー間でレプリケーション状態を確認したところ、次のようなエラーが発生することがあります。
1722 (0x6ba):
The RPC server is unavailable.
RPC サーバーを利用できません。例えばrepadmin /replsummaryやrepadmin /showreplを実行したときに、1722が表示されるケースです。
「RPCサーバー」と表示されるためRPCサービスだけを疑いたくなりますが、Active Directoryでは、
DNS
ネットワーク
RPC
ファイアウォール
ドメインコントローラー
ADサイト
レプリケーションなど複数の要因が関係します。
そのため、いきなりサービスの再起動や設定変更をするのではなく、どのDC間で、どの通信が失敗しているのかを順番に切り分けることが重要です。
この記事では、ADレプリケーションでRPC 1722が発生した場合の確認方法を紹介します。
まずレプリケーション全体の状態を確認する
最初に実行したいのが、
repadmin /replsummaryです。
このコマンドで、ドメインコントローラー間のレプリケーション状況を一覧で確認できます。
正常なら失敗数は0になりますが、問題があると、
fails
largest delta
errorなどに異常が現れます。
例えば、
Source DSA largest delta fails/total
DC01 00h:05m 0 / 10
DC02 05h:32m 4 / 10
DC03 05h:32m 4 / 10のようになっていれば、どのDCでレプリケーションが滞っているのかを確認できます。
ここで重要なのは、
1722が出たからDC全体が壊れている
と考えないことです。
まず、
どのDCから
↓
どのDCへの
↓
レプリケーションが
失敗しているのかを特定します。
1. repadmin /showreplで詳細を確認する
次に、
repadmin /showreplを実行します。
特定のDCを確認する場合は、
repadmin /showrepl DC01のように指定できます。
ここでは、
Last attempt
Last success
Consecutive failures
Resultなどを確認します。
1722の場合は例えば、
Last attempt @ 2026-09-16 10:00:00 failed,
result 1722 (0x6ba):
The RPC server is unavailable.のように表示されます。
特に重要なのが、
最後に正常レプリケーションできた時刻
です。
昨日までは正常
↓
今日から1722なのか、
数週間前から失敗なのかで調査対象が変わってきます。
2. 相手DCが起動しているか確認する
基本的ですが、まず対象となるドメインコントローラーが稼働しているか確認します。
例えば、
ping DC02です。
ただし、
ping成功だけで、
AD通信正常とは判断できません。
pingで確認できるのは基本的にICMP通信です。
Active DirectoryのレプリケーションではRPCなど別の通信を使用します。
そのため、
ping成功
↓
ネットワークは全部正常とは考えないようにします。
pingはあくまで最初の疎通確認です。
3. DNS名前解決を確認する
Active DirectoryでRPC 1722が発生した場合、DNSは非常に重要な確認項目です。
例えば、
nslookup DC02を実行します。
期待したIPアドレスが返るか確認します。
さらにFQDNでも、
nslookup DC02.example.localのように確認します。
ここで、
名前解決できない
違うIPが返る
古いIPが登録されているなどがあれば、ADレプリケーションに影響する可能性があります。
Active DirectoryはDNSへの依存度が高いため、
RPC 1722だからRPCだけを見る
のではなく、DNSを早い段階で確認します。
4. DC自身が参照しているDNSサーバーを確認する
次に、
ipconfig /allを実行します。
特に、
DNS Serversを確認します。
ドメインコントローラーが意図したAD DNSサーバーを参照しているか確認します。
例えば、
DC01
DNS1 → DC02
DNS2 → DC01など、組織で設計したDNS設定になっているか確認します。
意図しない外部DNSや古いDNSサーバーが設定されていれば注意が必要です。
5. AD用DNSレコードを確認する
単純なAレコードだけではなく、Active Directoryが利用するSRVレコードも確認します。
例えば、
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.localです。
正常なら、ドメインコントローラーが返ってきます。
イメージとしては、
_ldap._tcp.dc._msdcs.example.local
↓
DC01
DC02
DC03です。
ここに存在すべきDCが表示されない場合は、DNS登録にも調査範囲を広げます。
必要に応じて、
ipconfig /registerdnsやNetlogon関連の状態も確認します。
ただし、原因が分からない状態でむやみにDNSレコードを削除・再登録するのは避けた方がよいでしょう。
まず現在の状態を記録してから変更します。
6. RPC Endpoint Mapperの135番ポートを確認する
RPCではTCP 135番ポートが重要です。
PowerShellなら、
Test-NetConnection DC02 -Port 135を実行できます。
例えば、
ComputerName : DC02
RemotePort : 135
TcpTestSucceeded : Trueなら、少なくとも対象DCのTCP/135へ接続できています。
一方、
TcpTestSucceeded : Falseなら、
ネットワーク
ファイアウォール
対象DC
RPC関連サービスなどを調査します。
ただし、ここでも注意があります。
135番が通ればRPC通信がすべて正常というわけではありません。
RPCではEndpoint Mapperで接続先を確認したあと、動的ポートが使用されるためです。
7. RPCの動的ポートにも注意する
Windows ServerのRPC通信では、TCP/135だけで通信が完結するとは限りません。
大まかには、
DC01
│
│ TCP 135
▼
DC02
RPC Endpoint Mapper
│
│ 使用するRPCポートを確認
▼
動的RPCポート
│
▼
実際の通信という流れになります。
そのため、
TCP 135 → OK
でも
ADレプリケーション → 1722ということがあります。
ネットワーク途中のファイアウォールやACLが存在する環境では、RPCの動的ポート範囲が許可されているかも確認対象になります。
8. 必要なAD通信が遮断されていないか確認する
Active DirectoryではRPC以外にも複数の通信を使用します。
代表的には、
DNS
Kerberos
LDAP
SMB
RPC
Global Catalogなどです。
したがって、
ping OK
TCP/135 OKだけではAD全体の通信が正常とは判断できません。
例えばネットワーク構成が、
DC01
↓
L3スイッチ
↓
ファイアウォール
↓
拠点WAN
↓
DC02のようになっている場合、途中のACLやファイアウォールポリシーも確認します。
特に、
最近ネットワーク設定を変更していないか
は重要です。
9. RPC関連サービスを確認する
対象DCでサービスの状態も確認します。
特に、
Remote Procedure Call (RPC)
RPC Endpoint Mapper
DCOM Server Process Launcher
Netlogon
Active Directory Domain Services
DNS Serverなどです。
services.mscから確認できます。
ただし、Windowsの重要サービスを原因確認なしに停止・再起動するのはおすすめしません。
特にドメインコントローラーでは影響が大きいため、
サービス停止している？
↓
原因確認
↓
影響範囲確認
↓
必要なら対応という順番にします。
10. dcdiagでDC全体を確認する
Active Directoryの診断には、
dcdiagが利用できます。
より詳しく確認するなら、
dcdiag /vです。
DNSを重点的に確認する場合は、
dcdiag /test:dns /vも有効です。
出力はかなり長くなるので、
failed
error
warningなどを確認します。
ただし、警告が一つ表示されたからといって、それがRPC 1722の直接原因とは限りません。
repadminの結果と組み合わせて判断することが重要です。
11. nltestでDCを発見できるか確認する
例えば、
nltest /dsgetdc:example.localを実行します。
正常なら利用可能なドメインコントローラーの情報が返ります。
また、セキュアチャネルの確認では環境に応じて、
nltest /sc_verify:example.localなども利用できます。
ここでエラーになる場合は、
DNS
Netlogon
ドメイン通信
セキュアチャネルなども確認します。
12. AD Sites and Servicesを確認する
複数拠点にドメインコントローラーを配置している環境では、
Active Directory Sites and Services
も重要です。
例えば、
Site-A
└ DC01
Site-B
└ DC02
Site-C
└ DC03のような構成です。
ここで、
IPサブネットがSiteへ正しく割り当てられているか
DCが正しいSiteに所属しているか
Connection Objectが存在するか
Site Linkが適切かなどを確認します。
特に拠点数が多い環境では、
「通信できるからADサイト設定は関係ない」
とは考えない方がよいでしょう。
ネットワーク上のサブネットとADサイトの対応が正しいか確認します。
13. イベントログを確認する
DCのイベントビューアーも確認します。
特に、
Directory Service
DNS Server
DFS Replication
Systemなどです。
RPC 1722が発生した時刻付近のイベントを確認します。
ここで、
DNSエラー
レプリケーションエラー
Netlogonエラー
DFSRエラー
ネットワークエラーなどが同時に記録されていれば、原因特定の手掛かりになります。
重要なのは、
repadminで失敗した時刻とイベントログの時刻を合わせて見る
ことです。
14. SYSVOLも確認する
ADレプリケーションに問題がある場合は、SYSVOLの状態も確認しておきます。
例えば、
\\DC01\SYSVOL
\\DC02\SYSVOLへアクセスできるか確認します。
GPOを変更したあとであれば、各DCのSYSVOLに変更が反映されているかも確認します。
例えば、
Policies
↓
{GPO-GUID}
↓
gpt.iniなどです。
ただし、
ADデータベースのレプリケーションとSYSVOLのDFSRレプリケーションは同じものではありません。
そのため、
repadmin正常
↓
SYSVOLも絶対正常とは限りません。
逆も同様です。
15. 複数DCがある場合は「どのDCを止めると発生するか」も重要
複数のDCが存在する環境では、障害の出方を比較すると原因を絞れる場合があります。
例えば、
DC01
DC02
DC03の3台があるとして、
DC03停止
↓
RPC 1722発生なのか、
DC02停止
↓
別の1722が発生なのかによって、依存関係が見えてくることがあります。
ただし、本番環境で原因調査のためにDCを安易に停止するのは危険です。
既に発生した障害や計画停止時の結果を比較するという考え方で使います。
1722が出たときの確認順序
ここまでを整理すると、私は次の順番で確認します。
RPC 1722発生
↓
repadmin /replsummary
↓
どのDC間で失敗？
↓
repadmin /showrepl
↓
最後の成功時刻を確認
↓
対象DCは稼働している？
↓
DNS名前解決
↓
SRVレコード
↓
TCP/135
↓
RPC動的ポート
↓
Firewall / ACL
↓
dcdiag
↓
nltest
↓
AD Sites and Services
↓
イベントログ
↓
SYSVOL / DFSRポイントは、設定変更より先に現状を把握することです。
「pingが通るからネットワークは正常」ではない
RPC 1722の調査で特に注意したいのがこれです。
ping DC02
↓
Reply
↓
ネットワーク正常とは限りません。
実際には、
ICMP
↓
OK
DNS
↓
？
TCP/135
↓
？
RPC動的ポート
↓
？
LDAP
↓
？
SMB
↓
？です。
pingは多数ある確認項目の一つにすぎません。
「pingは通るのにRPC 1722になる」ことは十分あり得ます。
逆に「RPCサービスを再起動すればよい」とも限らない
エラー名が、
RPC server is unavailableなので、
RPCサービスがおかしいのでは？
と考えがちです。
しかし実際には、
名前解決できない
↓
相手DCへ到達できない
↓
RPC接続できない
↓
1722でも発生します。
また、
TCP/135は通る
↓
動的RPCポートが遮断
↓
RPC通信成立せず
↓
1722という可能性もあります。
そのため1722は、
RPCサービスだけのエラー
ではなく、
RPC通信を成立させられなかった結果として表示されるエラー
と考えた方が切り分けしやすくなります。
調査結果は表にすると分かりやすい
DCが複数ある場合は、調査結果を表にするのがおすすめです。
| 確認項目 | DC01 | DC02 | DC03 |
|---|---|---|---|
| Ping | OK | OK | OK |
| DNS A | OK | OK | OK |
| SRV | OK | OK | OK |
| TCP/135 | OK | OK | NG |
| repadmin | OK | OK | 1722 |
| SYSVOL | OK | OK | 要確認 |
こうすると、
DC03だけ
TCP/135 NG
+
repadmin 1722のように共通点を見つけやすくなります。
大規模なAD環境では、コマンド結果を一つずつ眺めるよりDCごとの差を見ることが重要です。
原因が分からない状態でやらない方がよいこと
RPC 1722が発生すると、早く直したくなります。
しかし、いきなり、
DNSレコード削除
DC再起動
AD再構築
強制レプリケーション
ファイアウォール無効化などを行うと、原因が分からなくなることがあります。
まず、
repadmin
dcdiag
nslookup
Test-NetConnection
イベントログなどで変更前の状態を保存することをおすすめします。
特に本番のActive Directoryでは、原因調査と復旧作業を分けて考えた方が安全です。
まとめ
Active Directoryのレプリケーションで、
1722 (0x6ba)
The RPC server is unavailable.
RPC サーバーを利用できません。が発生した場合、RPCサービスだけを確認して終わらせないことが重要です。
まず、
repadmin /replsummaryと、
repadmin /showreplで、
どのDCからどのDCへのレプリケーションが失敗しているのか
を確認します。
その後、
DNS
↓
SRV
↓
ネットワーク
↓
TCP/135
↓
RPC動的ポート
↓
Firewall / ACL
↓
dcdiag
↓
AD Sites
↓
イベントログ
↓
SYSVOL / DFSRと範囲を広げていきます。
特に重要なのは、
pingが成功してもRPCが正常とは限らない
という点です。
また、RPC 1722は必ずしもRPCサービス自体の故障を意味するわけではありません。
DNSやネットワークなどの問題によって相手DCとのRPC通信を確立できなかった結果として、1722が表示される場合もあります。
トラブル対応では設定を片っ端から変更するより、
「どのDC間の、どの通信までは正常なのか」
を一つずつ確認することが、原因特定への近道です。
注意： Active Directoryは組織全体の認証に関係する重要なシステムです。本記事はトラブルの切り分け方法を紹介するもので、原因を確認せずDCの降格・DNSレコード削除・サービス停止などを行うことは推奨していません。本番環境ではバックアップや影響範囲を確認したうえで作業してください。
コメント