Active Directoryドメインコントローラー移行手順：同じサーバー名・同じIPで新サーバーへ安全に更改（dcdiag/repadmin/robocopy対応）

Windows Serverのハードウェア更改で、既存のドメインコントローラー（DC）兼ファイルサーバーを新筐体へ置き換えたい。しかし利用者側の設定や共有パスを変えたくないため「同じサーバー名・同じIPで切り替えたい」。本記事では、AD健全性確認から降格・昇格、robocopyによるデータ同期、共有/プリント設定の移行まで、事故を起こしにくい手順を具体的に整理します。

前提：なぜ「同名・同IP」の置き換えは事故りやすいのか

ドメインコントローラー（DC）を新ハードへ移行するだけなら、通常は「新DCを追加→レプリケーション安定→旧DCを降格→廃止」の流れで十分です。ところが「旧サーバーと同じホスト名・同じIPを新サーバーに付け直す」要件が入ると、以下の落とし穴が増えます。

• 同名・同IPは同時に存在できない（DNS/NetBIOS/ADコンピューターアカウント/ARPなど、多方面で衝突します）
• DC昇格後の“名前変更”は推奨されないため、切り替えのタイミング設計が重要
• ファイルサーバー要素（共有定義、共有権限、NTFS ACL、プリント設定、サービス依存）がADとは別に存在する
• “切替日”にやることが多くなりがちで、手順漏れが起きやすい

結論として、質問の提案である「データは事前同期→旧DCを降格→旧を退避（別名/IPまたは遮断）→新を旧名/IPへ変更→DC昇格」は大筋で妥当です。さらに安全性を上げるために、健全性確認ポイントと退避手順、共有/プリントの移行を「工程として明文化」して進めるのが肝になります。

まず最初にやること：役割の棚卸し（ここを飛ばすと詰みます）

「DC兼ファイルサーバー」という表現でも、実環境では追加の役割を持っていることが少なくありません。まず各サーバーについて、最低限以下を棚卸しします。

項目	確認ポイント	確認例
ADの役割	DCか、GCか、DNSサーバーか	AD DS / DNS のインストール状況、Sites and Services
FSMO	どのDCがFSMOロールを保持しているか	netdom query fsmo
SYSVOL	DFSRか（古い環境はFRS残存の可能性）	イベントログ、dfsrdiag、ドメイン機能レベル
ファイル共有	共有数、共有パス、共有権限、NTFS ACL、Abe/オフラインファイルなど	共有一覧、アクセス権の棚卸し
プリント	プリントサーバー兼務、キュー/ドライバー数	Print Management（印刷の管理）
その他のサービス	DHCP / CA（AD CS）/ NPS / ADFS / WSUS / アプリ等	役割と機能、サービス一覧

この棚卸しで「実はDHCPも載っていた」「証明書局（AD CS）が同居していた」などが出てくると、手順は別物になります。本記事は“DC＋ファイル（＋必要ならプリント）”を中心に、安全な置き換え方を扱います。追加役割がある場合は、その役割の移行（別記事級）を先に計画へ入れてください。

全体方針：1台ずつ置き換え、毎回“健全性100%”を通過してから次へ

DCが4台ある環境では、1台ずつ順番に更改するのが定石です。特に同名・同IPを使う場合は、1台の切り替えが終わってから次へ進みます。

フェーズ	目的	重要なチェック
事前準備	現状把握と、切替の失敗要因を潰す	FSMO/GC/DNS、共有定義、バックアップ
事前同期	切替時のコピー量を最小化	robocopyで複数回（初回＋差分）
旧DC降格	ADから“DCとしての役割”を外す	dcdiag/repadminで問題なし、FSMO移動済
旧の退避	同名・同IPの衝突を回避	別名/別IPへ変更またはネットワーク遮断
新を旧名/旧IP化	クライアント影響を最小化	DNS更新、コンピューターアカウント整合
新DC昇格	ADレプリケーションへ復帰	SYSVOL共有、レプリケーション正常
ファイル/プリント切替	共有や印刷を新へ移す	共有定義、アクセス権、最終差分同期
安定化・廃止	監視と不要オブジェクトの整理	DNS/NSレコード、サイト/サーバーオブジェクト

