Windows Server 2019 ドメインコントローラー追加と2008 R2降格手順｜フォレスト機能レベル・DHCP/DNS移行まで

Windows Server 2008 R2/2012 R2 で運用中の Active Directory に Windows Server 2019 のドメイン コントローラー（DC）を追加し、旧 2008 R2 DC（DHCP/DNS あり）を安全に降格・撤去するための実務手順を、つまずきやすい「機能レベル」と「SYSVOL（DFS-R）」を軸にまとめます。

想定シナリオ（現状）とゴール（到達点）

本記事で扱うケースは、現場でよくある「段階的に新DCへ置き換える」パターンです。

• 現状：2008 R2 DC（主：DNS/DHCPあり）＋ 2012 R2 DC（副）でドメイン運用
• やりたいこと：Windows Server 2019 DC を追加 → 役割やサービスを移行 → 旧 2008 R2 DC を降格して撤去
• 困りごと：ドメイン機能レベルは上げたつもりでも Get-ADForest が Windows2003Forest のまま、2019 の昇格チェックで「フォレスト機能レベルが足りない」と止まる

結論から言うと、最大の落とし穴は「ドメイン機能レベル」と「フォレスト機能レベル」の混同です。2019 DC の追加前提として、フォレスト機能レベルが 2008 以上になっていないと、昇格前提チェックで止まります。

まず押さえる：ドメイン機能レベルとフォレスト機能レベルは別物

「ドメインを 2008 に上げた」と言っても、それがドメイン機能レベルの話だけだと、フォレスト機能レベルは上がりません。ここを取り違えると、まさに今回のような状況になります。

項目	何を意味する？	確認コマンド	GUIの確認場所
フォレスト機能レベル	フォレスト全体の機能レベル（全ドメインに影響）	Get-ADForest	Active Directory ドメインと信頼関係（Raise Forest Functional Level）
ドメイン機能レベル	特定ドメインの機能レベル（そのドメインに影響）	Get-ADDomain	Active Directory ユーザーとコンピューター（Raise Domain Functional Level）

ポイントはシンプルです。

• Get-ADForest が出しているのはフォレスト機能レベル
• ドメイン機能レベルは Get-ADDomain 側で見る
• 2019 DC の追加前に、フォレスト機能レベルが 2008 以上になっている必要がある

「反映待ち？」と思ったときの実務判断
多くの場合、伝播待ちではなく「ドメイン機能レベルだけ上げて、フォレスト機能レベルを上げていない」が原因です。特に、昇格チェックで止まる場合は“待てば直る”ケースは少なく、設定が不足していることが多いです。

2019 DC 追加前の必須要件チェック（ここが本命）

作業に入る前に、追加要件を満たしているかを機械的にチェックします。ここを飛ばすと、昇格時に詰まって原因調査で時間が溶けます。

チェック項目	最低ライン（実務目線）	主な確認方法	満たしていない場合
フォレスト機能レベル	Windows Server 2008 以上	Get-ADForest | select ForestMode	フォレスト機能レベルを引き上げる
ドメイン機能レベル	Windows Server 2008 以上	Get-ADDomain | select DomainMode	ドメイン機能レベルを引き上げる
SYSVOL レプリケーション	DFS-R（FRS では不可／非推奨）	レジストリ / dfsrmig	DFS-R へ移行して完了させる
ADレプリケーション健全性	エラーなし（致命的な失敗がない）	dcdiag / repadmin	先に原因を解消（DNS/複製/権限）

フォレスト／ドメイン機能レベルの確認コマンド

Get-ADForest | Select-Object ForestMode
Get-ADDomain | Select-Object DomainMode

表示例の読み方：

• ForestMode : Windows2003Forest → フォレストが 2003 のまま（2019 DC 追加前提で止まりやすい）
• DomainMode : Windows2008Domain → ドメインは上がっているが、フォレストが上がっていない可能性

SYSVOL が DFS-R かの確認（FRS なら先に移行）

Windows Server 2019 を DC として追加する前に、SYSVOL が DFS-R で複製されていることが重要です。確認方法はいくつかありますが、現場で手早いのは次のどちらかです。

方法A：レジストリ（LocalState）で判定

• 次のキーの LocalState を確認

HKLM\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState

