Windows Server 2008 R2の旧DC再起動でdcdiag/repadminエラー（1722/1256）になる原因と対処｜AD移行直後の確認手順

Windows Server 2008 R2 の旧ドメインコントローラー（DC）から Windows Server 2012 の新DCへ移行した直後、旧DCを停止して動作確認をしたあとに再起動すると、dcdiag や repadmin で 1722/1256 などのエラーが突然出ることがあります。放置してよい“揺らぎ”か、すぐ対処すべき障害かを切り分ける手順をまとめます。

起きていることを整理：移行直後の「旧DC再起動」で発生しやすい症状

AD（Active Directory）移行では、新DCの追加、DNS/GC（グローバルカタログ）の役割、FSMO役割の移行、レプリケーションの確認までが一連の流れになります。移行作業が一通り終わり、dcdiag / repadmin で問題が無い状態になっていても、旧DCを一時的に停止して検証し、再起動した瞬間にエラーが噴き出すことがあります。

この現象は「移行が失敗した」というより、再起動直後に必要な前提（DNS登録、ネットワーク判定、依存サービス、時刻同期）が揃うまでの遅延が連鎖し、診断系コマンドが先に“失敗”を拾ってしまうことで起きるケースが多いです。とはいえ、放置してよいかは状況次第なので、まずは症状を整理してから原因を絞り込みます。

代表的なエラー/症状	よくある背景	最初の着眼点
repadmin /showrepl で 1722（The RPC server is unavailable）	名前解決失敗、RPC到達不可、相手DCのサービス未準備、ファイアウォール/セキュリティ	DNS解決（A/SRV）、DC間疎通、イベントログ（Directory Service/System）
1256（The remote system is not available）	リモートDCが見つからない/応答しない、サイト/サブネット未整備、古い参照が残る	AD Sites and Services、サブネット定義、DNSの参照先
GPO処理失敗（コンピューター名解決不可、ドメインが見つからない）	クライアント（旧DC自身含む）がDNSでドメインを引けていない、Netlogon未準備	NICのDNS設定、DNSサーバーログ、Netlogon関連イベント
DNS：DC位置特定（SRV）や動的登録の失敗	DNSサービス起動直後の遅延、DNSがADと同期中、登録先DNSが不適切	DNS Serverログ、_msdcs のレコード、ipconfig /registerdns の成否
NLA（Network Location Awareness）が起動ハング／依存サービス失敗（例：DCOM 1068）	ネットワークスタック確立の遅延、仮想環境の再開直後、NIC/ドライバ/サービス依存	Systemログの起動順、NIC状態、仮想化設定（保存状態/スナップショット）
DFS Namespace 初期化失敗（クロスフォレスト信頼情報など）	信頼関係参照に必要な名前解決やDC到達が未成立、認証/時刻ズレ	信頼先名前解決、時刻同期、DFS関連ログ

結論：一時的に収束する可能性はあるが、「待つ前提」では判断しない

質問の核心である「しばらく待てば自然に消える一時的なエラーか？」は、現場感としては“Yesの場合もある”が正直な答えです。特に以下の条件が揃うと、再起動直後にエラーが出ても、その後に収束することがあります。

• 新DC側は安定しており、移行前後の replication 成功履歴 がある
• 旧DC再起動直後の数十分〜数時間に限ってエラーが増え、その後は連続失敗が止まる
• DNSの動的登録が完了し、SRVレコードが正しく見えるようになると同時に、repadmin が成功に転じる

一方で、同じ症状に見えても、構成ミス・名前解決の恒常障害・スナップショット起因の問題などが紛れていると、待っても改善しません。したがって正攻法は次の通りです。

• 「何分待つか」を決める前に、イベントログで根本原因のヒントを掴む
• dcdiag/repadmin は、単発の失敗よりも“成功に戻ったか”と“失敗が収束しているか”で判断する
• 旧DCの降格（Demote）は同時ではなく1台ずつ進め、切り戻し可能性を残す

なぜ再起動で崩れるのか：原因は「DNS」「サービス」「時刻」が連鎖する

