Windows Server 2012 R2 のVMware環境を Windows Server 2019 に新規構築で移行するなら、まずはAD DS／DNS／AD CS（証明機関）を安全に置き換えるのが最短ルートです。冗長構成を維持したまま段階移行する具体的な手順と、現場でつまずきやすいポイントをまとめます。
「OS移行」を一括で考えると失敗する：ワークロード単位に分解する
Windows Server 2012 R2 から Windows Server 2019 への移行を「OSを上げる」とひと括りにすると、現場では計画が破綻しやすくなります。理由は単純で、AD DS／Exchange／SharePoint／SQL／監視・監査ツールは、それぞれ移行要件・互換性・停止許容時間がまったく違うからです。
まずは移行対象をワークロード単位に分解し、「基盤（AD）を先に固め、その上に乗るアプリを順番に移行する」設計にします。新しいサーバーを並行稼働させ、段階的に役割を切り替えていく方法は、OSのインプレースアップグレードよりも安全に進めやすいのが特徴です。
| 対象 | 推奨の進め方 | 理由 | 最初に確認すべきこと |
|---|---|---|---|
| AD DS / DNS | 2019 DCを追加 → 役割移行 → 旧DC降格 | 冗長を維持しながら置き換えできる | レプリケーション健全性、SYSVOL方式（FRS/DFSR） |
| AD CS（CA） | 移行方式を決めてから実施（同居DCは要注意） | 証明書の失効確認（CRL/AIA）が止まると影響が広い | CDP/AIA、発行済み証明書の用途、テンプレート |
| Exchange Server 2016（冗長） | 製品要件に沿って個別計画（可能なら先に更新） | CUやサポート条件に依存しやすい | サポートマトリクス、CU、認証・証明書・名前解決 |
| SharePoint 2016 / SQL Server 2016 | アプリ・DBの組み合わせで個別計画 | OS/SQL/パッチレベルの互換性が絡む | Farm構成、SQL可用性、サービスアカウント |
| ManageEngine（監視・監査） | 監視対象の切替と権限/LDAP設定を別枠で | DC名や証明書・LDAP設定が移行で変わりがち | 監視項目、認証方式、証明書、通知経路 |
全体の移行順序：まずAD基盤、次にCA、最後にアプリ
「段階移行」で最も事故が少ない順序は、次の考え方です。
- 認証と名前解決（AD DS / DNS）を先に新環境へ寄せる
- 社内PKI（AD CS/CA）を移行または再設計する
- その上で Exchange / SharePoint / SQL / 監視ツール を製品ごとに移行する
| フェーズ | ゴール | 主な作業 | 切り戻しの考え方 |
|---|---|---|---|
| 準備 | 失敗しない材料を揃える | 棚卸し、バックアップ、健全性確認、移行設計 | この時点で「戻れる」設計にしておく |
| AD DS / DNS | 2019 DCが本番運用できる | 2019 DC追加、DNS確認、FSMO移行、冗長化維持 | 旧DCは残す（すぐ撤去しない） |
| AD CS（CA） | 証明書発行と失効確認を新環境へ | CA移行（バックアップ/復元）または新規CA＋再発行 | CRL/AIAが読める状態を保つ |
| 旧DC撤去 | 2012 R2 DCを段階的にゼロへ | 降格→撤去（1台ずつ）、メタデータ清掃 | 撤去は最後、慌てない |
| アプリ群 | 各製品の移行完了 | Exchange/SharePoint/SQL/監視ツールを個別移行 | ワークロード単位で切り戻し策を用意 |
移行前の準備：ここを省くと「段階移行」が崩れる
新規構築で移行する場合、サーバー構築そのものよりも、現状把握と設計の精度が成否を決めます。特にADは「静かに壊れている」状態のまま長年運用されていることがあり、移行のタイミングで露見しがちです。
| 準備項目 | やること | 実務のコツ |
|---|---|---|
| 構成棚卸し | DC台数、サイト/サブネット、DNSゾーン、転送設定、CA構成、証明書用途を整理 | 「誰がどのDNSを見ているか（IP固定・DHCP）」を必ず洗い出す |
| バックアップ | DCはSystem State、CAはDB/秘密鍵/レジストリ等、DNS設定も控える | 「復元手順を実際に試す」までやると事故が激減 |
| 権限整理 | DC昇格、CA移行に必要な権限（Domain Admin/Enterprise Admin等）を確認 | 当日になって権限不足で止まるケースが多い |
| 名前/証明書の依存整理 | CAのCDP/AIA、LDAP(S)/RADIUS/社内Web等が参照するホスト名を洗う | CA移行は「URLが変わる」だけで証明書検証が崩れる |
| メンテ計画 | DC追加は無停止でできても、CA移行は手順次第で影響が出る | 「最悪どこまで止まるか」を事前に合意しておく |
AD DSの事前健全性チェック：移行前に必ず“エラーゼロ”へ
新しい2019 DCを追加する前に、既存2012 R2 DCが健康であることを確認します。移行作業は、既存環境の不具合を増幅させることがあるため、ここで出るエラーは先に潰してから進めるのが鉄則です。
| チェック | コマンド例 | 見るポイント |
|---|---|---|
| DCの総合診断 | dcdiag /v | DNS関連・SYSVOL・広告（Advertising）・サービス停止など |
| レプリケーション状態 | repadmin /showrepl repadmin /replsum | 失敗が継続していないか、遅延が常態化していないか |
| SYSVOL/NETLOGON共有 | net share | SYSVOL と NETLOGON が共有されていること |
| DNS自己診断 | dcdiag /test:dns /v | 委任、SRV、フォワーダ、動的更新など |
SYSVOLの複製方式がFRSなら先にDFSRへ移行する
ここが2012 R2 → 2019 移行で最も詰まりやすいポイントです。SYSVOLがFRS（File Replication Service）で複製されているドメインでは、2019 DCの追加（昇格）がブロックされるケースがあります。メッセージとして「FRS is deprecated」「DFSRMIGで移行してから続行」などが出たら、先にDFSRへ移行が必要です。
また、DFSR移行は段階的に進めますが、最終段階まで進めるとFRSへ戻せません。実施前にバックアップと復旧方針を固めたうえで進めます。
| 項目 | FRS | DFSR | 移行観点 |
|---|---|---|---|
| 位置付け | 旧方式（非推奨） | 現行方式 | 新しいWindows ServerではDFSRが前提になりやすい |
| 2019 DC追加 | ブロックされる可能性 | 問題になりにくい | まずSYSVOL方式を確認する |
| 移行の戻し | — | 最終完了後は戻せない | 「Eliminated」完了前に必ず慎重に確認 |
SYSVOL方式の確認例（どのDCでも実行可）
dfsrmig /getglobalstate
dfsrmig /getmigrationstateDFSR移行の基本フロー（概念）
- 既存DCの健全性を確保（dcdiag/repadminでエラー解消）
- Preparedへ移行
- Redirectedへ移行
- Eliminatedへ移行（ここまで完了すると戻せない）
DFSR移行の詳細はMicrosoftの移行ガイドに沿って進めるのが安全です。移行は段階的で、進行状況は dfsrmig /getmigrationstate で追えます。
Windows Server 2019 DCを新規構築で追加する手順
AD DSの推奨は、既存DCのOSを上げるのではなく、新しいサーバーをDCとして追加し、古いDCを降格して置き換える方法です。新規構築移行（作り直し）を安全に成立させる中心手順でもあります。
新2019サーバーのOSインストール直後にやること
- ホスト名（例：DC03、DC04など）を確定し、命名規則を統一
- 固定IPを設定（DCは固定が基本）
- DNSサーバーの参照先を「既存DCのDNS」に向ける（いきなり外部DNSを向けない）
- Windows Update適用、時刻同期の方針確認（PDCのNTP設計は後段で統一）
- VMware上でのバックアップ/スナップショット運用方針を明確化（DCは安易な巻き戻しを前提にしない）
ドメイン参加 → AD DS / DNS追加 → DC昇格
- 新2019サーバーを既存ドメインへ参加（再起動）
- 事前チェック（PowerShellでの例）
Test-ADDSDomainControllerInstallation -DomainName "example.local"この事前チェック用cmdletは、DC追加に必要な前提条件の確認に使えます。
- AD DSロールを追加（管理ツール含む）
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools- DCへ昇格（DNSも同時導入するのが一般的）
Install-ADDSDomainController -DomainName "example.local" -InstallDns新しいサーバーをDCとして追加する場合、adprepの手動実行は通常不要で、ウィザード/PowerShellに統合されています。
昇格後の確認（最低限ここまで）
dcdiagとrepadminを新DCでも実行し、エラーがないこと- DNSゾーン（AD統合）が新DCへ複製されていること
- 新DCで
net shareを実行し、SYSVOL/NETLOGON共有ができていること - ADサイト/サブネット設定が適切で、クライアントが意図したDCを参照すること
FSMO役割移行：移すべきタイミングと実務の定石
2019 DCを追加して安定したら、必要に応じてFSMO（操作マスター）役割を新DCへ移行します。最初の2019 DC導入時には、FSMO保持DCへの接続性が前提条件にもなります。
現在のFSMO保持先確認（例）
Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | FL DomainNamingMaster, SchemaMasterFSMO役割の所在確認は、移行前後の“事故防止”に直結します。
| 役割 | 移行先の考え方 | 現場メモ |
|---|---|---|
| Schema Master | 管理性の高い中核DCへ | スキーマ更新に関与。通常は常時使うわけではない |
| Domain Naming Master | 同上 | ドメイン追加/削除などに関与 |
| RID Master | 負荷と安定性を重視 | オブジェクト作成に影響 |
| PDC Emulator | 最優先で安定したDCへ | 時刻同期/ロックアウト/パスワード変更など影響が広い |
| Infrastructure Master | 基本は中核DC | 単一ドメイン/全DCがGCなら大きく問題になりにくい |
PowerShellで一括移行する例
Move-ADDirectoryServerOperationMasterRole -Identity "NEWDC01" -OperationMasterRole 0,1,2,3,4FSMOの移行/奪取（seize）は状況により手段が異なります。通常は“移行（transfer）”で進め、障害で旧DCが失われた場合のみ“奪取（seize）”を検討します。
DNS移行：AD統合DNSは「DC追加」とセットで設計する
DNSをAD統合ゾーンで運用している場合、2019 DCにDNSロールを入れて昇格すれば、ゾーン情報はADのレプリケーションで追従します。とはいえ、“ゾーンは複製されたのに、名前解決の挙動が変”というトラブルは頻発するため、確認ポイントを表で押さえます。
| 確認/移行ポイント | 何が起きると困るか | 対策 |
|---|---|---|
| DNSフォワーダ | 外部解決が遅い/失敗 | 旧DCの設定を新DCへ同等に反映（手動が多い） |
| 条件付きフォワーダ | 特定ドメイン宛が解決不能 | 設定を棚卸しし、移行後に実解決テスト |
| 逆引きゾーン | 監視/監査/一部認証で警告 | 必要なら新DCに存在することを確認 |
| エイジング/スカベンジ | 古いレコード残留 or 消え過ぎ | 設定値と適用対象（サーバー/ゾーン）を確認 |
| クライアントの参照DNS | 旧DCを参照し続ける | DHCPオプション(006)や固定IP機の設定を段階的に更新 |
実務的には、DNSサーバー切替は次の順で「痛みなく」進みます。
- 新DC（DNS）を追加して、ゾーンが揃っていることを確認
- サーバー群（固定IP）のDNS参照先を新DC優先へ切り替え
- DHCP配布のDNS参照先を新DCへ切り替え
- 旧DC（DNS）の参照が残っていないことを確認してから撤去
AD CS（CA）が同居しているDCは、AD移行の“ボトルネック”になりやすい
ドメイン コントローラーにAD CS（証明機関）が同居している構成は、移行で必ず壁になります。理由は次の2つです。
- CAが止まると「証明書の発行」だけでなく「失効確認（CRL/AIA）」が止まり、ログオンやTLS通信に影響が波及する可能性がある
- DCを入れ替えたいのに、CAの移行/廃止設計が固まっていないと、旧DCを最後まで撤去できない
そのため、AD DS/DNSを先に2019へ寄せて基盤を安定させたうえで、CAを「移行」するか「作り直すか」を決めて進めるのが現実的です。CA移行は、バックアップ対象や実施順序が明確に定義されており、準備不足だと復旧が難しくなります。
CA移行方式の選び方：移行（復元）か、新規（再発行）か
| 方式 | メリット | デメリット/注意 | 向いているケース |
|---|---|---|---|
| 既存CAを移行（バックアップ/復元） | 既存証明書を活かせる、影響が読みやすい | 手順ミスでCAが不整合になるリスク、CDP/AIA維持が重要 | 発行済み証明書が多い/影響範囲が広い |
| 新規CAを構築（証明書再発行） | 設計を整理でき、不要な負債を落とせる | 再発行/配布/失効設計が大変、移行期間が長くなりがち | 証明書用途が限定的、刷新を機にPKIを再設計したい |
既存CAをWindows Server 2019へ移行する手順（同一CAを引き継ぐ）
Microsoftの手順では、CA移行の前提としてCAデータベース、秘密鍵、レジストリ設定、CAPolicy.inf、（エンタープライズCAの場合は）テンプレート関連などのバックアップを行い、手順順守で移行します。さらに、CA役割を外す前にCRLの有効期間を延長したうえで新しいCRLを公開することが推奨されます。
ステップ1：影響範囲を短時間で把握する
- CAが発行している証明書テンプレート（コンピューター、ユーザー、Webサーバー、ドメインコントローラー認証など）
- LDAPS、Wi-Fi（NPS）、VPN、社内Web、監視ツールなど「証明書がないと動かない」用途
- CRL配布点（CDP）とAIAの参照先（HTTP/LDAP/ファイル共有など）
ステップ2：旧CAでバックアップを取得し、発行を止める
バックアップ対象（最低ライン）
- CAデータベース
- 秘密鍵（CA証明書と鍵）
- CAのレジストリ設定
- CAPolicy.inf（存在する場合）
- エンタープライズCAの場合：テンプレートの公開一覧（後で手動再設定が必要になりやすい）
このバックアップ対象の考え方は、Microsoftの移行ガイドで整理されています。
例：サービス停止（発行停止）
Stop-Service -Name "certsvc"停止のタイミングや停止時間は業務影響と合わせて計画します。
ステップ3：CRLを延命して公開する（移行の事故を減らす）
CA移行で本当に怖いのは「証明書を発行できない」よりも「既存証明書の検証ができない」状態です。Microsoftの手順では、廃止/削除に関連する手順として、CRL発行間隔を延ばし、新しいCRLを公開することが明記されています。
ステップ4：新2019サーバーへAD CSを導入し、復元する
- 移行先サーバーは、可能ならDCではなくメンバーサーバーとして分離（攻撃面/障害影響の観点）
- 同一CAを引き継ぐ場合、CA証明書と秘密鍵をインポートし、CAデータベースを復元
- 手順の順序（旧CAの役割削除の順番など）を守る
旧CAの設定（レジストリ）をエクスポートして新サーバーへインポートし、CAデータベースを復元する流れは、Microsoftの移行手順として提示されています。実施順序を誤ると新CAが使えなくなる可能性があるため、順序は厳守します。
ステップ5：移行後の確認（ここまでやって初めて“完了”）
- 証明書要求（手動/自動登録）が通る
- CRL/AIAが配布・参照できる（PKIビュー等で確認）
- ドメインコントローラー証明書（必要な場合）が更新/配布される
- Exchange/SharePoint/監視ツールなど、証明書を使う機能が実動作する
特に、PKIクライアントはAIA/CDPを参照して証明書を検証するため、移行後も参照パスが有効であることが重要です。
CAを廃止する場合の要点（「使っていないはず」を前提にしない）
「CAは使っていないと思う」でも、ドメインコントローラー証明書、LDAPS、内部TLSなどで静かに使われていることがあります。廃止するなら、発行済み証明書の扱い、CRLの延命、公開、オブジェクト削除などを順に実施します。Microsoftは、廃止手順として、証明書の失効、CRL発行間隔の延長、CRL公開などの流れを示しています。
旧DCの降格・撤去：最後にやるべき理由と手順
2019 DCの追加とCA移行が完了したら、ようやく旧2012 R2 DCを1台ずつ降格・撤去できます。冗長構成を崩さず、常に「複数DCが稼働している状態」を維持するのが安全です。
降格前チェック（最低限）
- 旧DCがFSMO役割を持っていない
- DNS参照先として旧DCしか指定していないサーバー/機器が残っていない
- CAが同居していた場合、CA移行/廃止が完了している
dcdiag/repadminが正常
降格はServer ManagerかPowerShellで（DISMは避ける）
DCの降格（AD DSの削除）は、Server ManagerまたはADDSDeploymentモジュールで実施します。DC昇格後にDISMでAD DSを外すのはサポートされず、起動不能など深刻な問題につながる可能性があると明記されています。
PowerShell例（環境に合わせてオプションは調整）
Uninstall-ADDSDomainControllerもし“強制削除”が必要になったら（最終手段）
本来は正常降格が理想ですが、障害で旧DCが壊れて降格できない場合は、メタデータクリーンアップが必要になることがあります。Microsoftは ntdsutil 等を用いたメタデータ清掃手順を案内しています。
ドメイン/フォレスト機能レベル：上げるなら“最後”に判断する
Windows Server 2019 のDCを導入しても、機能レベルは「2019」が増えるわけではありません。Microsoftのドキュメントでは、Windows Server 2019/2022はWindows Server 2016を最新の機能レベルとして扱うことが明記されています。
また、Windows Server 2019以降のDC導入には、最低でもWindows Server 2008のフォレスト機能レベルが必要とされます。
実務では、機能レベル引き上げは次の条件が揃ってからが安全です。
- 旧2012 R2 DCがすべて撤去済み
- Exchange/SharePoint/SQL/監視ツールの互換性を確認済み
- 戻せない（または戻しづらい）ことを理解し、合意済み
機能レベルは原則ロールバックできない（例外条件はある）ため、最後に判断するのが無難です。
移行後の最終確認チェックリスト（運用に戻す前に）
| カテゴリ | 確認内容 | 確認例 |
|---|---|---|
| 認証 | 複数拠点/複数端末でログオンが安定 | 社内LAN・VPNなど代表経路で実施 |
| GPO | ポリシー適用、ログオンスクリプト動作 | gpupdate /force、イベントログ |
| DNS | 内部名/外部名の解決が正常、遅延なし | nslookup、dcdiag /test:dns |
| ADレプリケーション | 失敗ゼロ、遅延が常態化していない | repadmin /replsum |
| 証明書 | 発行、更新、自動登録、CRL参照が正常 | PKIビュー、証明書要求テスト |
| 監視/運用 | 監視対象DCの切替、アラートが正常 | ManageEngine側の認証/収集設定 |
現場で多い落とし穴と回避策
- SYSVOLがFRSのまま：2019 DC昇格で止まる。最初に方式確認→必要ならDFSR移行。
- DNSフォワーダ/条件付きフォワーダの移し忘れ：ゾーンは複製されたのに外部解決が不安定。新DCのDNS設定を棚卸し表で潰す。
- CAのCDP/AIA参照先が旧サーバー名固定：移行後に証明書検証が失敗する。DNSエイリアスや公開パス維持を設計に入れる。
- 旧DC撤去を急ぐ：段階移行のメリットが消える。新DCが安定してから1台ずつ撤去。
- 機能レベル引き上げを先にやる：後戻りが難しい。全ワークロードの互換性確認後に判断。
まとめ：冗長を維持したまま、AD基盤から健康的に置き換える
Windows Server 2012 R2 から Windows Server 2019 への新規構築移行は、やり方さえ外さなければ「止めずに置き換える」ことが可能です。ポイントは、AD DS/DNSを先に2019へ寄せて基盤を固め、CA（AD CS）を移行または再設計してから、旧DCを1台ずつ降格・撤去することです。推奨される基本方針としても、新しいDCを追加して古いDCを降格する手順が示されています。
この順番で進めれば、Exchange/SharePoint/SQL/監視ツールといった周辺ワークロードも、個別計画で安全に切り替えやすくなります。「まずAD基盤を健康にする」ことが、結局いちばん早く、いちばんトラブルが少ない進め方です。
コメント