DC昇格後にSYSVOL共有が出ない原因と対処法｜確認コマンドと復旧手順を解説

DC昇格後にSYSVOL共有が出ないときは、すぐに「昇格失敗」と決めつけないのが正解です。DFSR を使うドメインでは、昇格後に Active Directory の同期と再起動が終わってから SYSVOL の初期同期が走るため、その完了前は新しい DC が正しく広告されず、SYSVOL や NETLOGON が見えないことがあります。一方で、既存DC側の DFSR 停止、権限設定の崩れ、名前解決や RPC の不通があると、本当に共有は出ません。 (Microsoft Learn)

この記事では、待ち状態と障害の見分け方、最初に打つ確認コマンド、イベント ID ごとの意味、やってはいけない対処、最後の復旧手順まで、実務でそのまま使える形で整理します。

まず理解したい、SYSVOL と NETLOGON の関係

SYSVOL は、ログオンスクリプトやグループポリシーオブジェクトのファイルを複製するための特別な共有です。NETLOGON 共有は、現在有効な SYSVOL の場所を参照します。つまり SYSVOL が出ないと、単に共有が見えないだけでなく、GPO 配布やログオンスクリプト、DC の正常な動作まで影響を受けます。 (Microsoft Learn)

逆に、SYSVOL はあるのに NETLOGON だけ無いなら別問題です。Microsoft には、Netlogon が SysVolReady を早く読み過ぎて scripts フォルダ作成前に共有処理へ進む既知事象があります。本記事は、SYSVOL そのものが出ないケースを前提にしています。 (Microsoft Learn)

まずは「待ち状態」か「障害」かを切り分ける

最初の切り分けは、dcdiag、AD レプリケーション、DFSR 状態の3本です。ここで「新DC単体の問題」なのか、「既存DC側が止まっていて新DCが引っ張れない」のかがほぼ見えます。 (Microsoft Learn)

net share

dcdiag /test:Advertising /test:SysVolCheck /test:NetLogons /test:DFSREvent

repadmin /replsummary
repadmin /showrepl * /csv > showrepl.csv

For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

dcdiag では、Advertising が DC としての広告可否、SysVolCheck が Netlogon の SysVolReady=1 の確認、NetLogons が実際に SYSVOL/NETLOGON 共有へ接続できるか、DFSREvent が過去24時間の DFSR 警告・エラーを確認します。つまり、SysVolCheck だけ通っても「共有が使える」とは言えません。ここを読み違えると、見かけだけ直ったように見えて調査が止まりがちです。 (Microsoft Learn)

repadmin /replsummary は複製失敗の全体像、repadmin /showrepl は inbound replication の失敗箇所を掴むのに向いています。さらに Microsoft の KB にある net view と WMI クエリを全 DC に流せば、どの DC で SYSVOL が共有されていないか、DFSR の state が 2 = Initial Sync、4 = Normal、5 = In Error のどれかを一望できます。 (Microsoft Learn)

DC昇格後にSYSVOL共有が出ない主な原因と対処

一番多いのは「まだ初期同期中」

DFSR ログに 4612 または 4614 が出ていて、4604 が出ていないなら、かなりの確率で「初期同期の待ち」です。Microsoft はこの状態で、昇格中だったサーバーは問題が解決するまで広告されず、正常な DC として機能しないと案内しています。 (Microsoft Learn)

この場合は、新DCをいじり回す前に、まず前提条件を戻します。repadmin /replsummary と repadmin /showrepl で AD レプリケーションを確認し、名前解決、RPC、ファイアウォール、相手DC上の DFSR サービス稼働を見直してください。直した後に、新DCで dfsrdiag pollad を実行し、4604 が出るまで待ちます。4604 が出て初めて「SYSVOL の初期化完了」と判断できます。 (Microsoft Learn)

見落としやすいのが、昇格時にソースとして使った DC です。新しい DC は、昇格時にドメイン名前付けコンテキストを取得した相手を Parent Computer として参照し、そのサーバーから SYSVOL の初期コピーを取りに行きます。もしそのサーバーが再起動後に到達不能になっていれば、初期同期は進みません。必要なら HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seeding SysVols\<domain> の Parent Computer を確認し、Microsoft KB の手順に沿って到達可能な DC を指すよう修正します。 (Microsoft Learn)

新DCではなく、既存DC側が止まっている

ここが実務で一番ハマりやすい点です。SYSVOL 共有が無い DC は、上流のソースDCが DFSR エラー状態だと受信複製できません。つまり、新DCだけを見ても直らず、既存DC側の DFSR を先に復旧しないと詰みます。 (Microsoft Learn)