移行直後は、見た目は落ち着いていても、内部的には参照先の入れ替えが続いています。旧DCを停止しても新DCで稼働できることを確認できたとして、再起動した旧DCは“移行前の状態”の記憶（DNS参照、キャッシュ、サービス依存）を持ったまま、再びドメインの一員として整合を取りに行きます。この瞬間に次のような連鎖が起こりがちです。

DNS動的登録の遅延：SRVレコードが揃わないと DC が見つからない

ADはDCの位置特定にDNSのSRVレコードを大量に使います。再起動直後、DNSサービス/Netlogonがまだ準備中だったり、登録先DNSが不適切（旧DCが自分を見てしまう、参照DNSが停止中のDC、外部DNSなど）だったりすると、「DCが見つからない」→「RPCが張れない」→「レプリケーション失敗」に見えます。

サービス起動順の問題：NLAや依存サービスが遅れると認証も遅れる

Windowsのサービスは依存関係と起動順に強く影響を受けます。特にDCは、ネットワークが確立して初めて正しくドメインネットワークとして認識され、Kerberos/LDAP/RPCが安定します。NLAが起動ハングしたり、依存サービスが失敗していると、「ネットワークはつながっているのに、ドメインサービスが成立しない」状態になり、dcdiag/repadminは容赦なくエラーを出します。

仮想環境の「一時停止/保存状態」：時刻ズレがKerberosを壊す

タイトルにある「一時停止」や、ハイパーバイザ側の保存状態（サスペンド）からの復帰は、DCにとって相性が良くありません。復帰直後に時刻がズレると、Kerberos認証が失敗し、結果としてRPCやGPO処理が連鎖して失敗します。旧DCがPDCエミュレーターではなくても、“自分の時刻がズレているDC”はドメインに迷惑をかけるため、再起動直後に時刻同期が安定するかは重要な観点です。

まず確認する場所：イベントログを軸に「原因」を切り分ける

“待てば直るか”を感覚で決めるのではなく、該当時刻のイベントログで、どこから崩れているかを見ます。特に移行直後は、同じエラーが複数のログに出るので、発生順に追うのがコツです。

ログ	見るポイント	よくある示唆
System	NLA、DCOM、Netlogon、サービス起動失敗、ネットワーク断	起動直後の依存関係崩れ／NIC不安定／仮想環境復帰直後の問題
Directory Service	レプリケーション失敗、KCC、GC、名前解決に関連する警告	サイト/サブネット、相手DC到達、参照先の整合性
DNS Server	DNSサービス起動遅延、動的更新失敗、ゾーン読み込み、4013系の警告	DNSがADと同期できていない／登録先DNSが不適切／ゾーン未整備
DFS Replication / DFS Namespace	SYSVOLや名前空間初期化、信頼先参照の失敗	信頼関係・名前解決・認証（時刻）を疑う
GroupPolicy（アプリケーション/運用に出る場合も）	1054/1055系（ドメインが見つからない）	DNS優先順位、SRVレコード参照、Netlogon/KDCが未準備

ここで重要なのは、「レプリケーションが失敗している」ログだけを見ないことです。レプリケーションは結果であって、原因は「DNS」「ネットワーク」「時刻」「サービス起動」のどこかにあることが多く、結果だけを追うと遠回りになります。

dcdiag / repadmin（repmon）で見るべき指標：単発エラーより“収束”

dcdiag や repadmin は、起動直後の揺らぎを容赦なく拾います。大切なのは「今エラーが出たか」より、継続して失敗し続けているのか、それとも成功に戻っているのかです。次のように“観測項目”を決めて確認すると判断が速くなります。

コマンド	確認したいこと	判断のコツ
repadmin /showrepl	相手DCごとの最終成功時刻、失敗理由、連続失敗回数	最終成功時刻が更新される／連続失敗が止まるなら収束傾向
repadmin /replsummary	全体の失敗率、Largest Delta（最終成功からの経過）	Largest Delta が伸び続けるのは危険信号。改善するなら一時的の可能性
dcdiag（特に Replications / DNS / Advertising）	致命的なテスト失敗があるか、DNS関連での失敗が集中していないか	DNSテストが落ちている場合は“待つ”よりDNSの修正が先
repadmin /queue	処理待ちが滞留していないか	キューが増え続ける場合は根本的に詰まっている可能性
nslookup（A/SRV）	DCのAレコードと、_msdcs配下のSRVが引けるか	SRVが引けないならレプリケーション以前に名前解決が成立していない

