Windows Server 2012 R2 から 2022 への AD・CA・DHCP 移行完全ガイド

Windows Server 2012 R2 の延長サポート終了により、Active Directory（AD）や CA、DHCP を抱えた基盤サーバーの刷新は待ったなしのテーマになっています。この記事では、単一ドメイン環境で 2012 R2 の 3 台構成から Windows Server 2022 へ AD／CA／DHCP をほぼ無停止で移行するための、具体的かつ現実的な手順と注意点をフェーズ別に整理して解説します。

Windows Server 2012 R2 から 2022 へ移行すべき理由

まず前提として、Windows Server 2012 / 2012 R2 は 2023 年 10 月 10 日に延長サポートが終了しており、通常のセキュリティ更新プログラムは既に提供されていません。

オンプレミスでは有償の Extended Security Updates（ESU）を購入することで一部セキュリティ更新を継続できますが、ESU はあくまで「延命措置」であり、恒久的な運用基盤としては Windows Server 2022 などサポート中バージョンへの移行が推奨されています。

特に AD・CA・DHCP といった「認証・証明・アドレス配布」の 3 役割は、インフラ全体の根幹です。障害やゼロデイ脆弱性の影響を最小化するためにも、計画的なリプレースが重要です。

現行構成とゴール構成を整理する

この記事では、以下のような単一ドメイン構成を前提に解説します。

種別	ホスト名	OS	主な役割	物理 / 仮想
現行 DC	DC01	Windows Server 2012 R2	DC（FSMO 保持）+ DHCP	物理
現行 DC	ADC02	Windows Server 2012 R2	追加 DC + CA	仮想
現行 DC	ADC03	Windows Server 2012 R2	追加 DC	仮想

目指すゴールは次のような構成です。

種別	台数	OS	主な役割	ポイント
新規 DC	3 台（物理 1 / 仮想 2）	Windows Server 2022	DC + Global Catalog	FSMO も 2022 に集約
DHCP	2 台	Windows Server 2022	DHCP フェールオーバー	冗長化されたスコープ配布
CA 専用サーバ	1 台	Windows Server 2022	AD CS（CA）	URL とホスト名の継承が鍵
旧 DC	本社 3 台 + Azure DR	Windows Server 2012 R2 など	順次降格・撤去	最終的に全 DC を 2022 へ

全体方針：サイドバイサイド移行が鉄板

AD／CA／DHCP のようなコア役割を一気に切り替えるのはリスクが高く、推奨されません。ここでは次の方針を取ります。

サイドバイサイド移行：新しい Windows Server 2022 を並行導入してから役割を順次移行し、安定を確認して旧サーバーを降格・撤去。
スキーマ拡張は必要だが機能レベルは 2016 が最終：Windows Server 2019 / 2022 では、新しい AD ドメイン／フォレスト機能レベルは追加されておらず、最高レベルは 2016 のままです。
停止時間の最小化：DC はオンライン追加、DHCP はフェールオーバー構成、CA は短時間の切替でダウンタイムを極小化します。

以降は、実際の作業をフェーズに分けて解説します。

移行フェーズの全体像

フェーズ	内容	主な目的	想定停止影響
0	事前バックアップ	万一のロールバックに備える	なし
1	AD ヘルスチェック & 修復	壊れた AD をそのまま 2022 に持ち込まない	なし
2	スキーマ／機能レベル確認	2022 DC 追加の前提条件を整える	なし
3	Server 2022 DC 3 台追加	新基盤の柱を用意する	なし（並行稼働）
4	FSMO 役割移管	論理的な AD の“心臓部”を 2022 に移す	ほぼなし
5	DHCP 移行 & フェールオーバー	IP 配布を冗長化しつつ新サーバーへ移行	短時間の切替のみ
6	CA（AD CS）移行	証明書基盤を専用 2022 サーバーへ	CRL/発行 URL 切替時にごく短時間
7	旧 DC / Azure DR DC の降格・撤去	環境をクリーンに整理	なし（事前に冗長化済み）
8	最終確認 & 監視整備	安定運用へ移行	なし

フェーズ 0：移行前に必ず実施したいバックアップ

まずは「戻れる状態」を作ることが何より重要です。特に CA は一度壊すと復旧が極めて難しいため、以下を最低限確保します。