失敗率を下げる“健全性確認”の入れ方（最重要）

「一応動いているから次へ進む」が一番危険です。工程の合間に“合格条件”を置き、合格してから次へ進みます。

合格条件の例（最低限）

• 降格前：レプリケーション遅延やエラーがなく、ADが健全である
• 降格直後：旧DCがDCとして残っていない（メタデータが残留していない）
• 新DC昇格後：SYSVOL共有が見える、レプリケーションが収束している

よく使う確認コマンド

目的	コマンド例	見どころ
DC診断	dcdiag /v	致命的エラーがないか、DNS関連の警告がないか
レプリケーション概要	repadmin /replsummary	Failsが0、遅延が常識的範囲
パートナー別の詳細	repadmin /showrepl	直近の結果がSuccessで揃っているか
FSMO確認	netdom query fsmo	降格対象がFSMOを持っていない状態にする
DNS登録確認	nslookup 旧サーバー名	A/PTRが期待通りか、古いIPが残っていないか

特に「repadminのFailsがゼロ」「dcdiagで致命傷なし」は、切替作業の保険として非常に効きます。運用現場では“軽微な警告はあるが問題ない”が積み重なって切替日に爆発するケースが多いので、可能なら事前に警告要因を潰しておきます。

FSMOロール：保持DCは“最後”に回し、降格前に必ず移動

降格対象のDCがFSMOロールを保持している状態で降格しようとすると、手順が崩れます。原則は以下です。

• FSMOを持つDCは最後に更改（もしくは更改対象から外す）
• どうしても先に更改するなら、降格前に別DCへFSMOを転送

FSMOの移動はGUIでも可能ですが、運用ログとして残しやすいPowerShellを例にします（実行は権限と慎重さが必要です）。

netdom query fsmo

# 例：FSMOをDC02へ移す（実行前に必ず移行先の健全性を確認）

Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
-OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster -Confirm:$false

移動後に再度 netdom query fsmo で保持先が変わったことを確認し、その上で降格へ進みます。

ファイルサーバー移行の考え方：「データ」と「共有定義」は別物

DCの置き換えだけならADの手順が中心ですが、ファイルサーバーを兼ねている場合は「データのコピー」だけでは移行完了になりません。共有が同じ見え方になって初めて、利用者影響が最小化されます。

移行対象を分解する

• データ本体：フォルダ/ファイル、NTFS ACL、所有者、監査（必要なら）
• 共有定義：共有名、共有パス、共有権限、オフライン設定、列挙ベースアクセス（ABE）など
• 依存要素：ドライブマッピング、ログオンスクリプト、GPO、DFS名前空間（使っている場合）

データコピー：robocopyは“複数回”が基本（初回＋差分＋最終）

容量が大きいほど、切替日に一発勝負をすると終わりません。初回は業務時間外に走らせ、切替前夜に差分、切替直前に最終差分、という形が現実的です。

タイミング	目的	ポイント
初回コピー	大部分のデータを移す	時間がかかっても良い。ACL込みで確実に
差分同期（1回目）	更新分を追従	ログを見てエラーを潰す
最終同期	切替直前に差分ゼロへ	旧共有を停止/利用者を追い出してから実施

robocopyのオプションは環境要件に左右されますが、よく使う考え方を表にまとめます（盲目的にコピペせず、テスト共有で必ず検証してください）。

要件	オプション例	意図
ACL/所有者/監査も含めたい	/COPY:DATSOU	Data/Attributes/Timestamps/Security/Owner/Auditを保持
ミラーリングしたい	/MIR	削除も反映（誤削除リスクがあるので最終同期で慎重に）
再試行を抑えたい	/R:1 /W:1	止まりにくくする（ログで失敗を拾う運用が前提）
ログを残したい	/LOG:xxx.log /TEE	証跡とトラブルシュート用
ジャンクションを避けたい	/XJ	ループや意図しないコピーを防ぐ
並列コピーしたい	/MT:16	速度改善（サーバー/ストレージ負荷に注意）

