Windows Server 2022 の Active Directory で 2 台目のドメイン コントローラーを追加した直後、SYSVOL の DFSR 初期同期が始まらないことがあります。dcdiag が正常でも起きる“メタデータ不整合”を、原因の見立てから復旧まで実例ベースで解説します。
起きている現象を、まず「正しい形」に言語化する
今回のケースは、単なる「複製が遅い」ではなく、SYSVOL 用 DFSR の初期化が始まる前段で止まっているのがポイントです。状況を整理すると、次のような特徴が揃っています。
| 観点 | 確認結果 | 示唆 |
|---|---|---|
| AD 複製（NTDS） | dcdiag / repadmin が概ね正常 | 「ディレクトリ複製」自体は壊れていない |
| DFSR グローバル設定 | CN=DFSR-GlobalSettings 配下に Domain System Volume が存在 | ドメイン全体として SYSVOL DFSR を使う体裁はある |
| DC2 のローカル設定 | CN=DFSR-LocalSettings,CN=DC2,… の下に Domain System Volume / SYSVOL Subscription が自動作成 | 昇格直後の “新規 DC 側” は通常どおりオブジェクトが作れている |
| DC1 のローカル設定 | CN=DFSR-LocalSettings,CN=DC1,… が空。Domain System Volume / SYSVOL Subscription が作られない | 「ソース側（本来の権威側）」が SYSVOL の構成に参加できていない |
| DFSR の状態（WMI） | DC1 で DfsrReplicatedFolderInfo が何も返らない | DFSR が AD 構成を読み込めていない／構成が存在しない扱いになっている |
| イベントログ | 1206 までは出るが、初期同期で見たい 4114 / 4614 / 4604 が出ない | 初期同期の開始条件（サブスクリプション成立）に到達していない |
| 手動作成の試み | PowerShell / ADSIEdit / LDIFDE で作ろうとしても制約違反・名前解決エラー | 単純なサービス再起動ではなく、AD 側のメタデータ破損・整合性崩れが濃厚 |
ここから導ける重要な結論はひとつです。「AD は複製できているのに、SYSVOL の DFSR 構成だけが“DC1 に対して成立していない”」というタイプの障害です。
なぜ dcdiag が正常でも、SYSVOL の DFSR だけが死ぬのか
Active Directory の健康診断（dcdiag / repadmin）が見ているのは主に、
- ディレクトリパーティション（Domain / Configuration / Schema など）の複製
- RPC/認証/名前解決/サイトリンクなどの基盤
です。一方、SYSVOL の DFSR は 「DFSR 用の AD オブジェクト（msDFSR-*）を読んで動く、別レイヤーの構成管理」を持っています。
つまり、こういうことが起きます。
- AD 複製は正常（repadmin もきれい）
- しかし DFSR が参照すべき オブジェクトが欠落／破損／矛盾しており、SYSVOL だけ初期化されない
今回の決定打は、DC2 では自動生成されるのに、DC1 では CN=DFSR-LocalSettings が空のままという点です。これは「DFSR サービスが止まっている」よりも、“DC1 が SYSVOL のメンバーとして成立できない”方向のトラブルを強く示します。
根本原因として濃厚なもの
原因はひとつに見えて、実際は“どこが最初に崩れたか”で枝分かれします。ただし優先度を付けると、だいたい次の順で当たりやすいです。
DC1 の SYSVOL Subscription（msDFSR-Subscriber）が欠落／破損している
本来、DC ごとの DFSR ローカル設定には、少なくとも以下がぶら下がります。
- CN=DFSR-LocalSettings（各 DC の配下）
- CN=Domain System Volume（SYSVOL 用のフォルダー定義）
- CN=SYSVOL Subscription（その DC が参加する“購読（サブスクリプション）”）
DC1 側のこの鎖が切れていると、DFSR は SYSVOL を「自分の管理対象」として初期化できず、結果として DC2 側も初期同期が始まりません。
FRS→DFSR 移行のメタデータが中途半端（移行完了に見えても不整合が残る）
Windows Server 2022 の DC 追加は DFSR が前提ですが、ドメインの歴史が長いと、過去の SYSVOL が FRS だった時代の名残や、移行・ロールバック・途中停止の残骸が残り得ます。
このタイプは、見た目では「もう DFSR だよね」と見えるのに、AD 内の msDFSR-* が部分的に欠けていたり、参照関係がねじれていたりします。結果として “DC1 だけ認識されない”のような片側障害が起きます。
CN=DFSR-LocalSettings 配下の ACL（権限）が壊れている
DFSR は AD 構成を読み、必要に応じてサブオブジェクトを作成します。このとき、
- DC のコンピューターアカウント
- あるいは SYSTEM / 既定の権限委任
が、「子オブジェクト作成」や「属性書き込み」を行える必要があります。
ここが壊れていると、昇格後もオブジェクトが作れず、ログ上は“それっぽく動いているのに実体が増えない”状態になります。手動作成でも制約違反が出やすく、今回の症状と一致します。
“見えない破損”が混ざっている（Exchange の残骸、孤立オブジェクト、重複参照）
質問にある「過去に削除済みの Exchange の残骸」は、可能性として十分あります。ただし「Exchange が直接 DFSR を壊す」というより、
- 長年の運用で AD に残った孤立オブジェクト
- 削除・復元・移行・スナップショット運用などで生じた参照不整合
- アクセス制御の変化（権限委任、継承ブロック）
といった“歴史の堆積”が DFSR の構成生成を阻害する、という形で現れます。
最短で切り分けるための「見る順番」
この障害は、手当たり次第にロール再インストールをしても改善しにくいです。理由は明確で、症状の主戦場が「サービス」ではなく「AD メタデータ」だからです。以下の順番で確認すると、迷子になりにくいです。
安全確保
- システム状態バックアップ（少なくとも DC の System State）
- 仮想環境なら「DC のスナップショット運用」を安易に戻さない（復元は設計どおりに）
- 作業中に GPO 変更や DC の増減をしない
FRS→DFSR の移行状態を確認
まず「ドメインとして SYSVOL DFSR が前提になっているか」を確認します。
dfsrmig /getglobalstate
dfsrmig /getmigrationstateここで状態が揺れていたり、“完了したはずなのに揃わない”場合は、移行メタデータの不整合が強く疑われます（この場合、後段の Subscription 再作成が必要になりがちです）。
AD 内の DFSR 構成を「ダンプして俯瞰」する
局所（ADSIEdit）で迷ったら、まず全体像をテキスト化します。
dfsrdiag dumpadcfg > dfsr-config.txtこのファイルで見るべきポイントは次のとおりです。
- SYSVOL（Domain System Volume）に対して、DC1 がメンバーとして出てくるか
- DC2 だけ存在し、DC1 が欠けていないか
- 参照 DN が不自然に別名・別 OU を向いていないか
DC1 の msDFSR-Subscriber（SYSVOL Subscription）の有無を LDAP で確認
“あるべきものが無い”を確定させるのが先です。
Get-ADObject `
-LDAPFilter '(objectClass=msDFSR-Subscriber)' `
-SearchBase "CN=System,DC=corp,DC=example,DC=uk" `
-Properties distinguishedName |
Select-Object distinguishedNameDC2 側の Subscription が見えるのに、DC1 側が無い（または DN が変）なら、ほぼ勝ち筋です。
ADSIEdit で “空の場所” を確認する
DC1 のローカル設定を見て、空であることを確認します（「空に見える」のではなく、本当に子が無いか）。
確認パス（例）
CN=DFSR-LocalSettings,
CN=DC1,
OU=Domain Controllers,
DC=corp,DC=example,DC=uk通常、ここには少なくとも CN=Domain System Volume がぶら下がり、さらにその下に CN=SYSVOL Subscription が存在します。ここが空なら、DC1 は SYSVOL DFSR の“参加者”として成立していません。
なぜ DC1 は SYSVOL Subscription を自動生成できないのか
「DC2 は作れるのに、DC1 は作れない」場合、説明として一番筋が通るのは次のどれかです。
| 仮説 | 起きること | 今回の症状との一致度 | 見つけ方 |
|---|---|---|---|
| Subscription が欠落/破損 | DC1 が参加者として成立せず、WMI も空になりやすい | 高い | Get-ADObject / ADSIEdit / dumpadcfg |
| 参照関係の不整合 | DN 参照が別名を向き、手動作成で名前解決エラー | 高い | dumpadcfg で DN を横断確認 |
| ACL 破損 | サービスは動くが「子オブジェクト作成」が失敗し続ける | 中〜高 | DC1/DC2 で ACL を比較 |
| 移行状態の取りこぼし | SYSVOL を DFSR として扱う前提が崩れ、片側だけ不整合 | 中 | dfsrmig の状態確認 + AD オブジェクト整合性 |
| 別要因（WMI/サービス破損） | 構成があっても WMI が壊れて見えない | 低〜中 | 他の DFSR クラスも取れない/イベントの傾向が違う |
質問にある「見えないメタデータ破損（Exchange の残骸など）」は、上の表でいう 参照関係の不整合や ACL 破損として現れることが多いです。今回、手動作成でも制約違反・名前解決エラーが出ているため、“AD の中で、作るべき場所が正常な状態ではない”可能性が高いと判断できます。
復旧の実務手順
ここからは「直す」手順です。ポイントは、DC1 を SYSVOL DFSR の正しい参加者に戻し、DC2 が初期同期を開始できる状態を作ることです。
手順の全体像
| フェーズ | 目的 | 成功の判断材料 |
|---|---|---|
| 構成の可視化 | 欠落/破損箇所を確定 | dumpadcfg と ADSIEdit が一致して “足りないもの” が見える |
| 権限・複製の健全化 | 作れる状態に戻す | AD オブジェクトが作成できる/複製される |
| Subscription の再構築 | DC1 を参加者に復帰 | DC1 の DFSR-LocalSettings に Domain System Volume / Subscription が揃う |
| 初期同期の開始 | DC2 が SYSVOL を受け取る | イベントログに初期同期の流れが出て、SYSVOL/NETLOGON が安定 |
DC1 側で AD 構成の再読み込みを促す（軽い順から）
“たまたま反映が遅いだけ” を除外するため、まずは軽い操作で DFSR に AD を読ませます。
# AD ポーリングを促す
dfsrdiag pollad
# サービス再起動
net stop dfsr
net start dfsrここで DC1 の ADSIEdit に Domain System Volume / SYSVOL Subscription が生えてくるなら、それで終わりです。今回は生えない前提なので、次に進みます。
SysVolReady のトグルで「再認識」のきっかけを作る
DC1 が SYSVOL の状態を誤認している場合、トグルが効くことがあります（すでに試していても、Subscription 再構築後に改めて実施する価値があります）。
# いったん非準備状態
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Domain System Volume" `
-Name "SysVolReady" -Value 0
net stop dfsr
net start dfsr
# 準備完了に戻す
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Domain System Volume" `
-Name "SysVolReady" -Value 1この操作の狙いは「DFSR に SYSVOL 周りの状態遷移をもう一度踏ませる」ことです。ただし、AD 側に Subscription が無い（または壊れている）なら、何度やっても初期同期には進みません。
AD オブジェクトの複製と整合性を確認する
“DC1 で見えない”のが「ローカルに無い」のか「複製されていない」のかを切り分けます。
repadmin /showobjmeta DC1 "CN=DFSR-LocalSettings,CN=DC1,OU=Domain Controllers,DC=corp,DC=example,DC=uk"また、オブジェクトが存在するはずの DN を指定して、メタデータ（いつ誰がどう更新したか）を確認します。ここで不自然な履歴が出る場合、過去の操作や復元で矛盾が混入している可能性があります。
ACL の比較で「作れない理由」を潰す
DC1 と DC2 の次の場所で、アクセス許可の差分を見ます。
- CN=DFSR-LocalSettings,CN=DC1,OU=Domain Controllers,…
- CN=DFSR-LocalSettings,CN=DC2,OU=Domain Controllers,…
特に重要なのは、DC1 のコンピューターアカウントが次を持っているかです。
- 子オブジェクトの作成（Create Child）
- 必要な属性の書き込み（Write）
- 継承が意図せずブロックされていないこと
もし DC1 側だけ継承が切れていたり、権限が欠けている場合は、Subscription が作れない直接原因になります。ここは“正”に戻してから次へ進むのが安全です。
Subscription を再構築する現実的な方法
今回のように、DC1 が自動生成できず、手動作成も制約違反でこける場合、作戦は大きく 2 つです。
不要・不正な DFSR/Exchange 関連オブジェクトを先にクリーンアップする
「作れない」の裏に、同名のゴミ・参照不整合・孤立オブジェクトが潜んでいることがあります。特に、過去に Exchange を導入して削除している環境は “歴史のゴミ” が溜まりやすいです。
確認観点の例：
- CN=System 配下に、不要な msDFSR-* が残っていないか（参照先の DC が存在しないなど）
- Deleted Objects に DFSR 関連が大量に残っていないか（復元・削除を繰り返した痕跡）
- CN=Microsoft Exchange System Objects 等に、GPO や SYSVOL 周りと干渉し得る“不正な参照”がないか
ここで重要なのは、いきなり大量削除しないことです。まず dumpadcfg の内容と照らし、SYSVOL のレプリケーショングループや参照がどこでねじれているかを特定してから、影響範囲が限定できる形で掃除します。
DC2 の正常な Subscription を「雛形」にして DC1 用を作り直す（LDIFDE アプローチ）
最終的に効果が出やすいのは、正常な DC2 の Subscription をエクスポートして、DC1 用に調整してインポートする方法です。これは AD を直接いじるため難易度が高いですが、“正しい形”をコピーできるのが強みです。
作業イメージ（概要）
- DC2 の SYSVOL Subscription をエクスポート
- エクスポートした LDF を編集して、DN や参照先を DC1 に合わせる
- DC1 用としてインポート
- DFSR に AD 再読み込み（pollad）→ サービス再起動
- イベントログと SYSVOL/NETLOGON 共有で成否確認
コマンド例（環境に合わせて DN は必ず調整）
REM 例：DC2 の Subscription をエクスポート（DN は環境に合わせて変更）
ldifde -f sub_dc2.ldf -d "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC2,OU=Domain Controllers,DC=corp,DC=example,DC=uk" -p base編集時の考え方はシンプルで、「名前（DN）と参照（DC 名・Computer DN）を DC1 に向け直す」ことです。逆に、システムが自動で持つ属性（作成日時や更新番号など）を持ち込むと制約違反の元になります。インポート前に余計な属性を削るのがコツです。
インポート例：
ldifde -i -f sub_dc1.ldf注意点
- この手順は “正しい雛形がある” ことが前提です（DC2 が正常形を持っていること）
- DN の 1 文字違いで「名前解決エラー」になります（特に OU 名や DC 名）
- バックアップ前提。可能なら検証環境で LDF を作ってから本番に適用します
質問のケースでは、最終的にDC1 の CN=SYSVOL Subscription を慎重に作り直し、Exchange 関連の AD オブジェクトを徹底的にクリーンアップすることで正常化しています。まさにこのパターンが “刺さる” 典型例です。
初期同期を「走らせる」ための最終仕上げ
Subscription を正しい形に戻したら、次は DFSR に初期同期を開始させます。ここで大事なのは、「DC1 が権威（authoritative）としての役割を果たせる状態」を作ることです。
DC1/DC2 で AD 構成の再読み込みとサービス再起動
dfsrdiag pollad
net stop dfsr
net start dfsrイベントログで “状態遷移” を追う
「アプリケーションとサービス ログ」→「DFS Replication」で、少なくとも次のような流れが出てくるかを見ます。
- 構成の読み込み
- SYSVOL に対する初期化・同期開始を示すイベント（環境によって前後しますが、今回の文脈では 4114 / 4614 / 4604 などが目安）
- 同期完了に向かうイベント
ここで依然として「1206 までは出るが、その先が出ない」なら、Subscription 自体は作れても、参照関係・権限・メタデータのどこかがまだ不整合です。dumpadcfg に戻って “DC1 の参加情報が完全に揃ったか” を再確認します。
復旧できたかどうかの確認（これが通れば勝ち）
“ログがそれっぽい”だけでは不十分です。SYSVOL は GPO 配布の生命線なので、運用目線で確認します。
| 確認項目 | コマンド/見方 | 期待値 |
|---|---|---|
| SYSVOL/NETLOGON 共有 | net share | 両 DC で SYSVOL / NETLOGON が安定して存在 |
| DFSR の WMI にフォルダーが見える | Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo | DC1 でも結果が返り、SYSVOL が管理対象として見える |
| バックログの確認 | dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC1 /rmem:DC2 | 一時的に数が出ても、最終的に 0 に向かう |
| GPO の実動 | クライアントで gpupdate /force | 新旧 GPO が意図どおりに適用される |
特に DC1 側の WMI が空でなくなるのは大きな前進です。これは「DFSR が AD 構成を取り込み、管理対象フォルダーを持った」ことを意味します。
それでも直らない場合の現実的な最終手段
ここまでやっても DC1 がどうしても参加者として成立しない場合、時間を溶かし続けるより、“壊れているノードを作り直す”ほうが結果的に安全・確実なことがあります。
DC1 の降格→メタデータクリーンアップ→再昇格
- DC1 をドメイン コントローラーから降格
- 必要に応じて ntdsutil でメタデータクリーンアップ
- DC2 を健全な状態にしてから、DC1 を新規 DC として再昇格
この作戦のメリットは、“壊れた DFSR ローカル設定”を AD から追い出して作り直せることです。もちろん影響は大きいので、FSMO 役割や DNS、認証経路を整理したうえで計画的に行います。
再発防止のために押さえておきたい運用ポイント
SYSVOL DFSR のトラブルは「直したら終わり」ではなく、同じ匂いの問題が再発しがちです。運用で意識すると効くポイントをまとめます。
- “dcdiag が正常＝SYSVOL も正常”ではない：DFSR の AD 構成（msDFSR-*）は別監視にする
- dfsrdiag dumpadcfg を定期的に採取：差分が出たタイミングで異常検知しやすい
- ADSIEdit の直接編集は最後の手段：やるなら変更範囲を最小化し、必ずバックアップ
- 古い製品（旧 Exchange など）を撤去した環境は、“残骸が残る前提”で棚卸しする
- DC のスナップショット運用・復元手順を明確化：安易な巻き戻しは整合性事故の起点になり得る
まとめ
Windows Server 2022 のドメインで「DC 追加後に DFSR SYSVOL 複製が始まらない」症状は、サービスやネットワークよりも、AD 内の DFSR メタデータ（特に DC1 の SYSVOL Subscription）不整合で起きることが多いです。
- DC2 では Subscription が作れるのに、DC1 の DFSR-LocalSettings が空のままなら、まずそこを疑う
- dfsrdiag dumpadcfg で全体像を掴み、Get-ADObject/ADSIEdit で欠落を確定
- ACL・参照関係・孤立オブジェクト（Exchange 残骸を含む）を整理し、Subscription を正しい形に戻す
- 最後に pollad とサービス再起動で状態遷移を起こし、イベントログと SYSVOL 共有で勝ちを確認
「再インストールしても直らない」タイプの SYSVOL トラブルは、“AD オブジェクトの正しさ”が最短ルートです。構成を俯瞰し、欠落を正しい形で埋める、という方針で攻めると復旧が速くなります。
コメント