Active Directoryを管理していると、SYSVOLという名前を目にすることがあります。
普段は意識することが少ないフォルダーですが、SYSVOLはグループポリシー(GPO)やログオンスクリプトなどをドメインコントローラー間で共有するための重要な領域です。
SYSVOLのレプリケーションに問題が起きると、グループポリシーが正常に適用されない、新しく追加したドメインコントローラーでSYSVOL/NETLOGON共有が作成されない、といったトラブルにつながることがあります。
この記事ではSYSVOLの役割と、障害が疑われるときに確認したいポイントを解説します。

- SYSVOLとは?
- SYSVOLはどこにある?
- SYSVOLとNETLOGONの違い
- グループポリシーとSYSVOLの関係
- 現在のWindows ServerではDFSRでSYSVOLを複製する
- SYSVOLが正常かnet shareで確認する
- dcdiagでSYSVOLを確認する
- NETLOGON共有もdcdiagで確認する
- Active Directoryレプリケーションも確認する
- DFS Replicationイベントログを確認する
- 新しいDCでSYSVOL・NETLOGONが共有されない場合
- DNSの問題も確認する
- SYSVOLフォルダーを直接コピーして直してもいい?
- SYSVOL障害を調査するときの確認順序
- まとめ
- 参考情報
SYSVOLとは?
SYSVOL(System Volume)は、Active Directoryのドメインコントローラーが持つ特別な共有領域です。
Microsoftによると、SYSVOLにはドメイン全体で複製する必要があるファイルが保存されます。
代表的なものは次のとおりです。
- グループポリシー(GPO)のファイル
- ログオンスクリプト
- ログオフスクリプト
- スタートアップスクリプト
- シャットダウンスクリプト
複数のドメインコントローラーが存在する場合、これらのファイルを各DCで利用できるようにSYSVOLがレプリケーションされます。
SYSVOLはどこにある?
標準的な構成では、SYSVOLはWindowsフォルダー配下にあります。
C:\Windows\SYSVOL
実際にクライアントや管理者がアクセスするときは、SYSVOL共有を経由します。
例えばドメイン名がexample.localなら、次のようにアクセスできます。
\\example.local\SYSVOL
ドメインコントローラー単位で確認する場合は、
\\DC01\SYSVOL
のようにアクセスできます。
SYSVOLとNETLOGONの違い
ドメインコントローラーでnet shareを実行すると、通常はSYSVOLとNETLOGONという共有が確認できます。
net share
SYSVOLはグループポリシーなどドメイン全体で必要なファイルを保持する共有領域です。
NETLOGON共有はSYSVOL内のスクリプト領域をクライアントから利用できるようにした共有です。
そのためSYSVOLの初期化やレプリケーションに問題があると、SYSVOLだけでなくNETLOGON共有にも問題が現れることがあります。
グループポリシーとSYSVOLの関係
グループポリシーオブジェクト(GPO)の情報は、すべてが1か所だけに保存されているわけではありません。
大きく分けると、Active Directory側に保存される情報とSYSVOL側に保存されるファイルがあります。
グループポリシー(GPO)
│
├─ Active Directory
│ └─ GPOのディレクトリ情報
│
└─ SYSVOL
└─ GPOのファイル
このためActive Directoryのレプリケーションだけが正常でも、SYSVOL側のレプリケーションに問題があれば、GPOが正常に利用できない可能性があります。
現在のWindows ServerではDFSRでSYSVOLを複製する
現在のWindows Server環境では、SYSVOLのレプリケーションにDFS Replication(DFSR)が使用されます。
以前のWindows ServerではFile Replication Service(FRS)が使用されていました。
Microsoftによると、現在のWindows ServerではDFSRがSYSVOLをDC間でレプリケーションする仕組みとして使用されています。
DC1
│
│ DFS Replication
↓
DC2
│
│ DFS Replication
↓
DC3
これによって各ドメインコントローラーが同じSYSVOLの内容を利用できます。
SYSVOLが正常かnet shareで確認する
まず簡単に確認できるのが共有状態です。
ドメインコントローラーで次のコマンドを実行します。
net share
正常なDCでは通常、一覧に次の共有が表示されます。
NETLOGON
SYSVOL
新しくDCへ昇格したサーバーでSYSVOLやNETLOGONが表示されない場合、SYSVOLの初期レプリケーションが完了していない可能性があります。
dcdiagでSYSVOLを確認する
ドメインコントローラーの診断にはdcdiagを利用できます。
SYSVOLの準備状態を確認するには次のテストがあります。
dcdiag /test:sysvolcheck
MicrosoftによるとSysVolCheckテストは、DCのSysVolReadyレジストリ値を確認してSYSVOLが準備済みかを検証します。
正常に準備されていれば値は1になります。
ただしSysVolCheckだけではSYSVOL共有へ実際にアクセスできるかまでは確認しません。
NETLOGON共有もdcdiagで確認する
SYSVOLとあわせてNETLOGONも確認します。
dcdiag /test:netlogons
MicrosoftのDCDiag資料ではNetLogonsテストにより、SYSVOL共有とNETLOGON共有へ接続して読み取れるかなどを検証します。
そのためSYSVOL障害を調査するときは、
dcdiag /test:sysvolcheck
dcdiag /test:netlogons
を組み合わせて確認すると分かりやすいでしょう。
Active Directoryレプリケーションも確認する
SYSVOLはDFSRで複製されますが、DFSRの構成情報はActive Directoryとも関係しています。
そのためSYSVOLだけを見るのではなく、ADレプリケーションが正常かも確認します。
repadmin /replsummary
さらに詳細を見る場合は、
repadmin /showrepl
などを利用します。
repadminの見方については、以下の記事でも解説しています。