実務では次のような形が多いです。

robocopy "\\OLD\ShareRoot" "D:\ShareRoot" /MIR /COPY:DATSOU /R:1 /W:1 /MT:16 /XJ /TEE /LOG:D:\logs\robocopy_1st.log

最終同期（切替直前）は利用者の書き込みを止めた状態で行います。書き込みが止められないと、差分が永遠に発生して「終わらない移行」になりがちです。

共有定義の移行：方法を決めてからデータを移すと楽

共有が多い環境は「共有定義の復元」がボトルネックになります。代表的なやり方を整理します。

方法	メリット	注意点
手動で再作成	小規模なら確実	数が多いとミスが増える
PowerShellで棚卸し→再作成	再現性が高い、レビューしやすい	共有権限/ABEなど細部の取り込み設計が必要
レジストリで共有定義を移す	共有が多い場合に早い	環境差分で事故ることがあるため検証必須
DFS（名前空間）で吸収	将来の更改が楽、同名要件を緩和できる	今回「同名・同IP固定」要件が強いと採りにくい

「同名・同IP」を狙う場合でも、将来的な更改のためにDFS名前空間へ寄せるのは有効な改善案です。今回は要求仕様として同名・同IPを維持する前提で、現行共有の再現を主眼にします。

共有一覧の棚卸し例です。

# 共有一覧（特殊共有を除く）
Get-SmbShare | Where-Object {$_.Name -notmatch '^\w\$$'} | 
  Select-Object Name, Path, Description, FolderEnumerationMode, CachingMode |
  Export-Csv "D:\logs\shares.csv" -NoTypeInformation -Encoding UTF8

新サーバー側での再作成（例）です。

# 例：共有作成（詳細は shares.csv を見ながら）
New-SmbShare -Name "DATA" -Path "D:\ShareRoot\DATA" -FullAccess "DOMAIN\FileAdmins" -ChangeAccess "DOMAIN\Users"

共有権限は「NTFS ACL」と別管理です。両方が一致しないと、移行後に“見えるのに開けない”や“開けるべきでない人が開ける”が起きます。移行設計では、共有権限はなるべくシンプル（管理者フル＋利用者変更、細かい制御はNTFS）に寄せると事故率が下がります。

「同名・同IP」を成立させるための実務ポイント

同名・同IPで置き換える場合のキモは、旧サーバーを“衝突しない状態”にしてから新サーバーへ名寄せすることです。順番を間違えると、DNSやADの整合が崩れ、原因追跡が難しくなります。

安全な順番（基本形）

• 新サーバーは一時的な別名・別IPで構築し、ドメイン参加（まだDCにしない）
• データは事前にrobocopyで複数回同期
• 旧サーバー（DC）を降格（必要ならDNS役割も整理）
• 旧サーバーを別名＋別IPへ変更、もしくはネットワーク切断
• （必要なら）旧サーバーのコンピューターアカウントやDNSレコードの整理
• 新サーバーを旧名へリネームし、旧IPへ変更
• 新サーバーをDCへ昇格
• 健全性確認（dcdiag/repadmin）合格後に、ファイル共有・プリントを切替

「旧を降格したのに、名前が使えない」原因の典型

症状	原因	対処
新サーバーのリネーム/参加で「同名が存在」	旧サーバーのコンピューターアカウントが残っている	旧が完全に退避済みであることを確認し、AD上のコンピューターアカウントを削除/リセットして整合を取る
名前解決が旧IPのまま	DNSのA/PTRが古い、レプリケーション未収束	DNSレコード整理、repadminで収束確認、TTLも考慮
クライアントが旧へ繋がり続ける	ARPキャッシュやセッション、DNSキャッシュ	切替時に旧のNICを抜く/シャットダウン、必要に応じてキャッシュクリア