DC（Active Directory）のバックアップ

すべての DC で システム状態バックアップ を取得（Windows Server Backup やサードパーティ製ツール）
少なくとも FSMO 保持 DC と PDC Emulator は個別にバックアップを確認

CA（証明機関）のバックアップ

CA サーバー（ADC02）では以下を取得します。

certutil -backupdb C:\CABackup\DB
certutil -backupkey C:\CABackup\KEY
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\CABackup\CA.reg

CA データベース
CA の秘密鍵と証明書
CA 設定のレジストリ

これらがあれば、同じ CA 名で新サーバーに復元することができます。

DHCP のバックアップ

DHCP サーバー（DC01）では、PowerShell コマンドレットで設定とリース情報をエクスポートしておくのが簡単です。

Export-DhcpServer -ComputerName DC01 -File C:\Backup\dhcp.xml -Leases -Verbose

このファイルを後で新サーバーにインポートします。

フェーズ 1：AD ヘルスチェックと問題修復

壊れた AD のまま DC を増やしても、問題を複製するだけです。先にヘルスチェックを行い、エラーは可能な限り解消しておきます。

基本的なヘルスチェック

dcdiag /v /c /e /s:DC01
repadmin /replsummary
repadmin /showrepl * /csv &gt; C:\temp\repl.csv
dcdiag /test:dns

dcdiag：各 DC の基本動作や DNS の状態を確認
repadmin /replsummary：レプリケーション遅延や失敗がないか確認
repadmin /showrepl：詳細なレプリケーション状態を CSV で出力し、エラーを洗い出し

ここで出たエラー（名前解決、レプリケーション失敗、時刻同期エラーなど）は、移行前に必ず潰しておきましょう。

SYSVOL 複製方式の確認（FRS → DFSR）

Windows Server 2022 の DC を追加するには、SYSVOL の複製方式が DFSR であることが事実上必須です。FRS のまま残っている場合、先に DFSR への移行を完了させます。

dfsrmig /getglobalstate

出力が 3 (Eliminated) であれば DFSR への切り替えが完了している状態です。もし 0〜2 の場合は、DFS 移行ステップを完了させてから次へ進みます。

フェーズ 2：スキーマ・機能レベルの確認と更新方針

現状の機能レベル確認

Get-ADForest
Get-ADDomain

ForestMode / DomainMode が Windows2012R2Forest / Windows2012R2Domain などになっているはずです。

Windows Server 2019 / 2022 では、新しい機能レベルは提供されておらず、2016 が最も高い機能レベルです。

スキーマ拡張（adprep）

通常は、Windows Server 2022 で最初の DC 昇格を行う際に、ウィザードが自動的に adprep を実行します。権限や接続性の制約がある場合は、2022 のインストールメディアから手動実行も可能です。

adprep /forestprep
adprep /domainprep

実行には Schema Admins / Enterprise Admins 権限が必要です。完了後、イベントログでエラーがないことを確認しておきましょう。ドメイン／フォレスト機能レベルを 2016 に上げるのは、すべての DC が 2016 以上になってからで構いません。

フェーズ 3：新規 Windows Server 2022 DC を 3 台追加

次に、新しい 3 台の Windows Server 2022 を DC として追加します。

事前準備

すべての 2022 サーバーを最新パッチまで更新
IP アドレスと DNS（既存 DC を優先 DNS として指定）を静的設定
ドメインにメンバーサーバーとして参加（コンピューター名/ドメインの変更）

DC 昇格

サーバーマネージャーのウィザードからでも、PowerShell からでも構いません。

Install-ADDSDomainController `
  -DomainName "example.local" `
  -InstallDns `
  -Credential (Get-Credential) `
  -NoGlobalCatalog:$false

昇格完了後、レプリケーション状態を確認します。

repadmin /replsummary

Global Catalog とサイトの確認

新規 DC は すべて Global Catalog を有効にしておくのが無難です。
「Active Directory サイトとサービス」で、サイトとサブネットの紐付けを整理し、新しい DC が適切なサイトに属しているか確認。
クライアントの DNS 設定が、新しい DC の IP を優先・代替として参照するよう順次切替えます。

フェーズ 4：FSMO 役割の安全な移管

