Windows Server 2012 R2のADにWindows Server 2019追加ドメインコントローラーを導入する方法｜DFSR(SYSVOL)移行と注意点

Windows Server 2012 R2で運用中のActive Directoryに、Windows Server 2019の追加ドメインコントローラーを増設できるか。結論は共存可能ですが、SYSVOLがFRSのままだと2019を昇格できません。本記事では事前確認からDFSR移行、追加DC導入、ユーザー影響の考え方まで実務目線で整理します。

まず結論：Windows Server 2012 R2 のAD DSに Windows Server 2019 の追加DCは導入できる

Windows Server 2012 R2のドメインコントローラー（DC）が稼働しているActive Directory Domain Services（AD DS）環境に、Windows Server 2019の追加ドメインコントローラーを新設することは可能です。2012 R2と2019が同一ドメイン内で共存し、レプリケーションしながら運用できます。

ただし、追加DCの導入可否を左右する最大のポイントがSYSVOLのレプリケーション方式です。もし現状がFRS（File Replication Service）のままなら、Windows Server 2019はFRSを使えないため、その状態では2019をDCに昇格できません。先にDFSR（Distributed File System Replication）へ移行しておく必要があります。

よくある疑問	結論	実務上のポイント
2012 R2 と 2019 の DC は共存できる？	共存可能	追加DCとして先に2019を入れて、段階的に役割を移すやり方が安全
SYSVOLがFRSのままでも2019 DCは追加できる？	不可	先にFRS→DFSR移行が必須。ここを飛ばすと昇格で詰まる
移行や追加DC導入でダウンタイムは必要？	原則として大きな停止は不要	ただし再起動・レプリケーション遅延・DNS/サイト設計不備で影響が出るため、監視と計画が重要

共存の可否を左右する「SYSVOL」とは何か

SYSVOLは、ドメインコントローラー上で共有される重要なフォルダで、主に以下を保持します。

• グループポリシー（GPO）のテンプレート（GPT）
• ログオンスクリプトなどのドメイン共通ファイル

クライアントはログオン時などにSYSVOLからGPO情報を取得します。つまりSYSVOLのレプリケーションが正常でないと、以下のような運用障害につながります。

• GPOが適用されない／適用が遅れる
• ログオンスクリプトが実行されない
• サイト間でポリシー差異が出る

このSYSVOLの複製を古くから担っていた仕組みがFRSで、現在の推奨はDFSRです。Windows Server 2019のDCはFRSを使えないため、2012 R2環境でもSYSVOLがFRS運用のまま残っている場合は、先にDFSRへ移行しておく必要があります。

導入前に確認すべき前提条件

ドメイン機能レベルが Windows Server 2008 以上であること

SYSVOLのFRS→DFSR移行の前提として、一般にドメイン機能レベル（Domain Functional Level）が2008以上である必要があります。2012 R2で運用しているなら多くの環境で満たしていますが、古い設計を引き継いだ環境では要確認です。

PowerShellでの確認例：

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

GUIで確認する場合は、Active Directory ドメインと信頼関係／Active Directory ユーザーとコンピューターなどから確認できます。

SYSVOL が DFSR かどうかを必ず確認する

最初に確認したいのはここです。確認はdfsrmig.exeで行います。

dfsrmig.exe /getglobalstate

出力の見方は次のとおりです。

表示される状態	意味	2019追加DCの観点
0 (START)	FRS運用（移行前）	不可：先にDFSRへ移行が必要
1 (PREPARED)	DFSR用の複製を準備中	移行途中。全DCで状態が揃ってから次へ
2 (REDIRECTED)	SYSVOLの参照先をDFSRへ切替済み	移行途中。最終のELIMINATEDまで完了推奨
3 (ELIMINATED)	FRSからDFSRへ移行完了	OK：この状態なら2019を追加DCとして導入しやすい

加えて、各DCがその状態に到達しているかは以下で確認します。

dfsrmig.exe /getmigrationstate

追加作業の前に、ADレプリケーションの健全性を確認する