特に重要なのは、“旧が本当にネットワーク上から消えているか”です。旧の電源を入れたまま、同名・同IPの新を立てると、障害が複合して状況が分からなくなります。切替当日は、旧サーバーのNICを抜く、ポートをshutdownする、VLANから外すなど、物理的/ネットワーク的に衝突しない状態を確実に作るのが安全です。

手順例：DC兼ファイルサーバーを同名・同IPで置き換える（1台分）

ここからは、1台を置き換える具体例です。環境差分が出やすいので、実行前にテスト環境または検証時間を確保し、ログを必ず残してください。

ステップA：事前準備（当日に慌てないための仕込み）

• バックアップ：旧サーバーのフルバックアップ（可能ならシステム状態も）。ファイル領域も含め復旧できる形にする
• 役割確認：FSMO、GC、DNS、その他サービス（DHCP/CAなど）
• AD健全性確認：dcdiag / repadmin を実施し、エラーを事前に解消
• 共有棚卸し：共有名、パス、権限、NTFS ACL、利用者影響（オフラインファイル等）
• 切替方式の決定：停止時間、最終同期のタイミング、切替手順書（担当分担）

ステップB：新サーバーを「仮の名前・仮のIP」で構築（まだDCにしない）

• 新サーバーをインストールし、Windows Update/ドライバー/セキュリティ設定を適用
• 仮のホスト名（例：NEW-DCFS01）、仮のIPでネットワーク設定
• ドメイン参加（メンバーサーバーとして）
• ファイル用ボリューム/ドライブレターを本番構成に合わせる（共有パスを作りやすい形に）

ここで重要なのは、旧名へ変える前に“データの大部分”を済ませておくことです。

ステップC：robocopyで初回同期→差分同期（複数回）

• 初回同期：時間がかかってもよいので確実に
• 差分同期：切替前夜にもう一度
• ログでエラー（アクセス拒否、パス長、ファイルロック等）を必ず潰す

ファイルロックが多い共有は、最終同期前に利用者調整（アナウンス、セッション切断）が必要です。移行作業は「技術」より「段取り」で決まる部分が大きいです。

ステップD：旧DCがFSMOを持っていないことを確認（必要なら移動）

netdom query fsmo

降格対象がFSMOを持っている場合は、事前に別DCへ移します（前述）。

ステップE：旧DCを降格（Graceful demotion）

GUI（サーバーマネージャー）でも良いですが、操作ログが残しやすいPowerShell例です。実行は管理者権限で行い、事前に「他DCが健全」「DNSやGCが不足しない」ことを確認してください。

# 例：旧DCを降格（状況によりパラメータは調整）
Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartitions -ForceRemoval:$false

降格後は再起動が入ります。再起動後に次を確認します。

• 旧サーバーが「DC」ではなくなっている（AD DSが外れている）
• AD Sites and Services や DNS に旧DCとしてのオブジェクトが不整合に残っていない
• 他DCで repadmin /replsummary を実施し、問題がない

ステップF：旧サーバーを退避（別名・別IP、またはネットワーク切断）

同名・同IPを使うための核心です。旧サーバーは、次のいずれかで確実に衝突を回避します。

• 推奨：ネットワーク切断（NIC無効化、ケーブル抜線、スイッチポートshutdown、隔離VLANなど）
• 次点：別名＋別IPへ変更し、旧名・旧IPを解放する

「念のため旧は電源オンで残す」場合でも、同一ネットワークに居続けるのは危険です。必ず衝突しない形にします。

ステップG：DNS/ADの残骸を整理（必要な場合のみ）

環境によっては、旧名のAレコードやコンピューターアカウントが残り、新サーバーが旧名を名乗れないことがあります。旧が確実に退避されているのを確認したうえで、必要に応じて整理します。

• DNS：旧名のA/PTRが古いIPを向いていないか確認し、必要なら削除/更新
• AD：旧サーバーのコンピューターアカウントが残っている場合、削除またはリセット

この整理をするときは、誤って別用途の同名オブジェクトを消さないよう、対象を二重確認します。

ステップH：新サーバーを「旧サーバー名・旧IP」に変更（昇格前に実施）