DFS Replicationイベントログを確認する
SYSVOLレプリケーションの状態を調べる場合は、イベントビューアーのDFS Replicationログも重要です。
イベント ビューアー
↓
アプリケーションとサービス ログ
↓
DFS Replication
例えばMicrosoftのSYSVOLトラブルシューティングでは、次のイベントが重要な手掛かりとして紹介されています。
イベントID 4614
DFSRがSYSVOLの初期レプリケーションを待っている状態で記録されることがあります。
新しくDCへ昇格したサーバーで、4614は記録されているのに4604が記録されない場合、初期同期が完了していない可能性があります。
イベントID 4604
SYSVOLの初期同期が完了し、初期化されたことを確認する重要なイベントです。
Microsoftのトラブルシューティングでも、4614のあと4604が記録されることが初期同期完了の目安として使われています。
イベントID 2213
ダーティシャットダウン後などにDFSRがレプリケーションを停止している場合に確認されることがあります。
イベント2213がある場合は、イベントに記載された内容やMicrosoftの手順を確認してから対応します。
イベントID 4012
長期間レプリケーションできなかった場合など、コンテンツ鮮度保護によってレプリケーションが停止しているケースで確認されることがあります。
新しいDCでSYSVOL・NETLOGONが共有されない場合
新しくドメインコントローラーを追加したあと、
net share
を実行してもSYSVOLとNETLOGONが存在しないことがあります。
この場合、単純に共有フォルダーを手動作成するのではなく、まず初期レプリケーションの状態を確認します。
確認するポイントは、
- ADレプリケーションが正常か
- DFS Replicationサービスが動作しているか
- イベントID 4614が記録されていないか
- イベントID 4604まで到達しているか
- DNS設定に問題がないか
などです。
DNSの問題も確認する
Active DirectoryのレプリケーションではDNSも重要です。
ドメインコントローラーがDNSを使って相手のDCを正しく検索できない場合、ADレプリケーションや関連処理に影響する可能性があります。
Active DirectoryとDNSの関係については、以下の記事で詳しく解説しています。
▶ Active DirectoryでDNSが重要なのはなぜ?ドメイン参加・ログオン・レプリケーションとの関係を解説
SYSVOLフォルダーを直接コピーして直してもいい?
SYSVOLの内容が違っているからといって、障害原因を確認せずにDC間でフォルダーを単純コピーするのは避けた方がよいでしょう。
DFSRにはレプリケーション状態やデータベースがあり、障害内容によって適切な復旧方法が異なります。
MicrosoftにはDFSRで複製されるSYSVOLについて、権限のある同期(authoritative)・権限のない同期(non-authoritative)を行う復旧手順も用意されています。
ただし、この操作はSYSVOLの内容に直接影響するため、正常なDCと障害DCを特定し、バックアップを確保したうえでMicrosoftの手順に従って実施する必要があります。
SYSVOL障害を調査するときの確認順序
実際のトラブル調査では、次のような順序で確認すると切り分けしやすくなります。
net shareでSYSVOL/NETLOGONを確認dcdiag /test:sysvolcheckを実行dcdiag /test:netlogonsを実行repadmin /replsummaryでADレプリケーションを確認repadmin /showreplで詳細を確認- DFS Replicationイベントログを確認
- DNS設定・名前解決を確認
特に複数DC環境では、問題のDCだけでなく正常なDCと比較することが重要です。
まとめ
SYSVOLはActive Directory環境で、グループポリシーのファイルや各種スクリプトなどをドメインコントローラー間で共有する重要な領域です。
現在のWindows Serverでは、SYSVOLはDFS Replication(DFSR)によってDC間で複製されます。
SYSVOLに問題が疑われる場合は、
net share
dcdiag /test:sysvolcheck
dcdiag /test:netlogons
repadmin /replsummary
repadmin /showrepl
などを使い、さらにDFS Replicationイベントログを確認します。
「SYSVOLがないから共有を作る」とすぐ修正するのではなく、ADレプリケーション・DFSR・DNSを含めて、なぜSYSVOLが正常に初期化・複製されていないのかを確認することが重要です。



コメント