典型例が 2213 です。これは DFSR が dirty shutdown を検出して複製を止めた状態で、Microsoft はイベント本文に出る ResumeReplication の WMI コマンドで再開するよう案内しています。実行前に複製フォルダーをバックアップし、実行後は 2212 と 2214 を確認します。無理に DB を消すより、この順番で戻すのが基本です。 (Microsoft Learn)

もう一つの典型が 4012 です。これは content freshness protection で、複製失敗が MaxOfflineTimeInDays を超えた状態です。Windows Server 2012 以降の DC では、content freshness が既定で有効で、値は通常 60 日です。長期間停止していた拠点DCや、移行で長くオフラインだった旧DCがあると起きやすく、新DCの pollad だけでは直りません。1台だけ止まっているならその DC を非権威で戻し、全体が止まっているなら最新の SYSVOL を持つ DC を権威にしてやり直します。 (Microsoft Learn)

権限や GPO の変更で DFSR オブジェクト作成に失敗している

DFSR の 6016 や 8028 で Access is denied. が出るなら、msDFSR-LocalSettings などの AD DS オブジェクト更新に失敗している可能性があります。Microsoft は、原因として組み込み Administrators から Manage Auditing and Security Log 権限を外した状態を挙げています。これは DC ではサポートされない構成です。 (Microsoft Learn)

このパターンでは、PDCE で次を実行して、どの GPO がその権利を配っているか特定します。特定できたら、該当 GPO に Administrators を戻し、影響 DC で gpupdate /force を実行したうえで DFSR サービスを再起動します。

gpresult /h secpol.htm

セキュリティ強化のつもりで権利を絞った直後に SYSVOL 共有が出なくなったなら、このパターンを優先して疑ってください。症状が「昇格後すぐ」でも、原因は DFSR の権限不足ということがあります。 (Microsoft Learn)

旧環境のまま FRS を引きずっている、または移行状態が不整合

旧 DC からの移行中なら、SYSVOL 欠落より前に「複製方式が古い」可能性もあります。Windows Server 1709 以降の DC は、SYSVOL を FRS で複製しているドメインには追加できません。新旧混在や in-place upgrade 後で怪しいなら、dfsrmig /getglobalstate と dfsrmig /getmigrationstate を確認し、全 DC が同じ移行状態に達しているかを見ます。なお、DFSR への移行は一方向で、Eliminated まで進むとロールバックできません。 (Microsoft Learn)

また、古い Windows Server 2008 R2 がまだ残る環境では、Microsoft は DFSR 更新の適用も推奨しています。古い DC を残したまま「新しい DC だけ直す」方針は、長期的には再発しやすいです。 (Microsoft Learn)

復旧は「1台だけ壊れている」のか「全体がおかしい」のかで分ける

ここで重要なのは、D2/D4 相当の復旧を最初の一手にしないことです。Microsoft も、共有欠落で直ちに DFSR を再初期化するのは通常不要で、誤るとデータ損失の可能性があるとしています。まず上流DCとイベント ID の切り分けを済ませてから選んでください。 (Microsoft Learn)

健全なDCがあり、新DC 1台だけ壊れているなら「非権威」で戻す

Microsoft の考え方は明快で、1台だけ修理するなら、その DC を非権威で戻し、他のサーバーには触れないです。 (Microsoft Learn)

1. 影響 DC の SYSVOL をバックアップします。必要なら健全側の SYSVOL も退避します。初期同期をやり直すと、差分が PreExisting や Conflict and Deleted に退避されることがあります。 (Microsoft Learn)
2. ADSIEdit で次の DN を開き、影響 DC の msDFSR-Enabled を FALSE にします。 (Microsoft Learn) CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<server>,OU=Domain Controllers,DC=<domain>
3. AD レプリケーションを流したあと、影響 DC で DFSRDIAG POLLAD を実行します。DFSR ログに 4114 が出れば、SYSVOL 複製メンバーシップがいったん外れています。 (Microsoft Learn)
4. 同じ属性 msDFSR-Enabled を TRUE に戻し、再度 AD レプリケーションを流して DFSRDIAG POLLAD を実行します。4614 → 4604 の順に出れば、非権威同期で初期化が完了です。 (Microsoft Learn)
5. 必要なら PreExisting や Conflict and Deleted を見て、最新の GPO ファイルやスクリプトを戻します。 (Microsoft Learn)

全体がおかしい、または正本を決め直すなら「権威」で戻す

権威同期は、全 DC で SYSVOL が壊れている、あるいは この DC の SYSVOL を正本として配り直したいときだけ使います。Microsoft は、権威にするなら通常は PDC Emulator を推奨しています。SYSVOL の内容が最も新しい可能性が高いからです。 (Microsoft Learn)