• 3（ELIMINATED） なら DFS-R 移行完了

方法B：dfsrmig の状態で判定

dfsrmig /getmigrationstate

「All domain controllers have migrated successfully to the global state (‘Eliminated’).」のように、全DCが最終状態に到達していればOKです。

作業前の“儀式”：健全性チェック（失敗率を下げる）

DC追加や降格は、根本に「DNS」や「複製」の問題があると簡単に転びます。作業前に必ず健康診断を通しておきます。

目的	コマンド	見るポイント
DCの総合診断	dcdiag /v	DNS/Advertising/FRS・DFSR/Replication 関連の致命的エラーがない
複製状況の確認	repadmin /showrepl repadmin /replsum	失敗が継続していない、エラーが収束している
GPO配布の基盤確認	net share	SYSVOL と NETLOGON の共有が存在
クライアント側の到達性	gpupdate /force	GPO更新が通り、SYSVOL参照で転ばない

バックアップについての実務メモ
DC入れ替え作業は「戻せる状態」が心理的にも作業的にも重要です。システム状態バックアップ、VMならスナップショットに頼り切らず、復旧手順（どこまで戻せるか）も含めて準備しておくと事故が減ります。

機能レベルを正しく引き上げる（フォレストが上がっていない人向け）

Get-ADForest が Windows2003Forest のままなら、フォレスト機能レベルを引き上げます。実務的にはGUI操作が分かりやすく、手戻りが少ないことが多いです。

引き上げの順序（ここを間違えると詰まる）

• 先にドメイン機能レベルを上げる（対象が単一ドメインでも順序は同じ）
• すべてのドメインが要件を満たしてから、最後にフォレスト機能レベルを上げる

GUIでの確認・変更（現場で確実）

• ドメイン機能レベル：Active Directory ユーザーとコンピューター → ドメイン右クリック →「ドメイン機能レベルを上げる」
• フォレスト機能レベル：Active Directory ドメインと信頼関係 → ルート右クリック →「フォレスト機能レベルを上げる」

注意：機能レベル引き上げは原則として“戻せない”
互換性（古いOS・古い機能の必要性）が残っていないか、最低でも「古いDCが残っていない」「古いアプリ要件がない」を確認してから進めます。

SYSVOL が FRS の場合：DFS-R へ移行して完了させる

SYSVOL が FRS のままだと、後工程で詰まる可能性が高いです。移行は段階方式（Prepared → Redirected → Eliminated）で進めます。

状態	意味	実施コマンド例	実務ポイント
Prepared	DFS-R の準備が整う	dfsrmig /setglobalstate 1	到達確認（全DCが同状態になるまで待つ）
Redirected	参照先が DFS-R 側へ切り替わる	dfsrmig /setglobalstate 2	このタイミングでポリシー配布の影響を観察
Eliminated	FRS を完全廃止（最終）	dfsrmig /setglobalstate 3	ここまで到達して初めて“完了”

各段階で次を叩いて、全DCが同じ状態に到達したことを確認します。

dfsrmig /getmigrationstate

2019 DC 追加は「新規サーバー参加→昇格」が推奨（adprep手動は原則不要）

2019 DC を追加する方法は大きく2つありますが、現場での推奨は方式B（新規サーバーを追加して昇格）です。

方式	概要	メリット	注意点
方式A：インプレースアップグレード	既存DCをOSアップグレードして延命	サーバー台数を増やさない	失敗時の影響が大きい／手動 adprep が絡むことがある
方式B：新規 2019 をドメイン参加→昇格	新しい2019を追加し、後から旧DCを降格	切り戻ししやすい／構成が整理される	ネットワーク/DNS設定ミスで詰まりやすい

方式Bでは、一般的に Server Manager（または PowerShell）での昇格手順の中にadprep 相当の処理が統合されています。つまり、条件が整っていて権限が足りていれば、手動で adprep を叩かなくても進むことが多いです。

昇格前にやるべき 2019 側の準備

• OS更新（最新の累積更新まで適用できる範囲で適用）
• 固定IP、DNS サーバー設定（既存DCのDNSを参照する）
• 時刻同期（ドメイン参加後は通常自動だが、極端にズレていると参加に失敗する）
• サーバー名確定（後で変えるのは面倒）

昇格後に最低限チェックすること

