Windows Server 2008 R2 の Active Directory で、子ドメインや別ツリーを含むフォレストを 2012 R2 相当へ引き上げる作業は、手順を誤ると「機能レベルが上げられない」「権限が足りない」といったトラブルが起きがちです。多ドメイン環境での実務手順と注意点を、現場目線で整理します。
結論：フォレスト機能レベルを上げる前に「全ドメイン」のDFLを揃える
子ドメイン（child domain）や別ツリー（tree domain）があるフォレストでも、考え方はシンプルです。フォレスト機能レベル（FFL）を引き上げるには、フォレスト内に存在する“すべてのドメイン”のドメイン機能レベル（DFL）が先に引き上がっていることが必須条件になります。
よくある誤解は「子ドメインがあるから、子→親の順で上げないといけない」というものですが、厳密には順番よりも“全ドメインの足並み”が重要です。どのドメインから着手しても構いませんが、最終的に全ドメインの DFL が揃わない限り、FFL は上げられません。
Active Directoryの機能レベル（DFL/FFL）を正しく理解する
「2008 R2 → 2012 R2 に上げたい」という相談では、OS のアップグレードと AD の機能レベルを混同しているケースが少なくありません。まずは用語を整理しましょう。
| 項目 | 対象 | 何が変わるか | 引き上げ条件（代表例） | 主な操作方法 |
|---|---|---|---|---|
| ドメイン機能レベル（DFL） | 1つのドメイン | そのドメイン内で利用できる AD 機能が増える／制約が変わる | そのドメイン内に、目標レベル未満の DC が存在しない | 「Active Directory ドメインと信頼関係」または PowerShell |
| フォレスト機能レベル（FFL） | フォレスト全体 | フォレスト全体で利用できる AD 機能が増える／制約が変わる | フォレスト内の全ドメインの DFL が、目標レベル以上に揃っている | 「Active Directory ドメインと信頼関係」または PowerShell |
| DC の OS バージョン | 各 DC サーバー | DC 自体の OS／パッチ／役割など。機能レベルとは別物 | （機能レベルとは別管理） | 新 DC 追加→旧 DC 降格、またはインプレースアップグレード |
| スキーマ（Schema） | フォレスト全体 | オブジェクト定義が更新される（新 OS の DC 追加時に更新されることが多い） | スキーマ更新権限が必要（後述） | adprep または DC 昇格ウィザード（自動実行） |
機能レベルを上げても、既存サーバーの OS が勝手に 2012 R2 になるわけではありません。実務上は、まず新しい OS の DC を追加して世代交代し、そのうえで DFL/FFL を引き上げるのが安全で一般的です。
子ドメイン／別ツリー（ツリードメイン）がある場合の考え方
フォレスト配下に複数のドメインがある場合、たとえば次のような構成になっています。
- ルートドメイン：corp.example.com
- 子ドメイン：tokyo.corp.example.com / osaka.corp.example.com
- 別ツリー：example.net（同一フォレスト内の別 DNS 名前空間）
このとき、子ドメインでも別ツリーでも扱いは同じで、「フォレスト内の“各ドメイン”」としてそれぞれ DFL 引き上げ対象になります。ルートドメインだけが 2012 R2 相当になっても、子ドメイン／別ツリーが 2008 R2 のままなら FFL は上げられません。
また、多ドメイン環境では次の点でハマりやすくなります。
- ドメインの数だけDC 世代交代・事前準備・検証が必要（単一ドメインより単純に工数が増える）
- 遠隔拠点のドメイン（子ドメイン/別ツリー）があると、レプリケーション品質が結果に直結する
- 「権限」と「資格情報」の整理が必要（どの作業が Domain Admins/Enterprise Admins/Schema Admins を要求するか）
作業前の現状把握：フォレスト内ドメインとDCを洗い出す
最初にやるべきことは、設計書ではなく現物の棚卸しです。特に多ドメインでは「忘れていた別ツリーの 1 台」が最後に見つかって計画が崩れがちです。
| 確認したいこと | 理由 | 確認方法（例） |
|---|---|---|
| フォレスト内の全ドメイン一覧 | FFL 引き上げ条件は“全ドメイン”が対象 | PowerShell：Get-ADForest で Domains を確認 |
| 各ドメインの DC 一覧（OS/役割/サイト/GC） | DFL 引き上げ条件は“当該ドメイン内の DC の最小 OS”で決まる | PowerShell：Get-ADDomainController -Filter * |
| FSMO 役割の所在 | 世代交代時に移行が必要。障害時の復旧手順にも影響 | netdom query fsmo / Get-ADDomain, Get-ADForest |
| レプリケーション健全性 | スキーマ更新・DC 追加・降格はレプリケーションが前提 | repadmin /replsummary、dcdiag |
| DNS（AD 統合ゾーン/委任/条件付きフォワーダ） | 多ドメイン/別ツリーは DNS 設計の影響を受けやすい | DNS マネージャ、nslookup、イベントログ |
| SYSVOL 複製方式（FRS/DFSR） | 将来 2016 以降に上げるなら DFSR へ移行がほぼ必須 | dfsrmig /getglobalstate |
| 依存システム（Exchange/認証基盤/業務アプリ） | 機能レベル引き上げ自体は互換性が高いが、運用変更が発生しうる | 構成管理、ベンダー資料、検証環境 |
棚卸しに使える、最低限の PowerShell 例です（RSAT/ActiveDirectory モジュールが必要）。
## フォレスト情報（ルートドメイン、全ドメイン、現在の FFL）
Get-ADForest | Select-Object RootDomain, Domains, ForestMode
## 各ドメインの DFL（DomainMode）確認
(Get-ADForest).Domains | ForEach-Object {
Get-ADDomain -Server $_ | Select-Object DNSRoot, DomainMode
}
## 各ドメインの DC 一覧（OS/サイト/GC）
(Get-ADForest).Domains | ForEach-Object {
Get-ADDomainController -Filter * -Server $_ |
Select-Object @{Name='Domain';Expression={$_.Domain}},
HostName, Site, OperatingSystem, IsGlobalCatalog
}ここで 2008 R2 の DC が 1 台でも残っているドメインは、その時点で DFL 2012 R2 に上げられません。逆に言えば、「2008 R2 DC をゼロにする」ことが最初の大きなマイルストーンになります。
推奨アプローチ：インプレースアップグレードより「新DC追加→旧DC降格」
2008 R2 DC を 2012 R2 にインプレースアップグレードする方法も理屈上は存在しますが、現場では次の理由で避けられることが多いです。
- ドメインコントローラーは役割が重く、OS 更新失敗時の影響が大きい
- 復旧が「OS と AD の両方」になり、切り分けが難しい
- 多ドメイン環境では横展開回数が増え、失敗確率が積み上がる
そのため、一般的には新しい OS（2012 R2 以上）のサーバーを DC として追加（昇格）し、旧 2008 R2 DC を降格して撤去する手順が推奨されます。これならロールバックもしやすく、段階的に進められます。
手順：2008 R2 から 2012 R2 相当へ引き上げる（多ドメイン版）
新しいドメインコントローラーを各ドメインへ追加する
多ドメインの場合は「ドメインごと」に DC を追加していきます。現場で安定しやすい進め方は次の通りです。
- 対象ドメインに 2012 R2 以上のサーバーをメンバー参加
- DNS 設定（優先 DNS を既存 DC に向ける）と時刻同期を確認
- AD DS 役割を追加し、DC に昇格（可能なら 2 台目も追加して冗長化）
- 必要に応じて Global Catalog（GC）を有効化
注意点として、多ドメイン環境では「そのドメインの DNS が正しく引けること」が必須です。別ツリーのドメインを追加するときに、参照している DNS がルートドメイン側だけだと名前解決に失敗することがあります。サイト間・名前解決・委任/フォワードのどこで解決しているかを、事前に把握しておくと事故が減ります。
スキーマ拡張（adprep）を安全に進める
2012 以降は、DC 昇格ウィザード中にスキーマ更新（いわゆる adprep 相当）が自動で走る仕組みになっています。ただし、変更管理が厳しい現場では「いつ・誰が・どの DC で」スキーマを更新するかを明確にしたいことも多いので、手動実行で事前に済ませる運用もよく行われます。
| 作業 | 主な目的 | 実施単位 | 必要になりやすい権限 | 実務メモ |
|---|---|---|---|---|
| forestprep（スキーマ更新） | フォレスト全体のスキーマ/構成を新世代に対応 | フォレストで 1 回 | Schema Admins + Enterprise Admins | Schema Master での実施が基本。レプリケーション完了まで待つ |
| domainprep | 対象ドメインの準備（権限/コンテナ等） | ドメインごと | Domain Admins（対象ドメイン） | 複数ドメインなら回数が増える。別ツリーを忘れない |
| rodcprep（必要時） | RODC を導入している/する場合の準備 | フォレストで 1 回 | Enterprise Admins（環境による） | RODC が絡むときだけ意識すればよい |
ポイントは、スキーマ更新そのものは「機能レベル引き上げ」とは別イベントだということです。新しい DC を追加するためにスキーマ更新が先に必要になり、その後に DC 世代交代と DFL/FFL 引き上げが続きます。「機能レベルを上げる前に、まずスキーマが上がる」ことは珍しくありません。
FSMO 役割とグローバルカタログ（GC）の配置を見直す
旧 DC を降格する前に、FSMO 役割（操作マスター）が旧 DC に残っていないか必ず確認します。役割が残ったままだと降格が失敗したり、障害時に面倒が増えます。
| 役割 | スコープ | 確認例 | 移行の考え方（実務） |
|---|---|---|---|
| Schema Master | フォレスト | netdom query fsmo | 原則として新しい安定 DC へ移行（スキーマ更新時も管理しやすい） |
| Domain Naming Master | フォレスト | netdom query fsmo | フォレスト構成変更がある運用なら、管理しやすい DC へ |
| PDC Emulator | ドメイン | Get-ADDomain | 時刻同期の要。拠点/回線/監視が安定した DC へ |
| RID Master | ドメイン | Get-ADDomain | 大量アカウント作成があるなら性能余裕のある DC へ |
| Infrastructure Master | ドメイン | Get-ADDomain | GC との兼ね合いが話題になりがちだが、現代的な構成では深刻化しにくい |
また、多ドメインでは GC の配置が体感品質に直結します。旧 DC を撤去して GC が消えると、ログオンやアドレス帳参照などが遅くなることがあります。「降格前に、代替の GC が同一サイトにいるか」をチェックしておくと安心です。
旧 2008 R2 DC を降格・撤去する
新 DC を追加したら、レプリケーションが安定していることを確認し、旧 2008 R2 DC を降格します。降格前後のチェックポイントをまとめます。
| タイミング | チェック内容 | 見落としやすいポイント |
|---|---|---|
| 降格前 | repadmin/dcdiag でエラーが無い、SYSVOL/NETLOGON 共有が正常 | 別ツリーの DC でレプリケーション遅延があると、後から整合性問題が出る |
| 降格前 | FSMO が残っていない、DNS が新 DC を参照できる | クライアントの固定 DNS（旧 DC 固定）が残っていると障害に見える |
| 降格後 | AD から DC オブジェクトが消えている、DNS の古い A/NS/SRV レコードが整理されている | 降格失敗/強制削除のときはメタデータクリーンアップが必要 |
「どうしても降格できない」ケース（OS 障害・レプリケーション不整合など）では、強制削除とメタデータクリーンアップが必要になります。ここは手順を誤ると後遺症が出やすいので、必ずバックアップを取り、慎重に進めてください。
各ドメインのドメイン機能レベル（DFL）を Windows Server 2012 R2 に引き上げる
そのドメイン内から 2008 R2 DC が消えたら、DFL 引き上げの準備が整います。多ドメインでのコツは、「ドメイン単位で完了条件を満たしてから」次へ進むことです（DC が混在したまま機能レベルだけ上げようとして詰みます）。
GUI の場合は「Active Directory ドメインと信頼関係」から対象ドメインを選び、ドメイン機能レベルを引き上げます。PowerShell なら次のイメージです（実行前に対象ドメイン名と現在値を必ず確認してください）。
## 現在の DFL 確認
Get-ADDomain -Server corp.example.com | Select-Object DNSRoot, DomainMode
## DFL 引き上げ（例：2012 R2）
Set-ADDomainMode -Identity corp.example.com -DomainMode Windows2012R2Domain機能レベルの引き上げは基本的に元に戻せません。「上げたら戻せない」を前提に、検証環境での事前確認、System State バックアップ、作業手順書のレビュー、変更ウィンドウの確保をセットで進めるのが現実的です。
全ドメインの DFL 完了後に、フォレスト機能レベル（FFL）を Windows Server 2012 R2 に引き上げる
フォレスト内のすべてのドメインで DFL 引き上げが完了したら、最後に FFL を引き上げます。ここで初めて「フォレスト全体が 2012 R2 相当の機能セットを前提にできる」状態になります。
## 現在の FFL 確認
Get-ADForest | Select-Object ForestMode
## FFL 引き上げ（例：2012 R2）
Set-ADForestMode -Identity corp.example.com -ForestMode Windows2012R2ForestFFL を上げる作業はフォレスト全体に影響するため、スキーマ更新と同様に「いつ誰がやるか」「直前・直後の確認項目」を明文化しておくと、監査や引き継ぎの面でも安全です。
権限・資格情報：ルートドメインのアカウントでどこまでできる？
多ドメイン環境では、作業アカウントの設計がトラブルの源になりがちです。結論としては、ルートドメインのアカウントでまとめて作業するなら Enterprise Admins を軸に考えるのが分かりやすいです（ただし最小権限の原則で、必要な期間だけ付与する運用が望ましい）。
| 作業 | 影響範囲 | 必要になりやすい権限（目安） | 補足 |
|---|---|---|---|
| 新 DC の昇格（最初の 2012 R2 DC） | ドメイン/フォレスト | Domain Admins（対象ドメイン）＋（自動スキーマ更新が走るなら）Schema Admins/Enterprise Admins | ウィザードで事前チェックに引っかかる場合は権限不足が多い |
| 追加 DC の昇格（スキーマ更新済み） | 対象ドメイン | Domain Admins（対象ドメイン） | 委任してドメインごとに実施する方式も可 |
| DFL 引き上げ | 対象ドメイン | Domain Admins（対象ドメイン） | Enterprise Admins で実施できる構成も多いが、環境依存なので事前確認 |
| FFL 引き上げ | フォレスト | Enterprise Admins | フォレスト管理作業として扱う |
| スキーマ更新（forestprep 相当） | フォレスト | Schema Admins ＋ Enterprise Admins | 作業後はグループから外す運用が一般的 |
実務的には、次のような“段取り”が事故を減らします。
- 「スキーマ更新用アカウント」と「通常移行用アカウント」を分ける（必要以上に Schema Admins を常用しない）
- 多拠点・多ドメインなら、ドメインごとに作業者を分けるより、手順と権限を一元化した方がミスが減ることが多い
- 権限付与は作業当日だけ、作業後に必ず戻す（監査対応にも強い）
よくある落とし穴と対処法
「子ドメイン／別ツリーがある」ことで増える失敗パターンを、原因と対処の形でまとめます。
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| FFL を上げようとしても選択できない | どこか 1 ドメインの DFL が低い／古い DC が残っている | Get-ADForest の Domains を起点に、全ドメインの DFL と DC OS を再点検 |
| 特定ドメインだけ DFL が上げられない | そのドメインに 2008 R2（またはそれ未満）の DC/RODC が残っている | 当該ドメインの DC 一覧を再取得し、世代交代の漏れを潰す |
| 新 DC 昇格時に前提条件チェックで失敗する | DNS/時刻同期/権限/レプリケーションのどれか | イベントログと昇格ウィザードの詳細を確認。repadmin/dcdiag で健全性を先に確保 |
| 旧 DC 降格後、クライアントが名前解決できない | クライアント/サーバーの DNS が旧 DC 固定になっている | DHCP オプション/固定設定/テンプレートを一斉点検。参照 DNS を新 DC へ |
| 遠隔拠点の子ドメインでログオンが遅い | 同一サイト内の GC 不足、サイト/サブネット定義不足 | AD サイトとサービスでサブネットと DC 配置を再設計。必要なら GC を追加 |
| 将来 2016 以降に上げたいのに準備が進まない | SYSVOL が FRS のまま | 早い段階で DFSR 移行を計画（dfsrmig）。移行後に監視と復旧手順を整備 |
作業後に必ず実施したい検証
機能レベルの表示が変わっただけで安心するのは危険です。多ドメインでは「ドメインごとの正常性」と「フォレストとしての正常性」を両方確認します。
| 検証項目 | コマンド/観点 | 合格の目安 |
|---|---|---|
| レプリケーション | repadmin /replsummary | エラーや大きな遅延がない |
| DC 健全性 | dcdiag /v | 重大エラーがない（DNS/Advertising/SysVolCheck を重点確認） |
| 機能レベルの整合 | Get-ADDomain / Get-ADForest | 全ドメインが Windows2012R2Domain、フォレストが Windows2012R2Forest |
| ログオン/参照系 | 各ドメインでのログオン、グループポリシー適用、名前解決 | 遅延やエラーがない（拠点間も確認） |
| DNS レコード | _msdcs/ SRV レコード、NS/A レコード | 旧 DC の残骸がない、期待する DC が登録されている |
検証は「作業直後」と「翌営業日」の 2 回やると、DNS キャッシュやレプリケーション遅延の影響を拾いやすくなります。多ドメインの場合、別ツリー側の利用者が少なくて気づきにくいので、テストユーザーでのログオン確認を必ず用意しておくと安心です。
2012 R2 機能レベルに上げるメリット（“上げる理由”を言語化する）
「上げたい」だけだと、作業が単なる負担になります。現場では、次のように“上げる理由”を整理しておくと、変更管理が通りやすくなります。
- 将来の世代（2016/2019/2022 など）へ移行するための土台づくり
- ドメイン/フォレストを新しいセキュリティ前提で運用できる（例：認証ポリシー/保護されたユーザーなどの活用余地）
- 古い DC を撤去することで、暗号スイートや TLS 設定、監査ログなどの運用を近代化しやすい
特に「子ドメイン／別ツリーがあるフォレスト」は、放置すると一部だけ古いまま残って攻撃面が広がる構造になりやすいです。今回の作業を“全ドメインを同じ世代に揃える機会”として捉えると、監査やセキュリティ観点でも説明がしやすくなります。
まとめ：多ドメインでも迷ったら「全ドメインDFL→最後にFFL」
子ドメインや別ツリーが存在しても、機能レベル引き上げの本質は変わりません。
- 各ドメインから 2008 R2 DC を無くす（新 DC 追加→旧 DC 降格が基本）
- フォレスト内の全ドメインで DFL を Windows Server 2012 R2 に揃える
- 最後に FFL を Windows Server 2012 R2 に引き上げる
この順序を守り、権限と DNS/レプリケーションを丁寧に潰していけば、多ドメイン環境でも安定して移行できます。
コメント