追加DC導入やSYSVOL移行は、既存のADが健康であることが前提です。レプリケーションエラーやDNS問題を抱えたまま進めると、作業自体は進んだように見えても、後からGPOや認証で事故りやすくなります。

最低限の確認として、以下は実施を推奨します。

• dcdiag：DCの自己診断
• repadmin /showrepl：パートナーとのレプリケーション状況
• repadmin /replsummary：全体の遅延や失敗率のサマリ

確認項目	コマンド例	見るべきポイント
レプリケーション失敗	repadmin /replsummary	失敗（fails）や遅延（largest delta）が突出していないか
DCの健全性	dcdiag /v	DNS/NetLogons/Advertisingなどのテストに異常がないか
名前解決	nslookup	ドメイン名やSRVレコードがDCのDNSで引けるか

SYSVOLがFRSだった場合：FRS→DFSR移行の実務手順

もしdfsrmig /getglobalstateで「3 (ELIMINATED)」以外が返ってきたら、追加DC導入より先にSYSVOLのDFSR移行を終えるのがセオリーです。ここでは現場で事故りにくい進め方を、要点に絞って解説します。

移行前の準備（ここを飛ばすと詰まりやすい）

• レプリケーションエラーを先に解消：エラーが残っていると、移行ステップが完了せず停滞しやすい
• 全DCが安定稼働している時間帯を選ぶ：停止中のDCがあると到達判定が揃わない
• バックアップ方針を明確にする：DCはVMスナップショットで安易に戻さず、システム状態バックアップなど正攻法で備える
• GPO変更を控える期間を設ける：移行作業中の頻繁な変更は、切り分けを難しくする

dfsrmigのステップと意味

dfsr移行は大きく3段階で進みます（0→1→2→3）。段階ごとに「全DCが到達した」ことを確認してから次へ進めるのが鉄則です。

ステップ	コマンド	何が起きるか	体感影響
PREPARED	dfsrmig /setglobalstate 1	DFSRで複製するためのSYSVOLコピーを準備（裏側で複製が進む）	基本的にユーザー影響は出にくい
REDIRECTED	dfsrmig /setglobalstate 2	SYSVOL共有の実体参照をDFSR側へ切替（クライアントの参照先は同じに見える）	設計通りなら影響は最小。ただし不具合が出るとGPOに症状
ELIMINATED	dfsrmig /setglobalstate 3	FRSを使ったSYSVOL複製を廃止し、DFSRに完全移行	完了後が最も安定。2019追加DCの前提も満たしやすい

移行の進め方（コマンド例）

実行は権限を持つアカウントで行い、一般的にはPDCエミュレーター（PDC Emulator）上から実行する運用が多いです。

PREPAREDへ移行：

dfsrmig.exe /setglobalstate 1
dfsrmig.exe /getmigrationstate

全DCが「prepared」に到達するまで待ちます。到達が揃ったら次へ進めます。

REDIRECTEDへ移行：

dfsrmig.exe /setglobalstate 2
dfsrmig.exe /getmigrationstate

こちらも全DCが到達してから、最後の段階へ進めます。

ELIMINATEDへ移行（最終）：

dfsrmig.exe /setglobalstate 3
dfsrmig.exe /getmigrationstate
dfsrmig.exe /getglobalstate

/getglobalstateが「3 (ELIMINATED)」になっていれば、SYSVOLはDFSR運用になっています。

移行後に必ず確認したいポイント

• 全DCでSYSVOL/NETLOGON共有が見えている（共有が消えたり不一致がない）
• GPOの更新と適用が正常（テスト端末でgpupdate /force、イベントログで適用確認）
• レプリケーションが安定（repadmin /replsummaryで失敗が出ていない）

DFSR移行は「やったら終わり」ではなく、移行後の数日間はGPO更新やログオンを含めて観察し、問題がないことを確認してから次の工程（2019追加DC）へ進むのが安全です。

Windows Server 2019 を追加ドメインコントローラーとして導入する基本手順

SYSVOLがDFSR（ELIMINATED）になったら、いよいよWindows Server 2019を追加DCとして導入します。作業手順自体はシンプルですが、現場ではDNS設定とサイト設計、そして導入後の検証で差が出ます。