AD の論理的な中枢を担う FSMO（操作マスタ）役割は、信頼性の高い 2022 サーバー（できれば物理機）へ集約します。

現在の FSMO 保持サーバー確認

netdom query fsmo

FSMO 移管（PowerShell）

例として、新 DC DC2022-01 にすべて集約する場合：

Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC2022-01" `
  -OperationMasterRole 0,1,2,3,4

0: PDC エミュレーター
1: RID マスター
2: インフラストラクチャマスター
3: スキーママスター
4: ドメイン命名マスター

PDC エミュレーターの時刻同期再設定

PDC エミュレーターはドメイン内の時刻の基準になるため、FSMO を移したあとは新しい PDC で NTP 設定を見直します。

w32tm /config /manualpeerlist:"ntp.example.jp,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time
w32tm /resync

これにより、クライアントの時刻ずれによる Kerberos 認証エラーなどを防ぐことができます。

フェーズ 5：DHCP を 2 台の 2022 サーバーへ移行（フェールオーバー）

新規 DHCP サーバーの準備

新規 2022 サーバー 2 台に DHCP サーバーの役割を追加
インストール後、DHCP 管理コンソールを開けることを確認

旧サーバーから設定とリース情報を移行

旧 DHCP サーバー（DC01）でエクスポートしたファイルを、新 DHCP サーバー 1 台目へコピーしてインポートします。

Import-DhcpServer `
  -ComputerName NewDHCP01 `
  -File C:\Backup\dhcp.xml `
  -BackupPath C:\DHCP-Backup `
  -Leases -Verbose

この時点で、スコープ設定・予約・除外範囲・オプションなどが一通り移行されているか確認します。

DHCP フェールオーバー構成

DHCP 管理コンソールから、スコープを右クリック →「フェールオーバーの構成」で、新 DHCP サーバー 2 台（NewDHCP01 / NewDHCP02）間のフェールオーバーを設定します。

モード：負荷分散（推奨）またはホットスタンバイ
共有シークレット：十分な長さのパスフレーズを設定

構成が完了したら、新 DHCP サーバーを AD で承認し、旧 DHCP サーバーを非承認に切り替えます。

ほぼ無停止での切替えポイント

新旧 DHCP を短時間だけ並行稼働させる場合は、アドレス重複を避けるためスコープ設定を慎重に確認。
実務上は、新 DHCP を承認 → 少し様子を見る → 旧 DHCP を非承認 → サービス停止という流れが安全です。
クライアントはリース更新時に自動的に新 DHCP に切替わるため、大きな停止なく移行できます。

フェーズ 6：CA（AD CS）を Windows Server 2022 専用サーバーへ移行

CA は「壊すと後戻りしづらい」コンポーネントなので、慎重に進めます。Microsoft 公式のガイドラインでも、バックアップ → 新サーバーへ復元 → 古い CA の適切な廃止、という流れが推奨されています。

新規 CA サーバーの準備

Windows Server 2022 を CA 専用サーバーとして構築
AD CS の役割はインストールするが、最初は構成ウィザードを完了させない（「未構成」の状態にしておく）

旧 CA のバックアップ（再掲）

旧 CA（ADC02）で以下を実行します。

certutil -backupdb C:\CABackup\DB
certutil -backupkey C:\CABackup\KEY
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\CABackup\CA.reg

新 CA への復元とサービス開始

新 2022 サーバーに CA 役割を追加（同じ CA 名／階層で構成）。
バックアップした DB・キー・レジストリを新サーバーへコピーし、復元。
サービス起動後、既存の証明書が正しく認識されているか確認。

CDP / AIA（CRL・発行者情報）の継続

既に発行済みの証明書には、既存 CA の CRL URL や AIA URL が埋め込まれています。ここを切ってしまうと、クライアントが失効確認に失敗し、証明書が「有効なのに使えない」状態になります。

もっともトラブルの少ない方法は：

旧 CA のホスト名 / IP を新 CA に再利用する

つまり、旧 CA を停止・降格したうえで、ADC02 という名前と IP アドレスを新 CA サーバーに付け替えるイメージです。これが難しい場合は、以下の方法を組み合わせます。

旧 URL から新 CA へ転送するための CNAME（DNS 別名） を設定
CRL / AIA を配布する Web サイトを共通のホスト名で構成し、どちらの CA からも公開できるようにする
DFS などで CRL 配布ディレクトリを共有