DCは昇格後にリネームするより、昇格前に旧名へ揃えるのが基本です。

• 新サーバーのホスト名を旧名へ変更（例：DCFS01）
• IPアドレスを旧IPへ変更
• 再起動
• DNS登録が新IPで正しく行われることを確認

# 例：ホスト名変更（実行後に再起動が必要）
Rename-Computer -NewName "DCFS01" -Restart

# IP変更は環境依存のためGUIまたはNetTCPIPで設定し、再起動後に確認

この時点で、クライアントの名前解決が新サーバーへ向くようになります。切替の影響範囲が大きいので、メンテナンス時間に実施し、想定外のアクセスが来ないよう事前告知を行います。

ステップI：新サーバーをDCへ昇格（DNS/GCの要否を設計どおりに）

新サーバーをDCとして追加し、既存DCからレプリケーションさせます。既存構成に合わせてDNSサーバーやGCを付与します。

# 例：AD DS役割インストール
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# 例：ドメインに追加DCとして昇格（詳細パラメータは環境に合わせて調整）

Install-ADDSDomainController -DomainName "example.local" -InstallDns:$true -NoGlobalCatalog:$false

昇格後は、SYSVOLとNETLOGON共有が見えること、repadmin/dcdiagで合格を確認してから次へ進みます。

ステップJ：健全性確認（合格してからファイル切替へ）

• dcdiag /v を実行し、致命的エラーがない
• repadmin /replsummary のFailsが0
• イベントログ（Directory Service / DFS Replication / DNS Server など）に重大エラーが連続していない
• （DNS併設なら）ゾーンが正しくレプリケーションされ、名前解決が期待通り

ここで問題が出た場合、焦ってファイル切替へ進むと“ADも共有も両方壊れる”最悪のパターンになります。まずAD側を正常化してから、共有切替へ移ります。

ステップK：ファイル共有の最終同期→共有定義を適用→動作確認

最終同期は、旧共有への書き込みを止めてから実施します。

• 利用者へアナウンス（書き込み停止時間）
• 必要に応じてSMBセッションの整理（開きっぱなしのファイルを解放）
• robocopy最終同期
• 共有定義の再作成（共有名/共有権限）
• 主要ユーザー・主要パスで読み書きテスト（権限の確認）

切替確認の観点をチェックリスト化しておくと、漏れが激減します。

チェック項目	確認内容	OKの判断
共有パス	\\サーバー名\共有名 が開く	主要共有がすべて参照できる
権限	閲覧のみ/編集可の境界が正しい	想定ユーザーでテストし差異がない
速度	体感速度の急低下がない	ピーク時を想定して問題ない
ログ	SMB/セキュリティログの異常	大量のアクセス拒否が出ていない

プリントサーバーも兼務している場合：printbrm.exeでまとめて移行

プリントサーバーは、キュー・ドライバー・ポートなどを手作業で再現するとミスが出がちです。Windowsの移行ツールを使うと再現性が上がります。

• 旧サーバーでエクスポート
• 新サーバーでインポート
• クライアント側が参照しているサーバー名が同一なら、基本的に再設定不要で動作しやすい

# 例：旧でエクスポート
printbrm.exe -b -f D:\backup\printers.printerExport

# 例：新でインポート
printbrm.exe -r -f D:\backup\printers.printerExport

ドライバー互換や署名要件（特に新しいWindowsクライアント）で詰まることがあるため、主要部署のプリンターは事前にテスト印刷まで確認しておくと安全です。

4台あるDCをどう回すか：おすすめの順番

4台のDCがある場合、順番を誤ると「気づいたらGC不足」「DNSの参照先が偏る」などが起きます。一般的に次の考え方が安全です。

• まずFSMOを持っていないDCから1台ずつ更改
• 各回でレプリケーションが正常であることを確認
• 最後にFSMO保持DCを更改し、必要なら別DCへFSMOを移動してから降格

また、複数サイト（拠点）がある場合は、サイト間レプリケーションの遅延を考慮して、切替の合間を十分に取り、repadminで収束を確認してから次へ進めます。