• dcdiag と repadmin で致命的エラーがない
• net share で SYSVOL/NETLOGON が共有されている
• DNS マネージャーで AD統合ゾーンが見える／複製されている

昇格後の中核作業：FSMO移行・GC・時間同期を整える

2019 DC が追加できたら、次に「そのDCが中核になれる状態」を作ります。特に、旧 2008 R2 DC を撤去するなら、FSMO役割をどこに置くかは必須検討です。

役割（FSMO）	影響が出やすい場面	移行の考え方（実務）
Schema Master	スキーマ更新、製品導入	基本は新しい主力DCへ
Domain Naming Master	ドメイン追加/削除	基本は新しい主力DCへ
PDC Emulator	時刻同期、パスワード変更反映、アカウントロック	最重要。撤去予定DCに残さない
RID Master	RID払い出し（大量作成時）	新しい主力DCへ
Infrastructure Master	参照整合性（環境により）	新しい主力DCへ

PowerShell でまとめて移行する例です。

# 例：すべてのFSMOを新DCへ移行
Move-ADDirectoryServerOperationMasterRole -Identity "NEW2019DC" -OperationMasterRole 0,1,2,3,4

移行後は次で配置を確認します。

netdom query fsmo

時間同期（PDC）も忘れずに
ドメインの時刻はPDCエミュレーターが要です。外部NTPへ同期させる設計（または上位時刻源）になっているか、旧DC撤去前に整理しておくと認証系トラブルが減ります。

DHCP移行（2008 R2 → 2019）：止めどころまでセットで考える

旧 2008 R2 DC に DHCP が載っている場合、DC降格の前に DHCP を移します。DHCP は「動くように移す」だけでなく、旧DHCPが残って二重配布しないように止めるところまでがワンセットです。

移行の全体像

• 旧 DHCP の設定をエクスポート
• 新 2019 に DHCP 役割を追加し、インポート
• 新DHCPを AD に承認（Authorize）
• 旧DHCPを停止・無効化（必要なら AD から承認解除）
• DHCP オプション（特に DNS）を更新して、クライアントを新DNSへ誘導

2008 R2 からの移行で使いやすい：netsh export/import

2008 R2 側でエクスポート：

netsh dhcp server export C:\dhcp-export.txt all

2019 側でインポート：

netsh dhcp server import C:\dhcp-export.txt all

その後、新DHCPを承認します（GUIでも可）。
DHCP を AD 承認する作業を忘れると、起動していても配布できないケースがあります。

移行時に更新必須になりやすい DHCP オプション

オプション	名前	見直しポイント
003	ルーター	ゲートウェイが変わる環境なら更新
006	DNS サーバー	旧2008 DCのIPを外し、新DC（2019/2012R2）へ
015	DNS ドメイン名	サフィックスが適切か確認

“移行したのに旧DHCPが自動で止まらない”はよくある
旧DHCPサービスが動いたままだと、セグメントや中継の状況次第で二重配布が発生します。移行確認が取れたら、旧サーバー側はDHCPサービス停止＋無効化まで実施して事故を防ぎます。

DNS移行・整理：AD統合ゾーンでも“残骸”は片付ける

DNS が AD 統合（Active Directory 統合ゾーン）であれば、基本的には新DC側にもゾーン情報が複製されます。ただし、旧DC降格後も DNS 管理上の参照（NS）や古いレコードが残り、見た目や運用で気持ち悪い状態になりがちです。

旧DC撤去前に確認したいDNSのポイント

• 新DCが DNS サーバーとして機能している（名前解決できる）
• 正引き／逆引きゾーンが新DC側から見える（複製されている）
• 条件付きフォワーダー（Conditional Forwarder）がある場合、ADに保存されているか（サーバーローカル設定のままだと移らない）

降格後に残りやすい“DNSの残骸”と対処

残りやすいもの	どこに出る？	対処の基本
旧DCのホスト（A）レコード	正引きゾーン	不要なら削除（静的設定の参照がないか確認）
_msdcs 配下の CNAME など	_msdcs.ゾーン	降格済みDCの参照なら整理
ゾーンのネームサーバー（NS）に旧DCが残る	ゾーンのプロパティ	ゾーンごとにNSから旧DCを削除

「ネームサーバーが削除できない／残り続ける」問題の実務解決