CA コンソール（certsrv.msc）のプロパティ →「拡張」タブで、新しい CDP / AIA の URL を追加し、「今後発行される証明書」に正しい URL が埋め込まれるよう調整しておきます。

テストのポイント

既存証明書の失効操作が正常に行えるか
新規に発行した証明書の「発行元」「CRL 配布ポイント」が期待通りの URL か
クライアントから CRL URL にブラウザでアクセスし、HTTP 200 で取得できるか

フェーズ 7：旧 DC と Azure-DR DC の段階的廃止

新しい 2022 DC が安定稼働し、FSMO 役割も移管済み・DHCP/CA も移行済みになったら、いよいよ旧 DC を降格していきます。

降格前のチェック

netdom query fsmo で、旧 DC に FSMO が残っていないことを再確認。
「サイトとサービス」で、廃止予定 DC が唯一の Global Catalog になっていないか確認。
DNS サーバーとしての役割を持っている場合、新 DC がゾーンデータを正しく複製しているか確認。

降格手順

各 DC ごとに、以下のように「正規の降格」を行います。

Uninstall-ADDSDomainController

ウィザードで「このサーバーをドメインコントローラーから降格する」を選び、指示に従います。

メタデータと DNS の清掃

降格後、「サイトとサービス」から該当サーバーオブジェクトを削除。
DNS に残る古い A レコード / NS レコード / SRV レコードを整理。
必要であれば ntdsutil によるメタデータクリーニングを実施。

Azure-DR サイトの DC も同様に降格し、サイト・サブネット定義を整理します。DR サイトを今後どう設計するか（別の 2022 DC を置くか、オンプレのみとするか）は、このタイミングで見直すとよいでしょう。

フェーズ 8：最終確認と運用フェーズへの移行

すべての DC が Windows Server 2022 になったら、Forest / Domain 機能レベルを 2016 まで引き上げることができます（任意）。

AD 機能レベルの引き上げ

「Active Directory ドメインと信頼関係」コンソール、または PowerShell から実施できます。

Set-ADForestMode -Identity "example.local" -ForestMode Windows2016Forest
Set-ADDomainMode -Identity "example.local" -DomainMode Windows2016Domain

引き上げは元に戻せないため、実施前にバックアップと動作確認（古い OS が残っていないかなど）を再確認してください。

基本動作確認

認証：複数サイト／ネットワークからユーザーがログオンできるか
GPO：クライアントで gpupdate /force 実行後、RSOP や gpresult /h でポリシー適用を確認
レプリケーション：repadmin /replsummary がエラーなしで終了するか
DNS：名前解決・逆引き・SRV レコードが正しく機能しているか
DHCP：新規取得・リース更新・予約の配布状況、フェールオーバー動作
CA：既存証明書の検証と、新規発行の CRL/AIA 埋め込み確認

監視とログ

イベントログ（Directory Service / DNS Server / System / Security）の定期チェック
重要イベント（レプリケーション失敗・DNS エラーなど）を監視ツールやメールで通知
CA ログや CRL 発行失敗も監視対象に加える

よくある“つまずきポイント”と対策

同名・同 IP を新 DC に再利用したい

「ADC03 を一度降格して削除し、その名前と IP アドレスを新 2022 DC に再利用したい」というニーズはよくありますが、次の条件を満たさないとトラブルの元になります。

旧 DC を正しく降格し、レプリケーションが 全 DC に完全に反映されている。
「サイトとサービス」「DNS」「コンピューターアカウント」など、旧 DC 関連オブジェクトの残骸がない（または手動で清掃済み）。

これが不完全だと、重複 SPN や古いメタデータによるレプリケーションエラーが発生します。運用上の安全性を最優先するなら：

一旦 新しいホスト名 で 2022 DC を昇格 → 安定運用を確認
どうしても名前を変えたい場合は、その後で DC の名前変更（netdom computername など）を検討

という手順の方がリスクは低くなります。

DHCP：移行と DC 昇格の順番は？

質問にあるように、「新サーバーで先に DHCP を受け持たせ、その後に DC 昇格する」という順番でも問題ありません。重要なのは：

