Active Directoryのドメイン コントローラー（DC）を新ハードウェアへ移行するとき、「旧DCを降格したら、repadminで見えているブリッジヘッド サーバーは自動で新DCに切り替わるの？」という不安がよく起きます。仕組みと例外、そして安全に確認する手順まで、実務目線で整理します。
状況の整理：なぜ「手動設定していないのに旧DCがブリッジヘッドに見える」のか
AD サイトとサービスを開いても「ブリッジヘッド サーバーを固定した覚えがない」のに、repadmin /bridgeheads を実行すると置き換え予定の旧DC名が表示されることがあります。
ここで押さえるべきポイントは、「表示されている＝手動で固定されている」ではないという点です。ブリッジヘッド サーバーは、何もしなければKCC（Knowledge Consistency Checker）/ ISTG（Inter-Site Topology Generator）が、サイト内のDCから“その時点での最適”として自動選出します。つまり、旧DCが表示されているのは、単に「今は旧DCが選ばれている」だけのケースが多いです。
ブリッジヘッド サーバーとは何か（ADレプリケーションの前提）
ブリッジヘッド サーバーは、サイト間レプリケーション（Inter-site）において、他サイトとの送受信の“窓口”になるDCです。サイト内の全DCが他サイトと直接やり取りするのではなく、KCCが選んだブリッジヘッドが他サイトのブリッジヘッドと通信し、サイト内へ反映していきます。
| 用語 | 役割 | 実務上のポイント |
|---|---|---|
| サイト内レプリケーション（Intra-site） | 同一サイト内のDC間でのレプリケーション | 頻度が高く、通常は自動で効率よく構成される。ブリッジヘッドの概念は主に関係しない。 |
| サイト間レプリケーション（Inter-site） | 異なるサイト間でのレプリケーション | コストやスケジュール、帯域を意識して構成される。ここでブリッジヘッドが重要になる。 |
| KCC | レプリケーション トポロジ（接続）を計算・維持する仕組み | 一定間隔で自動再計算。必要なら手動で再計算を促せる。 |
| ISTG | サイト間トポロジ生成の責任者（サイトごとに1台選ばれる） | ブリッジヘッド選出やサイトリンクをもとに接続を作る中心役。選出されるDC自体も自動で入れ替わる。 |
| ブリッジヘッド サーバー | サイト間通信の代表DC（窓口） | 手動指定しない限り、基本は自動選出。旧DCを降格すれば別のDCへ切り替わるのが通常。 |
| 優先ブリッジヘッド（Preferred Bridgehead） | 「このDCをブリッジヘッドとして使ってほしい」と明示する設定 | 設定しているとKCCが選択肢を絞るため、移行時に想定外の停止要因になりやすい。 |
結論：通常は何もしなくてOK。旧DC降格後にKCCが後任を自動選出する
質問の核心である「旧DCを降格（demote）したら新DCが自動でブリッジヘッドになるのか」については、“優先ブリッジヘッドを手動指定していない限り、通常は自動で切り替わる”が基本動作です。
- 旧DCを正しく降格すると、旧DCはレプリケーション トポロジの計算対象から外れます。
- その結果、ISTG/KCCが再計算し、同一サイト内に残るDCの中から新しいブリッジヘッドを自動選出します。
- 同一サイト内のDCが1台しかないなら、基本的にその1台がブリッジヘッドになります（選ぶ余地がないため）。
注意したいのは、「自動で切り替わる＝瞬時に表示が変わる」とは限らない点です。KCCの再計算は一定間隔で実施されるため、repadmin /bridgeheads の結果が切り替わるまでタイムラグがあり得ます。とはいえ、移行作業としては待つ必要はなく、後述のコマンドで“切り替えを促す”こともできます。
「自動で切り替わる」の前提条件：これが満たされないと詰まる
自動選出は強力ですが、前提が崩れていると「選ばれたのに通信できない」「そもそも候補がいない」などの形で問題が表面化します。移行で事故を避けるために、次の観点を押さえてください。
サイト設計が正しい（サブネット割り当て、サイトリンク、コスト、スケジュール）
- サブネットが正しくサイトに関連付けられている（DCやクライアントが意図したサイトに属する）。
- サイトリンクが適切に構成され、必要なサイト間が到達できる。
- コスト・スケジュールが極端ではなく、レプリケーションが許可されている。
ネットワーク/ファイアウォールが「新DCのIP」でも通る
移行で一番多い落とし穴がここです。旧DCのIPが許可リストに入っていて、新DCのIPは閉じている──この状態だと、旧DC降格後に新DCがブリッジヘッドに選ばれても、サイト間RPCが通らずレプリケーションが止まります。
| 用途 | 主なポート例 | 補足 |
|---|---|---|
| DNS | TCP/UDP 53 | AD統合DNSの場合、特に重要。相互参照・転送も確認。 |
| LDAP/LDAPS | TCP 389 / 636 | 基本のディレクトリ通信。LDAPS利用環境は証明書も含めて確認。 |
| GC（グローバル カタログ） | TCP 3268 / 3269 | 複数ドメイン/フォレストで影響大。認証やアドレス帳参照にも関与。 |
| SMB/Netlogon等 | TCP 445 | SYSVOL/NETLOGON、GPO配布などに影響。 |
| RPCエンドポイント | TCP 135 | RPCの入口。サイト間レプリケーションでも必要。 |
| RPC動的ポート | TCP 49152–65535（既定例） | 環境によっては範囲制限している場合あり。旧DCだけ許可していないか要確認。 |
新DCがブリッジヘッド候補として“適切な役割/条件”を満たしている
- 新DCが対象のサイトに正しく所属している（意図せず別サイト扱いになっていない）。
- 対象のディレクトリ パーティション（命名コンテキスト）を保持している。
- RODCのみのサイト構成など、特殊要件がない（ある場合は設計を見直す）。
例外：事前に設定確認が必要なケース
「通常は自動でOK」とはいえ、実際の現場では“昔に誰かが固定していた”“回線が細いので固定している”などの事情があります。次の条件に当てはまる場合は、旧DC降格前に必ず確認してください。
優先ブリッジヘッド（Preferred Bridgehead）を手動指定している
AD サイトとサービス上で、特定のDCを「優先ブリッジヘッド」として指定していると、ISTGは原則としてその指定の中からブリッジヘッドを選びます。旧DCだけが優先ブリッジヘッドになっていると、降格後に候補が消え、サイト間レプリケーションが不安定になることがあります。
確認の目安は次の通りです。
- AD サイトとサービスで、各サーバーの NTDS Settings のプロパティに「ブリッジヘッド サーバー」関連の設定がないか確認する。
- IPトランスポート（通常はこちら）で「このサーバーを優先ブリッジヘッドにする」旨が有効になっていないか確認する。
サイト間通信を“特定のDCだけ”許可するファイアウォール運用
セキュリティ要件で「サイト間のAD通信はこのIPだけ通す」という設計にしている場合、ブリッジヘッドは事実上“固定運用”になります。移行後も同じ方針を取るなら、新DCに対して許可設定を移し、必要なら新DCを優先ブリッジヘッドとして明示するのが安全です。
手動接続オブジェクト（KCC任せではない接続）を作っている
AD サイトとサービスで、KCCが作る自動接続ではなく、管理者が手動で接続オブジェクトを作っている環境では、旧DC降格後に接続が残骸として残ったり、意図した通信経路にならない可能性があります。移行の前に、接続オブジェクトの運用方針（自動/手動）を棚卸ししておくとトラブルが減ります。
旧DC降格前にやるべき「安全な移行チェックリスト」
ブリッジヘッドの自動切り替え自体はKCCが面倒を見ますが、降格という作業はADの基盤に触れるため、周辺も含めたチェックが重要です。ここでは“ブリッジヘッド切り替え事故”を防ぐ観点で、必要最低限をまとめます。
| タイミング | チェック項目 | 目的 | 実務メモ |
|---|---|---|---|
| 降格前 | 新DCへのレプリケーションが正常（エラーなし） | 切り替え後に“最新状態”を担保 | repadmin /replsummary と repadmin /showrepl を複数回確認。 |
| 降格前 | 新DCのDNS設定/名前解決が正しい | サイト間通信の前提 | 新DCが自分自身と他DCを正しく解決できること。逆引きや委任も環境次第で確認。 |
| 降格前 | サイト間ファイアウォールの許可が新DCで通る | ブリッジヘッド交代後の通信断を防止 | “旧DCのIPだけ許可”になっていないかが最重要。 |
| 降格前 | 優先ブリッジヘッドの指定有無を棚卸し | 候補の枯渇を防止 | 指定があるなら、後任のDCも指定対象に入れるか、運用自体を見直す。 |
| 降格前 | 旧DCが持つ役割（FSMO、GC、DNS等）を把握 | 降格で失う機能をなくす | ブリッジヘッドとは別件だが、降格でのインシデントを避ける必須作業。 |
| 降格後 | レプリケーション トポロジ再計算（必要なら手動促進） | 切り替えの確実化 | repadmin /kcc や repadmin /syncall を活用。 |
| 降格後 | repadmin /bridgeheads 再確認 | ブリッジヘッドが新DCへ移ったことを確認 | 表示の切り替えはタイムラグがあるため、KCC促進後に確認すると確実。 |
降格前後で使うコマンド集（結果の見方まで）
“なんとなく大丈夫そう”をやめて、機械的に確認できる状態を作るのが移行のコツです。以下は、ブリッジヘッド切り替えに直結する確認コマンドです。
| コマンド | 何が分かるか | 見るべきポイント |
|---|---|---|
repadmin /bridgeheads | サイト間レプリケーションでブリッジヘッドとして扱われているDC | 旧DCが表示されても即異常ではない。降格後に新DCへ移るかを確認。 |
repadmin /showrepl | 各DCの受信レプリケーション状態（相手、最終成功時刻、エラー） | エラーコードが出ていないこと、最終成功時刻が更新され続けること。 |
repadmin /replsummary | 全体の要約（失敗率、遅延、エラー） | 失敗がゼロ、遅延が異常に大きくないこと。移行前後で比較する。 |
repadmin /kcc | KCCにトポロジ再計算を促す | 降格直後の“切り替え待ち”を短縮。実施後に再度 /bridgeheads などで確認。 |
repadmin /syncall /AdeP | 全パーティションの同期を促す（環境によってオプションは調整） | 降格前に「新DCへ最新を押し込む」、降格後に「新トポロジで同期」を確認するのに有効。 |
dcdiag /test:replications | DC診断（レプリケーション関連） | repadminの生情報と併用すると判断が早い。 |
コマンド例は次のように実行します（環境に合わせてサーバー名は置き換えてください）。
repadmin /replsummary
repadmin /showrepl NEW-DC01
repadmin /bridgeheads
repadmin /kcc NEW-DC01
repadmin /syncall NEW-DC01 /AdeP
「切り替わったか」を最短で確認する実務フロー
旧DCを降格したあと、ただ待つのではなく、次の順序で確認すると迷いません。
- 降格が完了し、旧DCがADから消えていくことを確認（AD サイトとサービス上のサーバー オブジェクトやDNS登録も含む）。
- 新DCでKCC再計算を促す（
repadmin /kcc）。 - 新DCのレプリケーションが回っているか確認（
repadmin /showrepl、repadmin /replsummary）。 repadmin /bridgeheadsを再実行し、旧DCではなく新DCがブリッジヘッド側に見えることを確認。
ポイントは、「ブリッジヘッド表示」だけで合否を決めないことです。ブリッジヘッドの表示が変わっていても、通信が通っていなければ意味がありませんし、逆に表示がすぐ変わらなくても実際のレプリケーションが成功していれば問題ない場合もあります。最終的には /showrepl と /replsummary が正義です。
トラブルが出たときの典型パターンと対処
新DCがブリッジヘッドに“選ばれたっぽい”のに、サイト間レプリケーションが失敗する
このケースは、ほぼネットワーク（ファイアウォール/ルーティング/DNS）の問題です。特に「旧DCのIPだけ通っていた」パターンが圧倒的に多いです。
- 対処：サイト間で必要なポートが新DCのIPでも許可されているか、双方向で確認する。
- 対処：DNSの参照先（プライマリ/セカンダリ）、条件付きフォワーダー、逆引きが旧DC前提になっていないか確認する。
- 確認：
repadmin /showreplのエラーコード（例：RPCサーバーを利用できません、アクセス拒否など）を起点に切り分ける。
旧DCを降格したのに、repadminで旧DC名が残り続ける
“降格が完了した”つもりでも、AD内に旧DCのメタデータが残っていると、参照が残る場合があります。これはブリッジヘッドの問題というより、降格の後処理（クリーンアップ）の問題です。
- 対処：AD サイトとサービスで旧DCのサーバー/NTDS Settingsオブジェクトが残っていないか確認し、残っているなら原因を調べる。
- 対処：DNSに旧DCのAレコードやSRVレコードが残っていないか確認する（クライアントが誤って旧DCへ向かう原因になる）。
- 対処：降格が失敗・中断した場合は、必要に応じてメタデータ クリーンアップを検討する（実施前に影響範囲を十分に確認）。
同一サイトにDCが1台しかなく、移行タイミングで不安定になる
1台構成だと、ブリッジヘッドは自動的にその1台になります。ただし、移行中の再起動やネットワーク設定変更の瞬間に、サイト間レプリケーションが止まるリスクが上がります。
- 対策：可能なら移行期間だけでも一時的に2台体制にし、レプリケーション正常を確認してから旧DCを降格する。
- 対策：回線が細い拠点ほど、移行時間帯を選び、
repadminで“止まっていないこと”を確認しながら進める。
実務で役に立つ「判断基準」：いつ手動指定を検討すべきか
多くの環境では「自動のまま」が最適です。ですが、次のような条件があるなら、優先ブリッジヘッドの指定や、DC配置そのものの見直しを検討する価値があります。
| 状況 | 自動選出のままだと起きがちなこと | 検討すべき対応 |
|---|---|---|
| サイト間に厳格なファイアウォール（IP限定許可）がある | 選ばれたDCが許可対象外で通信できず、突然レプリケーション停止 | 新DCのIP許可を反映し、必要なら優先ブリッジヘッドを明示 |
| 拠点回線が細く、特定時間帯のみ同期させたい | 思わぬタイミングで負荷が出る、帯域を食う | サイトリンクのスケジュール/コスト調整を優先。必要に応じて優先ブリッジヘッド |
| 特定DCにのみ監査/IDS例外や通信経路の要件がある | 経路が変わるたびに例外申請が必要になり運用負荷が増える | 「窓口DCを固定する」運用を文書化し、移行時の手順に組み込む |
| 複数DCがいるのに、いつも同じDCがブリッジヘッドで不安 | 偏りが気になるが、実害がないことも多い | まずはレプリケーション正常性を確認。偏り自体より“通信できるか”が重要 |
移行でやりがちなミスと、先回りの防止策
- 旧DC降格の前に、サイト間通信の許可設定を更新しない：旧IP前提の許可が残ると、新DCが選ばれた瞬間に止まる。移行作業のチェック項目として最優先に入れる。
- repadmin /bridgeheads の表示だけで判断する：表示は結果の一部。必ず
/showreplと/replsummaryで成功を確認する。 - 優先ブリッジヘッドの設定が“過去の遺産”として残っている：設計思想が分からないまま移行すると事故る。設定の有無だけでも棚卸しする。
- サイト/サブネットの紐付けが曖昧：拠点追加やIP変更のたびに崩れやすい。移行時はサブネット定義を再確認する良い機会。
まとめ：ブリッジヘッドは「自動」が基本。例外だけ潰して、repadminで淡々と確認する
旧DCを降格してもブリッジヘッド サーバーがどうなるかは、ADの仕組みを知っていれば怖くありません。優先ブリッジヘッドを手動指定していない一般的な構成なら、KCC/ISTGが自動で後任を選ぶため、原則として追加設定は不要です。
一方で、移行時に本当に問題になりやすいのは「自動選出」そのものではなく、新DCのIPでサイト間通信が通るか、そして降格前後のレプリケーションが正常かです。repadmin で状態を可視化し、必要なら repadmin /kcc で再計算を促しながら進めれば、ブリッジヘッド切り替えは安全に完走できます。
コメント