1. すべての DC で DFSR サービスを停止し、起動種類を一時的に Manual にします。 (Microsoft Learn)
2. 権威にする DC の次の DN で、msDFSR-Enabled=FALSE、msDFSR-options=1 を設定します。 (Microsoft Learn) CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<authoritative-server>,OU=Domain Controllers,DC=<domain>
3. それ以外のすべての DC では、同じ DN 配下の msDFSR-Enabled=FALSE にします。 (Microsoft Learn)
4. AD レプリケーションを強制し、全 DC に反映されたことを確認します。 (Microsoft Learn)
5. 権威 DC だけ DFSR を起動します。まず 4114 が出ます。次にその DC の msDFSR-Enabled=TRUE に戻し、再度 AD レプリケーション後に DFSRDIAG POLLAD を実行します。4602 が出れば、その DC が権威メンバーとして初期化されています。 (Microsoft Learn)
6. その後、他の DC で DFSR を起動し、各 DC の msDFSR-Enabled=TRUE に戻して DFSRDIAG POLLAD を実行します。最後に起動種類を元へ戻します。 (Microsoft Learn)

この手順は強力ですが、間違った DC を権威にすると誤った GPO を全体へ配ってしまうので、必ずバックアップを取ってから実施してください。 (Microsoft Learn)

やってはいけない対処

もっとも危ない回避策は、SysVolReady を 1 にして見かけ上だけ共有を出すことです。Microsoft はこの問題で SYSVOLREADY=1 や SYSVOL/NETLOGON の手動共有を回避策にしないよう明記しています。しかも dcdiag の SysVolCheck は、そもそも SysVolReady=1 を読むテストなので、ここだけ通る状態は簡単に作れてしまいます。 SysVolCheck だけで「直った」と判断しないのが大事です。 (Microsoft Learn)

同じく、DFSR データベースの削除を最初にやるのも避けてください。Microsoft は通常不要で、削除するとローカルデータが非権威扱いになり、原因調査も難しくなるとしています。DB 削除は「最後の手段」であって、昇格直後の SYSVOL 欠落で真っ先に選ぶ手ではありません。 (Microsoft Learn)

再発を防ぐポイント

復旧後は、新DCだけでなく全 DC の DFSR ログと複製状態を見てください。Microsoft も、イベントログの定期確認と、WMI クエリによる複製状態の収集を継続監視として勧めています。SYSVOL 欠落は、1台の故障ではなく、レプリケーション経路全体の異常として再発することがあるからです。 (Microsoft Learn)

再起動のたびに 2213 や 2212/2214 が繰り返し出るなら、unexpected shutdown、ESENT 回復、ディスク性能低下、ドライバーやストレージ側の問題も見直してください。Microsoft は、DFSR がきれいに停止できず dirty shutdown 判定になる場合に備えて、必要に応じて WaitToKillServiceTimeout の調整も案内しています。 (Microsoft Learn)

Defender を使っている環境では、Windows Server 2016 以降は AD DS、SYSVOL、DFSR まわりの自動除外が入ります。ただし、自動除外を無効にしている、または SYSVOL/NTDS をカスタムパスへ移しているなら、手動除外が必要です。性能や安定性の切り分けが必要なときは、ここも確認してください。 (Microsoft Learn)

迷ったら、この順番で動く

1. まず dcdiag、repadmin、DFSR ログで、4612/4614、2213、4012、6016/8028 のどれに当たるかを特定します。 (Microsoft Learn)
2. 4612/4614 で 4604 が無いなら、初期同期待ちです。新DCではなく、ソースDCへの到達性と AD レプリケーションを直します。 (Microsoft Learn)
3. 既存DCに 2213 や 4012 があるなら、必ず既存DC側を先に復旧します。新DCはそのあとです。 (Microsoft Learn)
4. 6016/8028 で Access is denied. なら、権限と GPO を疑い、Manage Auditing and Security Log に Administrators が入っているか確認します。 (Microsoft Learn)
5. 健全な DC があり新DC 1台だけ壊れているなら非権威、全体が壊れているなら権威 + 他を非権威で戻します。権威にする DC は通常 PDC Emulator を選びます。 (Microsoft Learn)

ここまで整理して進めれば、「とりあえず SysVolReady=1」のような危ない近道を避けつつ、最短で正しい復旧ルートに入れます。次にやるべきことは、新DC単体ではなく全DCの DFSR と AD レプリケーションを確認し、イベント ID で分岐することです。そこが合えば、復旧はかなりの確率で迷いません。 (Microsoft Learn)