起動直後の確認でエラーが出た場合でも、同じ観測項目を一定間隔で再確認し、成功に戻っているか（収束しているか）を見ます。待つこと自体が目的ではなく、「原因が解消しつつある」ことをログと指標で確認する、という位置付けにします。

repadmin 1722 / 1256 を最短で切り分けるフロー（DNS→疎通→認証→レプリケーション）

1722（RPC server is unavailable）と 1256（remote system is not available）は、原因が複数にまたがります。最短で潰すなら、DNS→疎通→認証→レプリケーションの順で、前提から確認します。

DNS：AレコードとSRVレコードが正しく引けるか

まずは「相手DCの名前が正しいIPに解決できるか」「DC位置特定用のSRVが揃っているか」を確認します。DC移行直後は、AレコードはあってもSRVが欠ける、あるいは古いIPが残ることがあるため、ここが最優先です。

nslookup 旧DCのFQDN
nslookup 新DCのFQDN

nslookup -type=SRV _ldap._tcp.dc._msdcs.ドメインFQDN
nslookup -type=SRV _kerberos._tcp.dc._msdcs.ドメインFQDN
nslookup -type=SRV _gc._tcp.ドメインFQDN

この段階で期待した結果が返らない場合、repadminの前にDNS（ゾーン、動的更新、NIC設定、不要NICの登録）を是正します。

疎通：RPC/LDAP/DNS など、DC間で最低限の通信が成立しているか

RPCは「135番（エンドポイントマッパー）」と「動的ポート」がセットで必要になります。ファイアウォールやセキュリティ製品、ネットワークACLがある環境では、起動直後に一時的にブロックされるケースもあるため、“名前は引けるのに1722”のときに疑います。

用途	代表ポート	メモ
DNS	53	名前解決の前提。UDP/TCPの両方が絡むことがあります
Kerberos	88	時刻ズレがあると失敗しやすい
LDAP	389（LDAPS:636）	AD参照の基本。GPO/認証にも波及
グローバルカタログ	3268（GC SSL:3269）	GCを使う検索やログオンに影響
SMB（SYSVOL/NETLOGON）	445	GPO配布やログオンスクリプトに影響
RPC	135 + 動的ポート（例：49152-65535）	レプリケーションの主経路。ネットワーク制御があると詰まりやすい

Windows標準だけでポート疎通を完全に確認するのは難しいことがあります。その場合は、Microsoftの疎通確認ツール（例：PortQry）や、ネットワーク側のログ/監視も併用すると原因特定が速くなります。

認証：時刻同期とセキュアチャネルが成立しているか

DNSが正しく、疎通もあるのにGPOやDFS、repadminが不安定なら、次に認証前提（時刻・セキュアチャネル）を疑います。

• 時刻：w32tm /query /status でソースとオフセットを確認
• DC自身のドメイン検出：nltest /dsgetdc:ドメインFQDN で DC を見つけられるか

レプリケーション：前提が揃ってから repadmin を再評価する

ここまでの前提が揃ったら、あらためて repadmin /showrepl と repadmin /replsummary を確認します。必要に応じて、手動同期をかけて“復帰できるか”を観測します。

repadmin /syncall 自分のDC名 /AdeP

強制同期は万能薬ではありませんが、「解消できる種類の問題か」を見分ける材料になります。同期直後に成功が増えるなら、起動直後の揺らぎやDNS起因だった可能性が上がります。

すぐにできる安全な対処：DNS登録・名前解決・時刻を整える

原因がDNS/ネットワーク/時刻に寄っている場合、比較的安全に試せる対処がいくつかあります。いずれも“構成を破壊する操作”ではないため、移行フェーズの切り分けに向いています。

NICのDNS設定を見直す（ここがズレていると全部崩れる）

DCのNIC設定は、移行直後ほど事故が起きやすいポイントです。以下を基準に、旧DC・新DCの両方で確認します。