“同名・同IP”に固執する前に知っておきたい代替案（将来の更改が楽になります）

要件として同名・同IPが必須でも、将来的な運用改善として次の選択肢は価値があります。

• DFS名前空間（推奨）：共有パスを \\domain.local\Share のように抽象化し、次回からサーバー名に依存しない
• 別名（CNAME）運用：実体サーバー名は変えても、利用者向けの参照名だけ維持する（ただしKerberosやSPN設計が絡む）
• DCとファイルサーバーの分離：セキュリティと保守性が上がり、障害切り分けがしやすい

ただし、今回のように「既存運用を変えずに置き換えたい」局面では、まずは同名・同IPでの安全な更改を成功させ、その後に段階的に改善するのが現実的です。

よくあるトラブルと対処（現場で詰まりやすい順）

レプリケーションが不安定なまま切替日を迎える

対処：切替手順を始める前に、repadminのFailsが0になるまで原因を潰します。DNSエラー、時刻ズレ、サイトリンク設定、ファイアウォールなどが典型です。直前に無理に進めず、健全性が担保できないなら切替を延期したほうが被害が小さくなります。

新サーバーが旧名を名乗れない（同名コンピューターアカウント問題）

対処：旧がネットワークから確実に退避されていることを確認してから、AD上の旧コンピューターアカウントを削除/リセットします。退避が不十分なまま整理すると、旧が復帰して暴れる原因になります。

DNSが旧IPを返し続ける

対処：DNSレコードの更新と、レプリケーション収束を確認します。クライアント側はDNSキャッシュを持つので、切替直後は一時的な名前解決のブレが起きます。重要ユーザーには「一度ログオフ/再起動」「ipconfig /flushdns」などを案内できると復旧が早いです。

共有は開くが権限がズレる

対処：共有権限とNTFS ACLを分けて確認します。robocopyでACLをコピーしていても、共有権限が不足しているとアクセス拒否になります。移行後に大量のアクセス拒否が出る場合は、共有権限の設計が原因のことが多いです。

切替当日の“最低限の進行表”サンプル

当日に迷わないために、最小構成の進行表を置いておきます。実際は環境に合わせて担当と時刻を埋めてください。

順序	作業	完了条件	ロールバック観点
1	切替開始アナウンス（共有書き込み停止）	利用者が作業停止	延長/延期の判断基準を明記
2	旧DC降格	降格完了・再起動後にDCでない	降格失敗時の復旧手順
3	旧をネットワーク退避	旧名・旧IPが解放	衝突回避のため確実に隔離
4	新を旧名/旧IPへ変更	名前解決が新へ向く	IP重複がないこと
5	新DC昇格	dcdiag/repadmin合格	昇格失敗時の切り戻し
6	最終robocopy同期	差分が収束	コピー失敗ログの扱い
7	共有定義/権限の適用	主要共有の読み書きOK	共有公開のタイミング管理
8	プリント移行（該当時）	主要キューでテスト印刷OK	ドライバー問題の切り分け
9	切替完了アナウンス	問い合わせ窓口の準備	監視強化（イベント/性能）

まとめ：提案フローは正しいが、「健全性確認」と「退避の確実さ」が成功を決める

「先にrobocopy→旧DC降格→旧を別名/IPへ退避→新を旧名/IPへ変更→DCへ昇格」という方向性は、同名・同IPを維持したい要件に対して合理的です。成功率を上げる鍵は、

• 工程の合間に dcdiag / repadmin を入れて、合格してから次へ進む
• FSMO保持DCは最後、降格前にロール移動
• ファイルサーバー移行は、データ（robocopy）と共有定義（共有名/権限）を分けて設計
• 同名・同IPのために、旧を確実に退避（衝突ゼロ）してから新へ名寄せ

この4点を守るだけで、同名・同IPの置き換えでも“よくある事故”をかなり減らせます。次回以降の更改を見据えるなら、切替後にDFS名前空間などの改善を段階的に入れていくのがおすすめです。