DNSマネージャーで、ゾーンのNSが旧DCのまま残っているケースはかなり多いです。整理するなら、次の流れが確実です。

• DNS マネージャーで 正引き参照ゾーン を開く
• 対象ゾーンを選び、右側に出る 「ネーム サーバー」（またはゾーンのプロパティ → 「ネーム サーバー」タブ）を開く
• 降格した旧DC を選択して削除
• これを ゾーンごとに 実施する（正引き／_msdcs／必要なら逆引きも）

残っていても即障害になるとは限りませんが、運用保守や監査の観点で「不要な参照」は消しておく方が安全です。

旧 2008 R2 DC を降格・撤去する手順（最後にやる）

旧DCの降格は、手順全体の中では“最後の最後”です。焦って先に降格すると、DNS/DHCP/FSMO のどれかが旧DC依存のまま残って痛い目を見ます。

降格前チェック（これを満たしてから実行）

• 2019 DC が安定稼働し、複製エラーがない（repadmin/dcdiag）
• FSMO 役割が撤去対象の 2008 R2 に残っていない（netdom query fsmo）
• DHCP を 2019 に移行し、旧DHCPを停止・無効化した
• クライアントのDNS参照（DHCPオプション006、サーバー固定DNS）が新DCへ向いている

降格の実行と、降格後の後始末

• 2008 R2 側で DC 降格（demote）を実行
• 降格後、Active Directory サイトとサービスで旧サーバーオブジェクトが残っていないか確認
• DNS から旧DC由来レコードの整理（A/CNAME/NS など）
• 必要に応じてメタデータクリーンアップ（正常降格できていれば通常は最小限）

典型的なつまずきと切り分け（現場で効く“原因の当たり”）

「ドメインを上げたのに Get-ADForest が Windows2003Forest」

• 原因の第一候補：フォレスト機能レベルを上げていない
• 次点：複数ドメイン構成で、どこかのドメインが要件未達（単一ドメインだと思い込んでいる）

実務では、まずGUIの「Active Directory ドメインと信頼関係」でフォレスト機能レベルを確認し、上げられる状態か（必要条件を満たしているか）を見に行くのが早いです。

2019 昇格チェックで「フォレスト機能レベルが足りない」

• フォレスト機能レベルが要件未達（今回の核心）
• SYSVOL が FRS のまま（DFS-R移行未完了）
• 複製やDNSの根本エラー（昇格はできても後で壊れる）

dcdiag の NCSecDesc で権限系エラーが出る

環境によっては、RODC 関連の準備不足や権限・ACLの問題でエラーが出ることがあります。必ずしも 2019 DC 追加の核心ではないこともありますが、昇格や複製が不安定な場合は放置しない方が安全です。エラーが続くなら、対象テスト名・イベントログ・発生DCを絞ってから対処します。

作業のおすすめ順序（まとめ）

最後に、実務で事故が少ない順序を表で整理します。基本は「基盤を整えてから足す」「安定を確認してから外す」です。

フェーズ	やること	完了判定
事前確認	機能レベル、DFS-R、複製/DNS健全性チェック	昇格の前提条件を満たす
基盤整備	（必要なら）フォレスト機能レベル引き上げ、SYSVOLをDFS-Rへ	Get-ADForest が要件達成／dfsrmig が Eliminated
追加	2019 をドメイン参加 → DC昇格（DNS追加・必要ならGC）	複製・SYSVOL共有・名前解決が安定
移行	FSMO移行、DHCP移行、DNS参照整理	旧DC依存が消える
撤去	旧2008 R2 DC を降格・撤去、DNS残骸の清掃	旧DC不在でも運用継続できる

補足：このタイミングで「2012 R2 DC も置き換える」判断がラクになる

2008 R2 を撤去できると、次は 2012 R2 の更新計画が立てやすくなります。2019 を追加した環境は、同じ流れで 2012 R2 も置き換え可能です（2019/2022 など）。今回の入れ替えを“テンプレ化”して、チェックリストとして残しておくと、次回作業の工数が一気に下がります。

機能レベル、DFS-R、DNS/DHCP、FSMOという「依存の塊」を順番に剥がしていけば、DC更改は怖くありません。焦らず、前提条件の確認から積み上げていきましょう。