• DNSサーバーはドメインDNS（AD統合DNS）を指しているか（外部DNSや停止中の旧DCを参照していないか）
• 新旧DCが混在する期間は、優先DNS：自分（DNS搭載DCの場合）／代替DNS：相手のDCなど、到達可能な組み合わせになっているか
• 複数NIC、VPN仮想NIC、不要なインターフェースが DNS登録に割り込んでいないか

DNS動的登録を再実行してSRVを揃える

DC位置特定に使うレコードが揃っていない場合、以下を実行して状況が改善するか確認します。

ipconfig /flushdns
ipconfig /registerdns

net stop netlogon
net start netlogon

Netlogonの再起動は、SRVレコードの登録を再トリガーします。実行後は、DNSマネージャーで _msdcs 配下を含むDC関連レコードが期待通りに作成されているか、nslookupで引けるかを確認します。

時刻同期を確認する（Kerberos前提）

特に仮想環境で一時停止/復帰を行った場合や、ハイパーバイザの時刻同期が介在している場合は、起動直後の時刻ズレが致命的になり得ます。

w32tm /query /status
w32tm /resync

時刻ズレが疑わしい場合は、どのサーバーが時刻ソースか（特にPDCエミュレーター）も含めて再確認します。移行直後にPDCエミュレーターが新DCへ移っているなら、時刻の参照が新しい体系になっているかが重要です。

DC間疎通と名前解決を“両方向”で確認する

1722（RPC server is unavailable）は、相手が落ちているとは限りません。名前解決が誤っている、到達できない、ポートが塞がっている、認証が通らない、など複数の要因で発生します。最低限、DC同士で次を確認します。

• 相手DCのFQDNが正しいIPに解決できる（Aレコード）
• ドメインのSRVレコードが引ける（_ldap / _kerberos / _gc など）
• 疎通（ICMPだけでは不十分だが、まずは基本として）

「一時的に直る」パターンの特徴：ログが“原因→結果”の順で収束していく

今回のように、数時間後にエラーが解消して正常に戻るケースでは、ログの並びが比較的きれいです。たとえば、起動直後はDNSやサービス起動の警告が出て、その後に動的登録が成功し、repadmin の成功が増えていく、という流れになります。

観測ポイント	収束していく挙動（期待）	危険な挙動（要対処）
DNS Serverログ	起動直後の警告が止まり、動的更新が成功する	動的更新失敗が繰り返し出続ける／ゾーンが読み込めない
Directory Serviceログ	レプリケーション失敗が減り、成功イベントが出る	KCC関連や名前解決関連のエラーが連続する
repadmin /showrepl	最終成功時刻が更新され、連続失敗回数がリセットされる	Largest Delta が伸び続け、同じエラーで固定される
GPO/DFS系	ドメイン検出が成功し、処理失敗が止まる	名前解決不可が継続し、アプリや共有も不安定
時刻	同期が安定し、ログオン/認証系が落ち着く	大きなズレが残り、Kerberos関連が断続的に失敗

つまり、“レプリケーションエラーが出ている”という結果だけで待つのではなく、原因になりやすいDNS/サービス/時刻のログが収束しているかを確認できれば、短時間の揺らぎとして扱える可能性が上がります。

直らない／繰り返す場合に疑うべき落とし穴

同じ「1722」「1256」でも、根が深い場合があります。移行直後は特に、次の落とし穴にハマりやすいので、該当するものがないか確認してください。

停止した旧DCを、まだ誰かが参照している（DHCP・固定設定・DNS転送）

旧DCを停止している間に問題が出なかったとしても、再起動後に旧DCがDNS登録を始め、クライアントやサーバーが一部だけ旧DCへ引き寄せられると、名前解決が揺れて障害に見えることがあります。代表例は次の通りです。

• DHCPオプションで配布しているDNSサーバーに旧DCのIPが残っている
• 一部サーバーのNICに旧DCが固定DNSとして残っている
• DNS転送先や条件付きフォワーダーに、停止していた旧DCを指定している

サイト/サブネットの未整備で、想定外のDCへ行ってしまう

AD Sites and Services でサブネット定義が不足していると、DCやメンバーサーバーが“最寄りのDC”を正しく選べず、遠いサイトや想定外のDCへ行きます。結果として、遅延・タイムアウト・断続的な失敗が増え、repadminは1722/1256を吐きやすくなります。移行直後は、新DCを置いたサブネットが定義されているかを必ず見直します。