サーバー準備（地味だが効果が大きい）

• Windows Updateを適用し、最新パッチ状態にする
• 固定IPを設定する（サーバー用途でDHCP任せは避ける）
• DNSサーバーの参照先を既存DCのDNSに向ける（外部DNS直指定はトラブルのもと）
• 時刻同期（Kerberosは時刻ズレに弱い）を確認する

項目	推奨	理由
IP	固定	DNS/SRV登録や運用監視が安定する
DNS	既存DC（内部DNS）を参照	SRVレコード解決が確実になり、昇格時の失敗を減らす
パッチ	最新化	AD DS関連の既知不具合回避、セキュリティ対策

ドメインに参加する

2019サーバーを既存ドメインに参加させます。ドメイン参加後に再起動が必要になるため、ここは計画的に行います。

AD DS 役割追加 → 追加DCへ昇格

Server Manager（サーバーマネージャー）から「Active Directory Domain Services」を追加し、そのままウィザードに沿って「このサーバーをドメインコントローラーに昇格する」を実行します。

PowerShellで行う場合の例（環境に合わせて調整）：

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSDomainController `  -DomainName "example.local"`
-InstallDns `  -NoGlobalCatalog:$false`
-SiteName "Default-First-Site-Name" `
-SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM Password")

実務上は以下が重要です。

• DNSサーバーを入れるか：既存がAD統合DNSなら、追加DCにもDNSを入れて冗長性を高める構成が一般的
• グローバルカタログ（GC）にするか：多くの環境で「追加DCはGC化」が無難（認証・検索の観点で効く）
• サイトの指定：サイトを正しく分けている環境では、想定サイトに配置されるよう確認

昇格後に必ずやる検証

「昇格が完了した」だけでは安心できません。導入直後に以下を確認しておくと、後日の切り分けが楽になります。

• dcdiagで重大なエラーがない
• repadmin /showreplで受信・送信ともに正常
• SYSVOL/NETLOGON共有が作成されている
• イベントログ（Directory Service / DNS Server / DFS Replication）に異常が増えていない

SYSVOL/NETLOGON共有の確認例：

net share

レプリケーション確認例：

repadmin /showrepl
repadmin /replsummary

クライアントの利用DCをコントロールする（サイトとDNSが鍵）

追加DCを入れたのに「全然クライアントが新DCを使わない」「遠い拠点のDCにログオンして遅い」といった相談はよくあります。原因の多くはサイト/サブネット未整備かDNS参照先です。

• 拠点が複数あるなら、Active Directory サイトとサブネットを正しく登録する
• DHCPを使っているなら、配布するDNSサーバー（オプション006）を設計に沿って更新する
• DCに複数NICや誤ったDNS設定があると、SRV登録や参照が乱れるため避ける

ユーザー影響（ダウンタイム）の考え方：基本は停止不要だが「失敗すると影響が出る」

追加DCの導入やDFSR移行は、正しく進めれば業務を止めるような大きなダウンタイムは通常不要です。ADはマルチマスター構成で複数DCが同時に稼働し、認証・名前解決を分担できます。

一方で、「作業そのもの」ではなく「作業が引き金になって顕在化する問題」でユーザー影響が出るケースがあります。代表例は次のとおりです。

• もともとレプリケーションが壊れており、DFSR移行でGPO不整合が表面化
• DNSの参照先が不適切で、クライアントがSRVを引けずログオン遅延
• サイト設計が未整備で、遠隔DCへログオンして通信遅延
• 時間同期が乱れてKerberos認証に失敗

つまり、停止時間ゼロを目指すなら「追加作業の手順」よりも、事前健全性チェックと導入後の検証・監視が勝負です。再起動が伴う工程（サーバー参加、昇格完了後）だけは、影響が少ない時間帯に計画するのが現実的です。

ADの役割は「プライマリ/セカンダリ」ではなく、FSMOで整理すると理解が早い

古い表現で「プライマリDC／バックアップDC」のように語られることがありますが、現在のActive Directoryは基本的にマルチマスターです。複数DCが同等に更新を受け付け、レプリケーションで整合させます。

ただし、全てを完全に同時更新できると衝突が起きるため、一部の役割はFSMO（Flexible Single Master Operations）として「担当DC」が決まります。追加DC導入後に実務で意識しやすいのは以下です。

• PDCエミュレーター：パスワード変更の即時反映、時間同期、GPO編集などで重要
• RIDマスター：SID払い出しに関与
• インフラマスター：参照整合性
• スキーママスター／ドメイン名前付けマスター：変更頻度は低いが移行時に意識

2019 DCを入れたら、いきなり全部移す必要はありません。まずは追加DCとして安定稼働させ、その後に必要に応じてFSMOを段階的に移行するのが安全です。

旧DC（Windows Server 2012 R2）を廃止する場合の進め方

追加DCの最終目的が「2012 R2の置き換え」なら、2019が安定してから旧DCを降格・撤去します。ここで慌てると、DNSやアプリ依存で想定外の停止が起きやすいので、チェックポイントを押さえて進めます。

廃止前に確認するポイント

• 旧DCが保持しているFSMO役割が残っていない
• 旧DCにしかないDNSゾーンやフォワーダ設定がない
• DHCP、証明書サービス（AD CS）、NPSなど「AD以外の役割」を担っていない
• 拠点設計上、DC台数が不足しない（最低2台運用が基本）

FSMO移行の例（PowerShell）：

Move-ADDirectoryServerOperationMasterRole `
  -Identity "NEW-DC01" `
  -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

降格・撤去の流れ（要点）

• 旧DCを「ドメインコントローラーの降格」でメンバーサーバーへ戻す
• DNSやADサイト/サービスから不要なエントリが残っていないか確認
• 必要に応じてメタデータクリーンアップ（通常は正規降格なら不要）

よくあるつまずきポイントと対処（現場で多い順）

症状	ありがちな原因	対処の方向性
2019の昇格が途中で失敗する	SYSVOLがFRSのまま	dfsrmig /getglobalstateで確認し、FRSなら先にDFSR移行を完了させる
昇格後、SYSVOL/NETLOGON共有が見えない	DFSR初期同期未完了、レプリケーション不良	イベントログとrepadminで同期状況を確認。安定するまで待ち、エラーを解消
クライアントのログオンが遅い	サイト/サブネット未整備、DNS参照不適切	サイト設計とDHCP配布DNSを見直し、近いDCを使わせる
GPOが端末によって適用されない	SYSVOL複製の不整合、DFSR移行途中の揺れ	DFSR移行状態の統一、SYSVOLの整合確認、GPO更新手順の整理
Kerberos関連の認証エラー	時刻ズレ	DCの時刻同期経路を整理し、PDCエミュレーター中心の設計にする

作業に入る前のチェックリスト（そのまま使える実務版）

• SYSVOLはDFSRか？：dfsrmig /getglobalstateが 3 (ELIMINATED)
• レプリケーションは健康か？：repadmin /replsummaryで失敗なし
• DCの健全性はOKか？：dcdiagで重大エラーなし
• DNS設計は一貫しているか？：DC/クライアントが内部DNSを参照し、外部DNS直指定がない
• サイト/サブネットは整備されているか？：拠点があるなら必ず登録
• バックアップはあるか？：システム状態バックアップ等、復旧手段が明確
• 導入後の検証項目は決まっているか？：ログオン、GPO、名前解決、レプリケーション

まとめ：追加DC導入の成否は「DFSR」「DNS」「健全性チェック」で決まる

Windows Server 2012 R2のAD DS環境にWindows Server 2019の追加ドメインコントローラーを導入すること自体は、設計として珍しい話ではありません。ポイントは、導入の前にSYSVOLがDFSR（ELIMINATED）であること、そしてAD/DNS/レプリケーションの健康状態を整えることです。

段階的に2019を追加し、安定を確認してからFSMO移行や旧DC廃止に進めば、ユーザー影響を最小化しつつ世代交代を進められます。焦って一気に切り替えるより、「検証→導入→検証→移行→廃止」という順序で、確実に進めることが最も安全です。