Windows Server 2016のドメイン コントローラー（DC）を2019へ移行しつつ、最終的に同じホスト名・同じIPアドレスで運用したい――。Azure AD Connect（Microsoft 365/Entra ID同期）が絡むと、同期が止まらないか不安になります。本記事では影響の整理と、失敗しにくい移行手順・確認ポイントを実務目線でまとめます。
最初に結論：おすすめは「サイドバイサイド移行」＋最後にホスト名・IPを引き継ぐ
Windows Server 2016のドメイン コントローラー（DC）をWindows Server 2019へ移行する方法は大きく2つあります。ひとつは既存DCをそのまま上書きするインプレースアップグレード、もうひとつは新しい2019サーバーを別名・別IPで用意して段階的に切り替えるサイドバイサイド移行（新DC追加→旧DC廃止）です。
DCは障害時の影響範囲が広く、失敗すると認証・DNS・グループポリシー・ファイル共有などが連鎖的に止まります。そのため、運用現場での再現性と切り戻し性を重視するなら、サイドバイサイド移行が基本的に推奨です。さらに、最後の段階で旧DCのホスト名・IPを新DCへ付け替えることで、「見た目は同じサーバー」を維持しつつクリーンに入れ替えできます。
| 項目 | サイドバイサイド移行 | インプレースアップグレード |
|---|---|---|
| 失敗時の復旧 | 旧DCを残して検証でき、切り戻しが現実的 | 失敗すると復旧が重くなりやすい |
| 不要設定の持ち越し | 最小構成で新DCを作れる | 過去の設定・役割を抱えたままになりやすい |
| 作業の見通し | 手順が定型化されており検証しやすい | 環境依存のトラブルが出ると調査が長引く |
| ホスト名・IP維持 | 最終段階で引き継ぎ可能（ただし注意点あり） | そのまま維持できるが、アップグレード失敗のリスクとトレードオフ |
2016から2019への移行で押さえる仕様：機能レベルとスキーマの考え方
よく混同されますが、Windows ServerのDCを新しくすることと、ドメイン/フォレスト機能レベル（DFL/FFL）を上げることは別です。Windows Server 2019には「2019専用」の新しい機能レベルはなく、一般的にはWindows Server 2016機能レベルのまま運用できます（無理に上げる必要はありません）。
一方で、新しいOSのDCを追加する際にスキーマ更新（adprep相当）が必要になることがあります。多くの環境ではDC昇格ウィザードが必要な準備を案内しますが、権限（Enterprise Admin等）やレプリケーション不全があると進みません。初回の2019 DC追加時は、作業時間に余裕を持たせ、事前にレプリケーション健全性を確認しておくのが安全です。
前提の整理：Azure AD Connectは「DC上」ではなく「別サーバー上」で動く
質問の前提では、Azure AD Connect（Microsoft 365/Entra IDのディレクトリ同期）がWindows Server 2022上で稼働し、そのサーバーは既にドメイン参加済みです。この構成だと、DCのOSを2016→2019に置き換えても、Azure AD Connect自体（同期エンジン、コネクタ設定、スケジューラ）は別サーバーに残ります。
つまり影響の本質は、Azure AD ConnectサーバーがActive Directoryへ接続できるか、そして接続先のDC/GC/DNSが健全かです。DCの「見た目（ホスト名・IP）」を維持するかどうかはAzure AD Connectの観点では二次的で、むしろネットワーク許可・DNS設定・特定DC固定の有無が重要になります。
Azure AD Connectへの影響まとめ：ホスト名・IPを維持する場合／変える場合
| ケース | Azure AD Connectへの典型的な影響 | 特に見るべきポイント |
|---|---|---|
| 最終的に同じホスト名・同じIPへ引き継ぐ | 基本的に影響は最小。通信許可やDNS参照先が変わらず、同期が継続しやすい | 切替時のDNSキャッシュ、旧DCの残骸（AD/DNSメタデータ）、LDAPS使用時の証明書 |
| ホスト名・IPを変えたまま運用する | 多くの環境で問題なく同期可能。ただし「旧DC固定」や「旧IPのみ許可」だと同期エラーになりやすい | Azure AD Connectで接続先DCを固定していないか、DNS/DHCP/Firewallの更新、GCの有無 |
ホスト名・IPを維持するときに「影響が出にくい」理由
Azure AD Connectは通常、ドメインやフォレストに対してLDAP/GCで接続し、サイト情報やDNSのSRVレコードを使って利用可能なDCを見つけます。最終的にホスト名・IPが同じであれば、ネットワーク許可（許可リスト/ACL）やサーバー側の参照設定を変えずに済むため、移行後も接続性が維持されやすくなります。
ホスト名・IPを変える場合に起きやすい落とし穴
- ファイアウォールが旧DCのIPだけ許可していて、新DCに接続できない
- Azure AD Connectが「優先DC（Preferred DC）」として旧DCを固定しており、旧DC撤去後にコネクタが失敗する
- Azure AD ConnectサーバーのDNS参照先が旧DCのみで、旧DC降格後に名前解決が崩れる
ホスト名・IPを本当に維持すべきか：判断の基準
「同じホスト名・同じIPでないと困る」のは、実はAzure AD Connectよりも、社内アプリや運用設計の都合であることが多いです。無理に引き継ぐと作業難易度が上がるので、まずは要件の“本当の理由”を整理するのがおすすめです。
| 状況 | ホスト名・IP維持が向く | 変更のまま運用が向く |
|---|---|---|
| LDAP接続先がサーバー名で固定 | 変更が難しい/影響範囲が広いなら維持を検討 | 設定変更できるならSRVレコード利用へ寄せる方が将来楽 |
| DNS/監視/運用ドキュメントが旧名前提 | 短期的な工数削減にはなる | 長期では新名運用＋ドキュメント整理の方が健全 |
| 証明書（LDAPS等）が旧名に依存 | 再発行が難しければ維持が現実的 | 証明書を正しく再発行できるなら変更が安全 |
| DCが“単独”構成（1台のみ） | 維持に固執すると事故のリスクが上がる | まずは2台構成を作り、そのうえで整理する方が安全 |
移行全体像：作業を「準備→追加→移行→降格→引き継ぎ→検証」に分ける
実務では、作業を一気にやろうとすると検証ポイントが曖昧になりがちです。以下のようにフェーズを分け、各フェーズで「合格条件」を決めて進めると失敗率が下がります。
| フェーズ | 目的 | 合格条件（例） |
|---|---|---|
| 準備 | 現状把握とリスク低減 | AD健全性が確認でき、復旧手段（バックアップ/手順）が確立している |
| 新DC追加 | 2019 DCを追加し冗長化 | レプリケーション/DNS/GCが正常、SYSVOL共有が見える |
| 役割移行 | FSMO・時刻同期・DNS参照を新側へ寄せる | FSMOが新DC、時刻同期が安定、クライアント参照に問題なし |
| 旧DC降格 | 旧DCを正しく撤去 | 降格が正常終了し、AD/DNSに旧DCの残骸がない |
| ホスト名/IP引き継ぎ（必要時） | 依存システム向けに見た目を維持 | 名前解決・認証・レプリケーションが正常 |
| Azure AD Connect検証 | 同期の継続確認 | デルタ同期が成功し、エラーが継続しない |
作業前に必ずやるチェックリスト（最重要）
サイドバイサイド移行は定番手順ですが、事前チェックを省くと「昇格できない」「レプリケーションが詰まる」「SYSVOLが複製されない」といった形で詰みます。以下を最低限実施してください。
| チェック項目 | 確認方法の例 | NGのときの代表的な対処 |
|---|---|---|
| ADレプリケーションの健全性 | repadmin /replsummary | 名前解決、サイト/サブネット、時刻ずれ、FW/ACLを優先的に疑う |
| DNSの整合性（SRVレコード含む） | dcdiag /test:dns /v | DNSをAD統合に寄せ、ゾーン/委任/フォワーダーを整理 |
| SYSVOL複製がDFSRで動いているか | dfsrmig /getglobalstate | 「Eliminated」まで移行完了させてから新DCを追加 |
| バックアップ（復旧できる形） | システム状態バックアップ、VMバックアップ取得と復元手順の確認 | 「戻せる」ことを具体化（誰が・何を・どこまで・どの手順で） |
| Azure AD Connectの現状把握 | 同期スケジュール、コネクタの接続先固定の有無、エラー履歴、OU/属性フィルタ | 旧DC固定があれば事前に解除/変更手順を準備 |
新しいWindows Server 2019を用意してドメイン参加させる
最終的に旧DCのホスト名・IPを引き継ぎたい場合でも、最初は別のホスト名・別のIPで新サーバーを構築します。いきなり同名同IPで作ると、AD/DNS上の識別子が衝突してトラブルになります。
- OSインストール後、最新の更新プログラムを適用
- 不要な役割/機能を入れない（DCはシンプルが正義）
- 固定IPを設定（この段階では旧DCとは別IP）
- DNS参照先は原則として既存DC（DNSサーバー）を向ける
- 既存ドメインへメンバーサーバーとして参加
新サーバーをドメイン コントローラーへ昇格する
AD DS役割を追加してDCへ昇格します。ウィザード実行時、必要に応じてスキーマ更新（adprep相当）が走ることがあります。権限不足やレプリケーション不全があるとここで詰まるため、事前チェックが効きます。
- 「Active Directory ドメイン サービス」を追加
- 既存ドメインに追加DCとして昇格
- DNSサーバーを同時に導入（一般的には推奨）
- グローバルカタログ（GC）を有効化（単一ドメインでも有効推奨）
昇格後は、次の確認を「必ず」行います。
- SYSVOLとNETLOGONが共有されているか（ポリシー/スクリプト配布の要）
- レプリケーションにエラーがないか（repadmin）
- DNSレコードが正しく登録されているか（dcdiag /test:dns）
FSMO役割を新DCへ移行する
旧DCを降格する前に、FSMO（5つの役割）を新DCへ移行します。移行確認ができていないまま旧DCを落とすのは、復旧を難しくする典型的な事故パターンです。
確認コマンド例：
netdom query fsmoPowerShell例：
Move-ADDirectoryServerOperationMasterRole -Identity "NewDC" -OperationMasterRole 0,1,2,3,4時刻同期（NTP）を必ず見直す：PDCエミュレーターが要
Kerberos認証は時刻ずれに弱く、ドメイン全体の認証不調がAzure AD Connectの同期失敗に波及することがあります。PDCエミュレーターを新DCへ移したら、時刻同期先が正しいかを確実に確認してください。
- 外部NTP（社内標準の時刻サーバー）に同期させる
- ドメインメンバーはドメイン階層で同期させる
確認例：
w32tm /query /status
w32tm /query /configuration旧2016 DCを降格して撤去する（ここは丁寧に）
旧DCは「いきなり電源OFF」ではなく、必ず降格（demote）して撤去します。降格により、AD内のメタデータやDNS登録が正しい手順で整理されます。
- 旧DCで役割/依存関係を最終確認（DNS・DHCP・証明書サービス・ファイル共有などが同居していないか）
- 降格ウィザードを実行し、DCからメンバーサーバーへ戻す
- 降格完了後、ドメインから切り離す（必要に応じて）
- ADユーザーとコンピューター、DNSマネージャで旧DCの残骸がないか確認
降格後の健康診断例：
repadmin /replsummary
dcdiag /vホスト名・IPを引き継ぐ手順（最終的に同じにしたい場合）
旧DCを降格・撤去したら、旧DCが使っていたホスト名とIPを新DCに引き継げます。ただし、この工程は「便利な反面、落とし穴が多い」ため、手順と検証ポイントを押さえて進めてください。
大前提：同名同IPは同時に存在できない
同一ネットワーク内で同じホスト名・同じIPを同時に使うことはできません。よって、旧DCの降格と、DNS/AD上の整理が終わってから新DCへ引き継ぐのが鉄則です。
引き継ぎの基本手順（推奨フロー）
- 旧DCのADコンピューターアカウントが残っていないことを確認（残っていれば削除）
- DNSのAレコード/古いSRVレコードが残っていないことを確認（残っていれば整理）
- 新DCでホスト名を変更（旧DCの名前へ）し、再起動
- 新DCでIPアドレスを変更（旧DCのIPへ）し、必要なら再起動
- ADレプリケーション/DNS登録/クライアント認証を検証
ホスト名変更（例）：
Rename-Computer -NewName "OLD-DC-NAME" -Restart引き継ぎ時の注意点：DNSキャッシュと「残骸」の二重罠
- DNSキャッシュの影響で切替直後に疎通が不安定になることがあります。Azure AD Connectサーバーや管理用端末で名前解決が怪しい場合は、DNSキャッシュクリアが切り分けに有効です。
ipconfig /flushdns - 旧DCが不完全な形で撤去されると、ADメタデータやDNS SRVレコードが残り、新DCが正しく認識されない原因になります。降格を正しく完了させるのが最重要です。
DCの名前変更は“最後の手段”として扱うのが安全
技術的にはDCの名前変更は可能ですが、環境によっては追加の役割（証明書サービス、特殊なアプリ同居など）が障害になります。DCはできるだけAD DS/DNSに専念させ、他の役割を載せない構成が理想です。「旧名に戻す」要件が強いほど、事前に検証環境でのリハーサルを行い、作業標準を固めてから実施してください。
ホスト名・IPを変えたまま運用する選択肢も現実的
「どうしても旧DC名でないと困る」ケース（アプリがLDAP先を固定、証明書CNの都合、監視/運用手順の都合など）は確かにあります。一方で、DCは本来「置き換え可能な基盤」として扱い、名前を固定しない設計の方が長期的には安全です。
もしホスト名・IPを変えたまま運用できるなら、その方が手順が単純で事故が減ります。変更した場合は、次の観点で依存関係を潰していけば問題なく移行できます。
| 変更点 | 影響が出やすい場所 | 対策の例 |
|---|---|---|
| IP変更 | ファイアウォール、ACL、許可リスト、監視 | 新DC IPを許可・監視対象に追加。旧IP前提のルールを洗い出す |
| ホスト名変更 | LDAP接続先の固定、スクリプト、ドキュメント | FQDN固定があるなら修正。可能ならSRVレコード利用に寄せる |
| DNSサーバー変更 | DHCPオプション、静的設定、Azure AD Connectサーバー | DNSは複数指定し冗長化。切替タイミングの周知 |
Azure AD Connect側で必ず確認するポイント（同期が止まる原因の大半はここ）
Azure AD ConnectはDC移行そのものより、「接続先の探索/固定」「DNS」「ネットワーク許可」で躓くことが多いです。移行後は次を確認します。
DNS設定：Azure AD ConnectサーバーのDNS参照先を冗長化する
Azure AD Connectが動作するWindows Server 2022のDNS参照先が旧DCだけになっていると、旧DC撤去後に名前解決が崩れて同期以前の問題になります。新DCをDNSとしても利用する場合は、DNS参照先に新DCを追加し、複数指定で冗長化してください。
「特定DC固定」になっていないか確認する
構成によっては、Azure AD Connectが特定のドメイン コントローラー（またはグローバルカタログ）を優先的に使うよう設定されていることがあります。旧DCに固定されていると、旧DC撤去後にコネクタが失敗します。
- Azure AD Connectサーバーで「Synchronization Service Manager」を開く
- Connectorsの設定で、ドメイン/フォレストの接続先が固定されていないかを確認
- 固定されている場合は新DC（または自動選択）へ変更
作業中に同期エラーを増やしたくない場合：スケジューラを一時停止する
切替の瞬間だけ一時的にLDAP接続が不安定になると、Azure AD Connectにエラーが記録されます。業務要件的に問題がないなら、作業中はスケジューラを一時停止し、切替完了後に再開する方法もあります。
# スケジューラ停止
Set-ADSyncScheduler -SyncCycleEnabled $false
# 状態確認
Get-ADSyncScheduler
# スケジューラ再開
Set-ADSyncScheduler -SyncCycleEnabled $trueLDAPS（636/3269）を使っている場合は証明書に注意
セキュリティ要件でLDAPSを使用している場合、新DCで同等のサーバー証明書が準備されていないとバインドに失敗します。証明書テンプレート、CN/SAN、信頼チェーン、秘密鍵の配置などを事前に整備してください。
同期確認：デルタ同期の実行とエラーログ確認
移行後は、同期エンジンが正常に動いているかを「結果」で確認します。
# デルタ同期（例）
Start-ADSyncSyncCycle -PolicyType Deltaよくあるエラーと原因・対処の例を表にまとめます。
| 症状（例） | 原因の切り分け | 対処例 |
|---|---|---|
| 「ディレクトリに接続できない」「LDAP bind失敗」 | DNS解決、到達性、FW/ACL、優先DC固定 | DNS参照先を見直し、新DC IP/ポートを許可。固定設定があれば変更 |
| 同期は走るがオブジェクト数が急に減る/増える | OUフィルタ、属性フィルタ、参照しているドメインパーティション | フィルタ設定を再確認。変更点がないか比較し、必要ならフル同期を計画的に実施 |
| パスワードハッシュ同期の遅延や失敗 | DC到達性、時刻ずれ、権限、イベントログ | NTPを見直し、Azure AD Connectのサービスアカウント権限を確認 |
通信要件の整理：Azure AD Connect→AD、DC↔DCで必要な通信は別物
IP変更時にファイアウォールを調整する場合、「Azure AD ConnectがDCへ到達するための通信」と「DC間レプリケーションに必要な通信」を分けて考えると漏れが減ります。
| 用途 | 代表的なプロトコル/ポート | メモ |
|---|---|---|
| Azure AD Connect → DC（参照） | LDAP 389（LDAPS 636）、GC 3268（GC over SSL 3269）、Kerberos 88、DNS 53 | 環境により追加要件あり。LDAPS利用時は証明書が必須 |
| DC ↔ DC（レプリケーション） | RPC 135、SMB 445、Kerberos 88、DNS 53、動的RPCポート（既定：49152-65535） | サイト間FWが厳しいとここが詰まりやすい |
移行後の最終チェック：ADの健康診断と「見えない不具合」潰し
移行直後は問題がなく見えても、数日後に「GPOが当たらない」「ログオンが遅い」「同期がたまに失敗する」といった症状が出ることがあります。最後に以下を押さえると安心です。
- dcdiagのエラーがゼロ（特にDNS/広告/レプリケーション）
- repadminで失敗がない（エラー数が増え続けない）
- SYSVOL/NETLOGON共有が正常（GPOが配布できる）
- イベントログ（Directory Service / DNS Server / DFS Replication）に重大エラーがない
- Azure AD Connectの同期履歴で連続成功している
診断コマンド例：
dcdiag /v
repadmin /replsummary
repadmin /showrepl
nltest /dsgetdc:yourdomain.localよくある失敗例と回避策（現場で刺さるポイント）
- 旧DCを降格せず電源OFF：SRVレコードやメタデータが残り、後から除去が面倒になります。必ず降格して撤去します。
- DNSを単一参照のまま切替：Azure AD ConnectサーバーやアプリサーバーのDNS参照先が旧DCだけだと一斉に不調になります。DNSは複数指定が基本です。
- 新DCを追加しただけで安心：FSMO移行、GC、時刻同期、SYSVOLの健全性まで揃って初めて「置き換えできるDC」になります。
- ホスト名・IP引き継ぎを急ぐ：引き継ぎ工程は事故りやすいので、まずは「新DCで安定稼働」を確認してから実施すると安全です。
まとめ：Azure AD Connectの観点では「ADが健全で到達できること」が最重要
Windows Server 2016から2019へのDC移行で、最終的にホスト名・IPを同一にする要件は実現可能です。ポイントは、新DCを別名・別IPで追加して健全性を作り、FSMO等の役割を移してから旧DCを正しく降格すること。Azure AD Connectについては、DCのOSが変わること自体よりも、DNS・ネットワーク許可・接続先固定の有無が影響要因になります。
手順をフェーズ分けして、各フェーズの合格条件（repadmin/dcdiag/同期成功）を満たしながら進めれば、同期を止めずに安全に移行できます。
コメント