仮想基盤のスナップショット/巻き戻し（DCでは特に注意）

DCをスナップショットで戻す運用は、レプリケーション整合性を壊すリスクがあります。今回の操作が「一時停止」ではなく、もしスナップショット復元や保存状態の扱いが絡むなら、ログに“USNの不整合”や“レプリケーション保護”の兆候が出ることがあります。その場合は、単純に待つのではなく、状況に応じた是正（安全な再構築やメタデータ整理）を検討してください。

複数NIC/不要NICのDNS登録が混ざる

バックアップ用NIC、管理用NIC、VPN仮想NICなどがあると、意図しないインターフェースのアドレスがDNSへ登録され、クライアントや他DCがそのIPへ接続して失敗することがあります。DNSに登録されるレコード（A/AAAA）が想定と一致しているかを確認し、必要なら登録設定を調整します。

移行フェーズの健全性チェック：やるべきことを“判断基準”に落とす

移行期に一番怖いのは、「そのうち直るだろう」で進めてしまい、後から切り戻せなくなることです。そこで、作業を進める条件（健全性の基準）を明確にします。

健全性の基準	確認方法	合格の目安
レプリケーションが安定	repadmin /replsummary / repadmin /showrepl	連続失敗が増えない／最終成功時刻が更新される
dcdiagが致命的エラーなし	dcdiag（特に DNS / Replications）	DNSテストが概ね成功し、エラーが固定化していない
DNSにDC関連レコードが揃う	DNSマネージャー / nslookup	_msdcs配下含め、期待するDCのA/SRVが引ける
クライアントが新DCへ寄る	DHCP/固定DNS設定の棚卸し	旧DC依存が残っていない（意図的に残す場合は管理できている）
役割の移行が完了	netdom query fsmo など	FSMOが新DC側にあり、旧DCへ戻らない

旧DCの降格（Demote）は「1台ずつ」：安全に前へ進める手順

今回のケースのように、再起動直後に一時的なエラーが出ても、最終的に収束して正常化することがあります。ここまで確認できたら、旧DCの整理（降格）を安全に進めます。ポイントは“同時に落とさない”ことです。

降格前に確認しておきたいチェック

チェック項目	理由	確認のヒント
新DCが複数台で稼働（冗長性）	1台降格しても認証/DNS/GCが継続できる	新DCがDNS/GCを担えるか、サイト配置が妥当か
旧DCにFSMOが残っていない	降格で役割が消えるとドメイン運用に直撃	netdom query fsmo の結果を保存しておく
旧DCが参照されていない	降格後に名前解決・認証が不安定になる	DHCP配布、固定DNS、DNS転送設定を棚卸し
SYSVOL/ポリシーが新DCで正常	GPO配布の要	新DC側でGPO適用、SYSVOL共有が見えるか

進め方の例（移行直後の現実的な運用）

• 旧DCを1台だけ対象にして、降格前の健全性チェック（repadmin/dcdiag/DNS）を満たすことを確認
• 旧DCを降格し、AD Sites and Services やDNSから関連情報が整理されることを確認
• 数日〜一定期間運用し、GPO・認証・名前解決・レプリケーションが安定していることを確認
• 問題がなければ、もう1台の旧DCを同様に降格

この順番にしておくと、もし想定外の依存（古いアプリが旧DCのIPを参照、古いDNS転送が残存など）があっても、影響範囲を小さくして切り戻しやすくなります。

まとめ：診断の正解は「待つ」ではなく、「原因をログで押さえて収束を確認する」

旧DCを停止→再起動した直後に、dcdiag/repadminで1722や1256が出るのは珍しくありません。特に移行直後は、DNSの動的登録、サービス起動順、時刻同期などが追いつくまでの間、診断が失敗に振れやすいからです。

ただし、同じエラーでも根本原因はさまざまで、放置が危険なケースもあります。だからこそ、イベントログで原因を確認し、repadminの最終成功時刻や失敗の収束で健全性を判断し、旧DCは1台ずつ順番に降格していくのが、移行直後の現場で最も堅い進め方です。