新しい DC に SYSVOL / NETLOGON 共有がない場合は、まず DNS・AD レプリケーション・DFSR のイベントを確認します。共有がないだけで非権威的復元が必要とは限りません。本記事では Windows Server 2019 / 2025 の確認手順と、正常な同期元がある場合に限る DFSR の非権威的同期を整理します。既存の正常な SYSVOL と復元可能なバックアップを確認できない場合は、変更を止めて管理者・Microsoft サポートへ相談してください。
既存ドメインに新しい DC を追加したのに動かない症状
まずは、今回想定しているトラブルの典型的な症状を整理します。既存のドメインに新しいドメイン コントローラー（DC）を追加した直後に、次のような状態になっているケースです。
- 対象 OS: Windows Server 2025 または Windows Server 2019（いずれも AD DS 役割を追加済み）
- 既存ドメインにはすでに稼働中の DC が 1 台以上存在
- 新 DC で
dcdiag /test:Advertisingを実行すると失敗 - 新 DC に SYSVOL 共有 が存在しない（
net shareで確認） - DNS や時刻同期など基本的なチェックは一通り実施済み
典型的な確認結果を、表にまとめると次のようになります。
| 確認項目 | コマンド / 画面 | 典型的な症状 |
|---|---|---|
| DC の広告状況 | dcdiag /test:Advertising | 「Server is not responding or is not considered suitable」と表示され失敗 |
| SYSVOL の状態 | dcdiag /test:sysvolcheck | SysvolReady の値を検査。共有の存在やアクセス可否は別に確認 |
| 共有フォルダー | net share | SYSVOL および NETLOGON 共有が存在しない |
| イベント ログ | イベント ビューアー → DFS Replication | 4614 の後に4604があるか、2213などの停止・回復イベントと本文を確認 |
| DNS 設定 | NIC の IPv4 プロパティ | 既存 DC を参照するよう設定済み（あるいは調整済み） |
この状態では、DC の昇格ウィザード自体は正常終了しているのに、新しい DC がクライアントや他の DC から「正式な DC」として認識されません。その結果、ログオンやグループ ポリシーの配布などで思わぬ不具合を招くことがあります。
原因候補：SYSVOL の初期 DFS レプリケーションが終わっていない
確認する原因の一つは、SYSVOL の初期 DFS レプリケーションが完了していない ことです。
Windows Server 2019 / 2025 では、SYSVOL のレプリケーション エンジンとして DFSR（DFS Replication） が利用されます。新しい DC をドメインに参加させた直後、次のような流れで SYSVOL が同期されます。
| フェーズ | 状態 | DC の挙動 |
|---|---|---|
| フェーズ 1 | AD データベース（NTDS）のレプリケーション | ユーザー/コンピューター/グループなどディレクトリ情報が同期される |
| フェーズ 2 | SYSVOL の初期 DFS レプリケーション | グループ ポリシーやログオン スクリプトを含む SYSVOL が DFSR によってコピーされる |
| フェーズ 3 | SYSVOL 共有の公開 | SYSVOL/NETLOGON 共有が作成され、DC が「広告」される |
このうち、フェーズ 2 が完了していない と、DC は自分自身を「クライアントにサービスを提供するのに適切（suitable）」として広告できません。そのため、dcdiag /test:Advertising で
Server is not responding or is not considered suitable
などの結果になる場合があります。ただし Advertising の失敗はDFSRだけでなく、Netlogon・KDCなど別の要因でも起こるため、エラー本文を併せて確認します。
つまり、DNS や時刻同期などの構成が問題ないにもかかわらず広告に失敗する場合、SYSVOL の DFSR が正常に完了しているかどうか を真っ先に疑うべきです。
DNS・通信・AD レプリケーションを先に切り分ける
DFSR の初期同期には相手 DC との通信が必要です。DNS や通信障害が原因なら、それを解消せずに非権威的復元を行っても同期できません。repadmin /replsummary と repadmin /showrepl、DNS 名前解決、DFSR イベント本文を先に確認します。ファイアウォールや IPv6 の一律無効化、DFSR データベースの削除は一般的な解決手順にしません。
Microsoft のSYSVOL / NETLOGON 共有欠落の診断に沿って、初期同期待ち、dirty shutdown 後の回復停止、長期オフラインによる保護停止などを区別します。
トラブル対応前に確認しておきたい前提条件
SYSVOL の非権威的復元を行う前に、次の前提を満たしているか必ず確認してください。
| 前提条件 | 内容 |
|---|---|
| 健全な DC が 1 台以上存在 | SYSVOL の「正」となる DC（グループ ポリシー、スクリプトが正常）が必要です。 |
| AD レプリケーションに致命的なエラーがない | repadmin /replsummary や dcdiag 全体で重大なエラーがないことを確認します。 |
| 復元可能なバックアップ | 対象 DC と同期元の SYSVOL の内容、復元可能なバックアップ、復旧計画を確認してから作業します。単なるVMスナップショットをバックアップの代替と決めつけません。 |
| 作業時間帯 | グループ ポリシー配布などへ影響が出ない時間帯に作業するのが安全です。 |
特に、すべての DC が同じように壊れている状況で無造作に D2 を行うのは危険 です。必ず「正常な SYSVOL を持っている DC」を 1 台は確保してから作業を進めましょう。
SYSVOL と DFSR の状態を確認する具体的な手順
次に、新しく追加した DC で SYSVOL と DFSR がどのような状態になっているかを確認します。
dcdiag の検査範囲を区別する
dcdiag /test:SysVolCheck /v は SysvolReady が1かを確認する検査で、共有へのアクセスを検証するものではありません。dcdiag /test:NetLogons /v、net share、実際の共有内容も合わせて確認します。DC が適切に自身を通知しているかのテスト名は Advertising です。
Microsoft：dcdiag の各テストを参照し、ひとつの成功だけで同期完了と判断しないでください。
net share で SYSVOL/NETLOGON 共有の有無を確認
次に、単純ですが非常に重要な確認として net share を実行します。
net share
正常な DC であれば、一覧の中に次の共有が存在します。
- SYSVOL
- NETLOGON
これらが表示されない場合、まだ SYSVOL が「DC として公開されるステータス」になっていません。DFS Replication の状態を必ず確認しましょう。
イベント ビューアーの「DFS Replication」ログを確認
［アプリケーションとサービス ログ］→［DFS Replication］で、対象 DC と同期元の時刻・イベント本文を確認します。
- 4614：初期同期待ち。後続の4604があるか確認します。
- 4604：SYSVOL の初期同期が完了したことを示します。非権威的同期で確認するイベントです。
- 4114：レプリケートフォルダーが無効化されたことを示します。非権威的同期では無効化段階の確認に使います。
- 4602：SYSVOL をプライマリメンバーとして初期化したことを示します。非権威的同期の完了条件ではありません。
- 2213：dirty shutdown 後に回復が停止し、手動再開が必要な場合があります。イベントの対象ボリュームと指示を確認します。
- 2214：dirty shutdown 後のデータベース回復完了です。「回復保留」ではありません。
- 4012：長期間オフラインだったことによるコンテンツの鮮度保護などを確認します。2213と同じ対処にしません。
イベントがないことだけで復元の要否を決めず、現在の状態と共有の内容を照合します。
解決策：非権威的 SYSVOL 復元（D2）の手順
通信・AD レプリケーションを直しても対象 DC の SYSVOL を正常な同期元から再同期する必要があると確認できた場合に、非権威的同期を検討します。D2 / D4 はFRSの用語を対応づけた呼び方であり、DFSRでFRSのBurFlagsを設定するわけではありません。
D2（非権威的復元）とは
DFSR の世界では、SYSVOL の復元方法として大きく次の 2 つがあります。
| 種類 | 意味 | 主な用途 |
|---|---|---|
| 非権威的復元（D2） | 対象サーバー上の SYSVOL を「正ではない」とマークし、他の正常な DC から内容を再同期する。 | 問題が起きている DC 側だけをリセットしたいとき（今回はこちら）。 |
| 権威的復元（D4） | ある DC の SYSVOL を「正」とみなし、他の DC へその内容を配布する。 | 「この DC の SYSVOL を基準に全体を上書きしたい」ときのみ使用（慎重な判断が必要）。 |
新 DC だけの問題でも、常に非権威的復元が必要とは限りません。正常な同期元がない場合や複数 DC が不整合の場合は、ここで止めて復旧計画を作成します。権威的同期はドメイン全体へ影響するため、本記事の単一 DC の手順と混同しないでください。
非権威的同期の手順：対象 DC のみ
以下はMicrosoft の非権威的同期手順に対応する流れです。管理権限を持つ担当者が、対象 DC の識別名、正常な同期元、バックアップ、AD複製の正常性を確認して行います。この手順のために DFSR サービスを停止したり、存在を確認できない setd2 メソッドを実行したりしません。
- ADSI Edit で対象 DC の
CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<対象DC>,OU=Domain Controllers,DC=<ドメイン>にあるmsDFSR-EnabledをFALSEにします。実際の識別名は環境に合わせ、別DCのオブジェクトを変更しないでください。 - AD レプリケーションを実行・検証し、変更がドメイン内へ反映されたことを確認します。エラーがあれば次へ進みません。
- 対象 DC で
DFSRDIAG POLLADを実行し、DFS Replication ログに 4114 が記録されたことを確認します。ツールがない場合は管理者に必要な管理ツールを確認し、別のコマンドを推測しません。 - 同じ対象オブジェクトの
msDFSR-EnabledをTRUEに戻します。 - 再び AD レプリケーションを実行・検証し、対象 DC で
DFSRDIAG POLLADを実行します。 - 4614 の後に4604が記録されることを確認します。4614で止まる場合は、同期元と通信・イベント本文を再確認し、変更を繰り返さないでください。
net share、dcdiag /test:SysVolCheck /v、dcdiag /test:NetLogons /v、dcdiag /test:Advertising /vをそれぞれ実行します。SYSVOL / NETLOGON共有だけでなく、GPO・スクリプトの内容とAD複製も確認します。
SYSVOL_READY レジストリ値の確認（必要に応じて）
場合によっては、Netlogon サービスが SYSVOL を「準備完了」と認識しているかどうかを、レジストリで確認することも有効です。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- 値の名前: SysvolReady（DWORD）
- 0 の場合: SYSVOL が準備完了ではないと認識されている
- 1 の場合: SYSVOL が準備完了と認識されている
通常は DFSR の復旧が完了すれば自動的に 1 になります。レジストリ値だけを強制的に変更しても根本原因が解決しないため、原因に応じた DFSR の診断・復旧を行ってください。
DNS 設定のベスト プラクティス（昇格前と昇格後）
SYSVOL の問題とは別に、DC の昇格時にありがちな DNS 設定の落とし穴についても整理しておきます。誤った DNS 設定は、AD レプリケーション全般に悪影響を及ぼすためです。
| タイミング | 推奨設定 | 注意点 |
|---|---|---|
| 新 DC 昇格 前 | プライマリ DNS に「既存の DC の IP アドレス」を指定し、セカンダリに他の DC（あれば）を指定。 | 127.0.0.1 を指定しない。昇格前は自分自身はまだ DNS として機能していないため。 |
| 初期複製完了後の安定運用時 | 初期のAD・DNS複製完了までは既存の正常なDNSサーバーを参照。完了後はサイト設計に応じて自分自身・他の内部DNSを構成。 | すべての DC が同じ DC だけを参照しないよう、役割を分散させる。 |
| クライアント PC | 同一サイト内の DC を優先する。DHCP を利用して一元管理するのが望ましい。 | 外部 DNS（ISP など）を直接クライアントに設定しない。名前解決は DC 経由で行わせる。 |
今回の症状は主に SYSVOL/DFSR が原因ですが、DNS 設定が適切でない場合、レプリケーションに失敗して DFSR がさらに混乱することもあります。昇格前の DNS 設定は特に慎重に行いましょう。
追加のチェックポイント：repadmin・時刻同期・ファイアウォール
復元を検討する前に、他の DC も含めて次の点を確認します。
repadmin で AD レプリケーションを確認
repadmin /replsummary と repadmin /showrepl でエラーと最終成功時刻を確認します。repadmin /syncall は状態表示だけでなく同期を実行するコマンドです。実行する場合は対象・サイト範囲を管理者が決め、単なる確認のために全サイトへ一律実行しません。
時刻同期（w32tm）の確認
Kerberos 認証は時刻差に敏感です。許容値はポリシーによるため、環境の設定と実際のずれを確認します。時刻が大きくずれていると、レプリケーション全般にも影響します。
w32tm /query /status
w32tm /query /source
ドメインの時刻同期階層と、フォレストルートの PDC エミュレーターが参照する時刻ソースを確認します。すべての端末を同じ外部NTPへ変更する手順ではありません。
ファイアウォールと IPv6
トラブルシュートの過程で、ついファイアウォールや IPv6 を無効化してしまうことがありますが、原因切り分け後は必ず標準設定に戻す ことを推奨します。
- Windows ファイアウォールの適用規則と、DC間のネットワーク機器の許可通信を確認します。ドメインプロファイルだから必要な通信がすべて通るとは限りません。
- IPv6 をむやみに無効化すると、将来の機能や一部コンポーネントで想定外の挙動を招く可能性があります。
「一時的に無効にしたら直った」場合でも、そのまま放置せず、なぜ無効化が必要だったのか を振り返り、可能な限り標準構成へ戻すことが重要です。
よくあるトラブル パターンと対処の考え方
同じような症状でも、環境によって細かい原因は異なります。よくあるパターンと対処の考え方をいくつか挙げます。
パターン 1：新 DC だけが SYSVOL 未作成
同期元が正常か、4614の後に4604があるか、DNS・通信・AD複製に問題がないかを調べます。初期同期待ちというだけで非権威的同期を実行せず、原因を先に解消します。
パターン 2：複数 DC で DFSR エラーが発生
どのSYSVOLが正しいか不明なら変更を止めます。GPO・スクリプトの更新履歴とバックアップを比較し、管理者またはMicrosoftサポートと復旧計画を作成してください。すべてのDCへ一律に非権威的同期を実行する手順ではありません。
パターン 3：イベント 2213 による回復停止
dirty shutdown 後の回復停止が記録されている場合は、対象ボリュームのデータを保全し、イベント本文と公式診断に従って再開します。ResumeReplication による回復再開と、SYSVOL Subscriptionを変更する非権威的同期は別の操作です。2214は回復完了の記録として確認します。
今後同じ問題を防ぐための運用上のポイント
最後に、今後同じトラブルを避けるための運用上のポイントを整理しておきます。
新しい DC 追加時の標準手順を文書化する
- 昇格前に設定すべき DNS の内容（既存 DC をプライマリにするなど）
- 昇格後に実行する確認コマンド（
dcdiag/repadmin/net share） - SYSVOL/DFSR のイベント ログを確認するタイミング
これらをチェックリストとしてまとめておくと、「昇格したつもりだが実は DC として動いていない」といった事故を防ぎやすくなります。
グループ ポリシー変更時のバックアップと記録
SYSVOL にはグループ ポリシー オブジェクト（GPO）のファイルが格納されています。重要な GPO を多数運用している環境では、
- GPO のバックアップを定期的に取得する
- 重要な変更にはチケット番号や変更理由を残す
- テスト用 OU や検証環境での事前検証を徹底する
といった運用を行うことで、万が一 DFSR のトラブルが発生しても「どの状態を正とすべきか」を判断しやすくなります。
定期的なヘルスチェックの自動化
手作業だけに頼らず、タスク スケジューラや監視ツールを使って、次のようなコマンドを定期実行し、結果をログとして保存するのも有効です。
dcdiag /v
repadmin /replsummary
repadmin /showrepl
これにより、「ある日突然 DC が壊れた」のではなく、「数日前からエラーが出ていた」ということに気づきやすくなります。
まとめ：SYSVOL 共有がない場合の確認順
- DNS・通信・ADレプリケーションの正常性を確認する。
- SYSVOL / NETLOGON の共有と実際の内容、DFSRイベント本文・時刻を確認する。
- 初期同期の4614と4604、dirty shutdown回復の2213と2214を区別する。
- 復元が必要と確認できた場合だけ、正常な同期元とバックアップを確保して公式の非権威的同期手順を実施する。
- 共有の再出現だけで終わらず、各dcdiagテスト・GPO内容・複製状態を確認する。
コメント