DHCP サーバーの 承認／非承認 を適切に切り替えること
フェールオーバー構成の動作確認を行ってから旧サーバーのサービス停止に踏み切ること

DC 昇格と DHCP 役割は直接の依存関係は薄いため、現場のメンテナンス時間に合わせて柔軟に順番を調整して構いません。

CA：ホスト名を変えずに移行するメリット

CA のホスト名を旧と同じにすると、次のようなメリットがあります。

既に発行された証明書に埋め込まれた URL（CDP / AIA / OCSP など）をそのまま生かせる
クライアント設定やアプリケーション設定の変更がほぼ不要

代わりに、切替日に新旧サーバーの IP とホスト名を入れ替える作業が発生しますが、トータルの工数・リスクはむしろ下がることが多いです。

チェックリスト：この状態なら切替えてよい

項目	確認内容	ステータス（〇/△/×）
SYSVOL	`dfsrmig /getglobalstate` が 3（Eliminated）になっている
PDC 時刻同期	新 PDC エミュレーターが外部 NTP と同期済み
DNS 冗長化	すべての DC が DNS サーバーとして動作し、クライアントは 2 台以上を参照
DHCP オプション	003（ゲートウェイ）、006（DNS）、015（DNS サフィックス）、042（NTP）などが正しく移行
CA CRL 期限	CRL の有効期限に十分な余裕があり、切替期間中に期限切れにならない
旧 DC の他役割	ファイル共有、プリンタ、アプリケーションなどの役割を別サーバーに移設済み
バックアップ	DC システム状態と CA バックアップからの復旧手順を事前テスト済み

最小停止で切り替えるための実践的なコツ

DHCP：新サーバーをフェールオーバー構成で立ち上げてから旧を非承認にすることで、IP 配布の停止をほぼゼロにできます。
CA：新 CA で CRL を先に発行・公開しておき、旧 CA を停止するタイミングを短時間に絞ります。
DC：旧 DC の電源を短時間オフにして、ログオンや名前解決に問題が出ないか事前の「疑似障害テスト」を行うと安心です。

参考コマンド早見表

:: AD ヘルスチェック
dcdiag /v /c /e /s:&lt;DC名&gt;
repadmin /replsummary
repadmin /showrepl * /csv &gt; C:\temp\repl.csv
dcdiag /test:dns
dfsrmig /getglobalstate

:: FSMO
netdom query fsmo
Move-ADDirectoryServerOperationMasterRole -Identity &lt;新DC名&gt; -OperationMasterRole 0,1,2,3,4

:: DHCP 移行
Export-DhcpServer -ComputerName &lt;旧&gt; -File C:\dhcp.xml -Leases
Import-DhcpServer -ComputerName &lt;新&gt; -File C:\dhcp.xml -BackupPath C:\DHCP-Backup -Leases

:: CA バックアップ
certutil -backupdb C:\CABackup\DB
certutil -backupkey C:\CABackup\KEY
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\CABackup\CA.reg

:: DC 降格
Uninstall-ADDSDomainController

まとめ：安全かつ現実的な移行シナリオ

本記事で紹介したフローを簡潔にまとめると、次のようになります。

AD を事前に健全化し、CA・DHCP を含むバックアップを確実に取得する。
Windows Server 2022 の DC を 3 台追加し、FSMO 役割を集約しつつ DNS / GC / 時刻同期を整える。
DHCP を 2 台の 2022 サーバーに移行し、フェールオーバー構成で冗長化する。
CA を専用の 2022 サーバーに移行し、ホスト名や URL の継承（または CNAME 等）で既存証明書の互換性を確保する。
旧 DC（本社 3 台および Azure-DR DC）を段階的に降格・撤去し、最終的に全 DC を 2022 とする。
必要に応じて機能レベルを 2016 に引き上げ、監視と運用手順を整備して長期安定稼働を実現する。

移行作業そのものは多ステップに見えますが、フェーズごとに「やること」と「ゴール」を明確にして進めれば、現場への影響を最小限に抑えつつ安全に更新していくことができます。これから Windows Server 2012 R2 から 2022 への AD／CA／DHCP 移行を検討している場合は、本記事の手順とチェックリストを自社環境向けにカスタマイズし、標準手順書として整備しておくと、トラブル時の再現性と安心感が大きく向上します。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。