既存の Active Directory ドメインに Windows Server 2025 / 2019 をドメイン コントローラーとして追加したのに、dcdiag では「Server is not responding or is not considered suitable」と表示され SYSVOL 共有も作成されない――本記事では、このよくある現場トラブルの原因と、DFS レプリケーションを使った SYSVOL の非権威的復元（D2）による解決手順を、チェックポイント付きで丁寧に解説します。
既存ドメインに新しい DC を追加したのに動かない症状
まずは、今回想定しているトラブルの典型的な症状を整理します。既存のドメインに新しいドメイン コントローラー（DC）を追加した直後に、次のような状態になっているケースです。
- 対象 OS: Windows Server 2025 または Windows Server 2019（いずれも AD DS 役割を追加済み）
- 既存ドメインにはすでに稼働中の DC が 1 台以上存在
- 新 DC で
dcdiag /test:advertisementを実行すると失敗 - 新 DC に SYSVOL 共有 が存在しない（
net shareで確認） - DNS や時刻同期など基本的なチェックは一通り実施済み
典型的な確認結果を、表にまとめると次のようになります。
| 確認項目 | コマンド / 画面 | 典型的な症状 |
|---|---|---|
| DC の広告状況 | dcdiag /test:advertisement | 「Server is not responding or is not considered suitable」と表示され失敗 |
| SYSVOL の状態 | dcdiag /test:sysvolcheck | SYSVOL 共有が見つからない / エラーを返す |
| 共有フォルダー | net share | SYSVOL および NETLOGON 共有が存在しない |
| イベント ログ | イベント ビューアー → DFS Replication | イベント ID 2213 / 2214 / 2002 などが記録され、初期レプリケーション未完了の状態 |
| 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:advertisement で
Server is not responding or is not considered suitable
という結果になってしまいます。
つまり、DNS や時刻同期などの構成が問題ないにもかかわらず広告に失敗する場合、SYSVOL の DFSR が正常に完了しているかどうか を真っ先に疑うべきです。
なぜ DNS やファイアウォール変更では解決しないのか
この問題に直面した管理者が最初に行うのは、多くの場合次のような対処です。
- DNS サーバーの構成変更
- ファイアウォールを無効化
- IPv6 を無効化
- 時刻同期の再設定（
w32tm） repadmin /syncallによるレプリケーションの再試行
これらは確かに AD トラブルの切り分けとして重要ですが、今回の現象の本丸は SYSVOL の DFSR の状態 にあります。DFS Replication サービスが「初期レプリケーション未完了」のステータスになっている場合、DNS やファイアウォールをどれだけ調整しても、SYSVOL 共有が作成されることはありません。
したがって、DFS Replication のイベント ログと SYSVOL の状態を確認し、必要であれば非権威的復元（D2）を実施すること が解決への近道になります。
トラブル対応前に確認しておきたい前提条件
SYSVOL の非権威的復元を行う前に、次の前提を満たしているか必ず確認してください。
| 前提条件 | 内容 |
|---|---|
| 健全な DC が 1 台以上存在 | SYSVOL の「正」となる DC（グループ ポリシー、スクリプトが正常）が必要です。 |
| AD レプリケーションに致命的なエラーがない | repadmin /replsummary や dcdiag 全体で重大なエラーがないことを確認します。 |
| バックアップ / スナップショット | 可能であれば、対象 DC と「正」とする DC のバックアップを取得してから作業します。 |
| 作業時間帯 | グループ ポリシー配布などへ影響が出ない時間帯に作業するのが安全です。 |
特に、すべての DC が同じように壊れている状況で無造作に D2 を行うのは危険 です。必ず「正常な SYSVOL を持っている DC」を 1 台は確保してから作業を進めましょう。
SYSVOL と DFSR の状態を確認する具体的な手順
次に、新しく追加した DC で SYSVOL と DFSR がどのような状態になっているかを確認します。
dcdiag /test:sysvolcheck で SYSVOL のヘルスを確認
まずは、dcdiag で SYSVOL の状態を確認します。
dcdiag /test:sysvolcheck /v
- 正常な場合: SYSVOL 共有が存在し、テストは成功します。
- 今回の問題が発生している場合: SYSVOL に関するエラーや警告が出力されます。
ここでエラーとなる場合、ほぼ間違いなく SYSVOL 共有が作成されていない か、DFSR が正常に動いていません。
net share で SYSVOL/NETLOGON 共有の有無を確認
次に、単純ですが非常に重要な確認として net share を実行します。
net share
正常な DC であれば、一覧の中に次の共有が存在します。
- SYSVOL
- NETLOGON
これらが表示されない場合、まだ SYSVOL が「DC として公開されるステータス」になっていません。DFS Replication の状態を必ず確認しましょう。
イベント ビューアーの「DFS Replication」ログを確認
DFS Replication の状態はイベント ログに詳細が記録されています。
- 新 DC で「イベント ビューアー」を起動
- アプリケーションとサービス ログ → DFS Replication を開く
- 次のようなイベント ID を探す
- 2213
- 2214
- 2002
- 4602（完了時に出る）
代表的なイベントの意味を、簡単に整理しておきます。
| イベント ID | 概要 | 状態の目安 |
|---|---|---|
| 2213 | 長期間の障害などにより DFSR が自動的に停止している / 管理者の介入が必要 | この状態のままでは SYSVOL は同期再開されない |
| 2214 | レプリケーション フォルダーが回復保留中など、初期レプリケーション未完了を示唆 | 初期同期が終わっておらず、共有公開されない |
| 2002 | レプリケーション グループ/フォルダーの構成に関する情報 | 設定変更の際や、初期構成時に出ることが多い |
| 4602 | SYSVOL の DFSR 初期レプリケーションが完了したことを示す | このイベントが出ていれば、SYSVOL 共有が作成される条件が整った状態 |
イベント ID 4602 が出ていない 場合、SYSVOL の DFSR 初期レプリケーションは完了していません。この状態を解消するのが、次で説明する 非権威的 SYSVOL 復元（D2） です。
解決策：非権威的 SYSVOL 復元（D2）の手順
新しい DC 側で SYSVOL の状態が不完全な場合、非権威的 SYSVOL 復元（D2） を実施して、正常な DC から SYSVOL を再取得させるのが定石です。
D2（非権威的復元）とは
DFSR の世界では、SYSVOL の復元方法として大きく次の 2 つがあります。
| 種類 | 意味 | 主な用途 |
|---|---|---|
| 非権威的復元（D2） | 対象サーバー上の SYSVOL を「正ではない」とマークし、他の正常な DC から内容を再同期する。 | 問題が起きている DC 側だけをリセットしたいとき（今回はこちら）。 |
| 権威的復元（D4） | ある DC の SYSVOL を「正」とみなし、他の DC へその内容を配布する。 | 「この DC の SYSVOL を基準に全体を上書きしたい」ときのみ使用（慎重な判断が必要）。 |
今回のように「新しく追加した DC だけがおかしい」ケースでは、必ず D2（非権威的復元） を使用します。誤って D4 を実行すると、正常な DC 側の SYSVOL を上書きしてしまう危険があります。
D2 実行手順（新 DC 側で実施）
以下の手順は、新しく追加した DC についてのみ実施します。既存の正常な DC では実行しません。
- DFS Replication サービスを停止
net stop dfsrサービスが完全に停止するまで待ちます。 - WMIC で SYSVOL のレプリケーション状態を D2 に設定 コマンド プロンプト（管理者）または PowerShell（管理者）で次を実行します。
wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo ` where replicatedfoldername='SYSVOL Share' call setd2PowerShell 上で実行する場合、改行やバッククォートの扱いに注意してください。1 行で実行しても問題ありません。 - DFS Replication サービスを開始
net start dfsrこの時点で DFSR は「自分は正ではない（非権威的）」と認識し、正常な DC から SYSVOL を再同期し始めます。 - DFS Replication イベント ログを監視
- イベント ビューアー → DFS Replication を開く
- イベント ID 4602 が記録されるまで待つ
- SYSVOL/NETLOGON 共有が作成されたか確認
net share一覧の中に SYSVOL と NETLOGON が表示されていれば、共有として公開されています。 - dcdiag で再チェック
dcdiag /test:sysvolcheck dcdiag /test:advertisementいずれも成功するようになれば、新しい DC は「適切な DC」として広告され、クライアントから利用可能な状態になっています。
SYSVOL_READY レジストリ値の確認（必要に応じて）
場合によっては、Netlogon サービスが SYSVOL を「準備完了」と認識しているかどうかを、レジストリで確認することも有効です。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- 値の名前: SysvolReady（DWORD）
- 0 の場合: SYSVOL が準備完了ではないと認識されている
- 1 の場合: SYSVOL が準備完了と認識されている
通常は DFSR の復旧が完了すれば自動的に 1 になります。レジストリ値だけを強制的に変更しても根本原因が解決しないため、DFSR の修復（D2）を優先 してください。
DNS 設定のベスト プラクティス（昇格前と昇格後）
SYSVOL の問題とは別に、DC の昇格時にありがちな DNS 設定の落とし穴についても整理しておきます。誤った DNS 設定は、AD レプリケーション全般に悪影響を及ぼすためです。
| タイミング | 推奨設定 | 注意点 |
|---|---|---|
| 新 DC 昇格 前 | プライマリ DNS に「既存の DC の IP アドレス」を指定し、セカンダリに他の DC（あれば）を指定。 | 127.0.0.1 を指定しない。昇格前は自分自身はまだ DNS として機能していないため。 |
| 昇格直後〜安定運用時 | プライマリ DNS を自分自身、セカンダリ DNS を別の DC にする構成が一般的。 | すべての DC が同じ DC だけを参照しないよう、役割を分散させる。 |
| クライアント PC | 同一サイト内の DC を優先する。DHCP を利用して一元管理するのが望ましい。 | 外部 DNS（ISP など）を直接クライアントに設定しない。名前解決は DC 経由で行わせる。 |
今回の症状は主に SYSVOL/DFSR が原因ですが、DNS 設定が適切でない場合、レプリケーションに失敗して DFSR がさらに混乱することもあります。昇格前の DNS 設定は特に慎重に行いましょう。
追加のチェックポイント：repadmin・時刻同期・ファイアウォール
D2 を実行しても問題が解消しない場合や、他の DC でも不具合が疑われる場合は、次の点もあわせて確認します。
repadmin /syncall /AdeP で AD レプリケーションを確認
repadmin /syncall /AdeP
/A: すべての名前付けコンテキスト/d: 詳細出力/e: すべてのサイト間でレプリケーション/P: プッシュ レプリケーション
重大なエラーが出ていないか確認し、必要に応じて接続オブジェクトやサイト/サブネットの設計を見直します。
時刻同期（w32tm）の確認
Kerberos 認証は時刻差に敏感で、5 分以上ずれていると認証エラーになります。時刻が大きくずれていると、レプリケーション全般にも影響します。
w32tm /query /status
w32tm /query /source
PDC エミュレーター ロールを持つ DC は信頼できる外部 NTP サーバーと同期し、他の DC やメンバー サーバーはその PDC と同期する構成が基本です。
ファイアウォールと IPv6
トラブルシュートの過程で、ついファイアウォールや IPv6 を無効化してしまうことがありますが、原因切り分け後は必ず標準設定に戻す ことを推奨します。
- Windows ファイアウォールは、標準の「ドメイン プロファイル」であれば AD に必要なポートが自動的に許可されます。
- IPv6 をむやみに無効化すると、将来の機能や一部コンポーネントで想定外の挙動を招く可能性があります。
「一時的に無効にしたら直った」場合でも、そのまま放置せず、なぜ無効化が必要だったのか を振り返り、可能な限り標準構成へ戻すことが重要です。
よくあるトラブル パターンと対処の考え方
同じような症状でも、環境によって細かい原因は異なります。よくあるパターンと対処の考え方をいくつか挙げます。
パターン 1：新 DC だけが SYSVOL 未作成
- 既存 DC では SYSVOL/NETLOGON 共有が正常に存在する。
- 新 DC のみ SYSVOL 共有が見つからない。
- DFSR ログに 2213 / 2214 が記録されている。
この場合は、本記事で紹介した通り、新 DC で非権威的復元（D2）を実行 するのが基本方針です。正常な DC が SYSVOL の「正」として機能し、新 DC の SYSVOL が再構築されます。
パターン 2：複数 DC で DFSR エラーが発生している
- 複数の DC で DFSR イベントが多数発生している。
- どの DC の SYSVOL が「正」なのか判断がつかない。
この場合は、まず どの DC の SYSVOL を基準とするか を慎重に決める必要があります。グループ ポリシーやスクリプトの更新履歴、変更管理の記録などを確認し、「現場で実際に使っている設定」と齟齬のない DC を選択してください。
その上で、
- 基準とする DC はそのまま維持
- その他の DC に対して D2 を実行して同期し直す
といった形で、段階的に修復するのが安全です。
パターン 3：イベント 2213 による手動再開指示
イベント 2213 は、「長期間の停止や障害により DFSR が自動再開できない状態になっている」ことを示します。この場合、イベントの説明に記載されたコマンド（WMIC など）を実行してレプリケーションを再開させる必要があります。
ただし、闇雲にコマンドを実行するのではなく、DFSR が停止した原因（ディスク障害、バックアップ ソフト、長時間の停止など）を必ず確認すること が重要です。根本原因が解消していないと、再開しても再度同じトラブルが発生します。
今後同じ問題を防ぐための運用上のポイント
最後に、今後同じトラブルを避けるための運用上のポイントを整理しておきます。
新しい DC 追加時の標準手順を文書化する
- 昇格前に設定すべき DNS の内容（既存 DC をプライマリにするなど）
- 昇格後に実行する確認コマンド（
dcdiag/repadmin/net share） - SYSVOL/DFSR のイベント ログを確認するタイミング
これらをチェックリストとしてまとめておくと、「昇格したつもりだが実は DC として動いていない」といった事故を防ぎやすくなります。
グループ ポリシー変更時のバックアップと記録
SYSVOL にはグループ ポリシー オブジェクト（GPO）のファイルが格納されています。重要な GPO を多数運用している環境では、
- GPO のバックアップを定期的に取得する
- 重要な変更にはチケット番号や変更理由を残す
- テスト用 OU や検証環境での事前検証を徹底する
といった運用を行うことで、万が一 DFSR のトラブルが発生しても「どの状態を正とすべきか」を判断しやすくなります。
定期的なヘルスチェックの自動化
手作業だけに頼らず、タスク スケジューラや監視ツールを使って、次のようなコマンドを定期実行し、結果をログとして保存するのも有効です。
dcdiag /v
repadmin /replsummary
repadmin /showrepl
これにより、「ある日突然 DC が壊れた」のではなく、「数日前からエラーが出ていた」ということに気づきやすくなります。
まとめ：新しい DC が「適切」と広告されないときのチェックリスト
既存ドメインに新しい Windows Server 2025 / 2019 ドメイン コントローラーを追加したのに、dcdiag /test:advertisement が
Server is not responding or is not considered suitable
と表示される場合、最優先で疑うべきは SYSVOL の DFS レプリケーション です。
最後に、対応の流れをチェックリストとしてまとめます。
- 新 DC で
dcdiag /test:sysvolcheckを実行し、エラーの有無を確認する。 net shareで SYSVOL / NETLOGON 共有が存在するか確認する。- イベント ビューアーの「DFS Replication」ログで、イベント ID 2213 / 2214 / 2002 / 4602 を確認する。
- イベント 4602 が出ていない場合は、非権威的 SYSVOL 復元（D2）を検討する。
net stop dfsrwmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where replicatedfoldername='SYSVOL Share' call setd2net start dfsr
- SYSVOL/NETLOGON 共有が作成され、
dcdiag /test:advertisementが成功することを確認する。 - あわせて DNS 設定、時刻同期、レプリケーション状況（
repadmin）も確認し、根本原因を取り除く。
これらのポイントを押さえておけば、「新しい DC を追加したのに DC として機能しない」という現場でよくあるトラブルに対して、落ち着いて原因を切り分け、適切に復旧作業を進めることができるはずです。
コメント