Windows Server 2016で発生するgpupdateエラーとSYSVOL複製トラブル解消の方法

社内ネットワークを安定運用しているつもりでも、ふとしたタイミングで「gpupdate」のエラーやSYSVOLフォルダー複製の問題が起きると、とても厄介に感じてしまいますよね。今回は、Windows Server 2016へドメインコントローラーをアップグレードした後に発生しやすい、SYSVOLレプリケーションとグループポリシーのトラブル解決策についてご紹介します。

gpupdateエラーとSYSVOL複製の問題とは

アップグレード直後は正常に複製が行われていたにもかかわらず、しばらくして追加ドメインコントローラー(セカンダリDC)で「gpupdate /force」などを実行するとエラーが表示され、イベントビューアーには「Group Policyの処理に失敗」や「\sysvol…\gpt.ini が読み込めない」「SYSVOLやNetlogonが見つからない」といったメッセージが残るケースがあります。これらは、SYSVOLフォルダーが複製されていない、もしくは複製方式の不整合などに起因することが多いです。

事象の背景

  • メインのドメインコントローラー(DC)をWindows Server 2008 R2からWindows Server 2016にアップグレード
  • サブのドメインコントローラーを構築し、最初は問題なくレプリケーションができていた
  • ある時点から追加DCで「gpupdate」がエラーを返しはじめる
  • SYSVOL共有が表示されない、またはIP指定で共有にアクセスすると資格情報が求められる

結果的に、ポリシーフォルダー(gpt.ini等)が複製されず、グループポリシーの設定が適用されない、という困った状況に陥ります。

問題が起きる代表的な要因

  1. DFS Replication(DFSR)とFile Replication Service(FRS)の移行や設定が中途半端な状態
  2. ドメインコントローラー間の時刻同期不備やDNS設定不備
  3. レジストリに誤った設定が残存している
  4. サブDCが非権威的な状態で同期できず、SYSVOL内ファイルが欠落した

Active Directoryレプリケーション状態の確認

最初のステップとして、やはりレプリケーション状況を客観的に把握することが重要です。メインドメインコントローラー(PDCエミュレーター保持DC)など、最も信頼できるDC上で次のコマンドを実行しましょう。

repadmin /showrepl > C:\rep1.txt
repadmin /replsum > C:\rep2.txt
repadmin /showrepl * /csv > C:\repsum.csv

これらのコマンドによって、ドメインコントローラー間の複製状況がテキストまたはCSV形式で得られます。大まかな流れは以下のとおりです。

コマンド意味
repadmin /showreplこのドメインコントローラーが認識しているレプリケーション状態を詳細表示します。
repadmin /replsum全ドメインコントローラーのレプリケーション状況の概要(成功/失敗など)を一覧表示します。
repadmin /showrepl * /csv複数のドメインコントローラーからの結果をCSV形式で出力できるため、エラーや遅延がないかをまとめて確認可能です。

もし、ここで明らかなエラーや再試行、失敗などが確認できた場合は、DNSやネットワーク、時刻同期に問題がないかを重点的にチェックしましょう。またドメインコントローラー各サーバーのイベントビューアーやサービス状態、ファイアウォールの設定が原因になることもあるため、併せて見直すとトラブルシューティングがスムーズに進みます。

SYSVOLのレプリケーション方式をチェック

Windows Server 2008以降は推奨設定としてDFSRが採用されていますが、以前の環境設定やアップグレード手順によってはFRSを使い続けている可能性もあります。現在、実際にどちらの方式でSYSVOLを同期しているかを把握することが問題解決の近道です。

DFSRかFRSかを判別する方法

以下のレジストリを確認します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState
  • LocalStateキーが存在し、値が「3 (ELIMINATED)」となっている場合は、DFSRへの移行が完了していると判断できます。
  • キー自体が見当たらない、または数字が異なる場合はFRSを使用しているか、DFSRへの移行が正常に完了していないことが考えられます。

もしFRSが使われている環境なら、近い将来サポートが終了するリスクや機能的な制限も多いため、この機会にDFSRへの移行を検討するのもおすすめです。

DFSR利用時の非権威的再同期(Non-authoritative Synchronization)

SYSVOLの中にあるGroup Policy関連フォルダー(gpt.iniなど)がサブDCで欠落している、または消えてしまったときに有効なのが「非権威的再同期」です。FRSの世界ではD2操作などと呼ばれましたが、DFSRでも類似の手順があります。

非権威的再同期の概要

  1. 問題が起きているドメインコントローラー(追加DCなど)のDFSRサービスを停止する。
  2. レジストリの設定を変更し、SYSVOLの状態を「非権威的な受け手」として再度同期させるモードにする。
  3. DFSRサービスを再起動すると、正常なドメインコントローラーからSYSVOLの内容(ポリシーフォルダー等)が再複製される。

この操作により、欠落しているファイルやフォルダーが上位(権威的)のDCから再配置されるため、サブDC上のSYSVOLが正しい構成に戻ります。ただし、この手順はレジストリエディタを使うため手動作業が発生し、またミスをすると大きな影響が出る可能性があります。必ず事前にSYSVOLフォルダーのバックアップを取るなど、慎重に行いましょう。

具体的な実施例

非権威的同期を実施する際には、Microsoftの公式ドキュメントが最も信頼できるガイドとなります。概略は以下のとおりです。

  1. バックアップを取得: SYSVOL、Netlogon、さらにActive Directory全体のバックアップを取る。
  2. DFSRサービスの停止:
   net stop dfsr
  1. レジストリ設定変更:
  • パス例:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Domain System Volume\SYSVOL Share
  • Replica Set FlagsSysvolRebuiltContent などの値を変更して非権威的同期をトリガーする設定にする。
  1. DFSRサービスの再起動:
   net start dfsr
  1. イベントビューアーでDFSRが同期を再開し、完了することを確認する。
  2. 非権威的再同期後、サブDCのSYSVOL内にポリシーフォルダーが正しく復元されているかをチェックする。

手順の詳細は環境ごとに異なるため、必ずMicrosoft公式のガイドやサポート情報を参考にしてください。

IPアドレス指定時に資格情報を求められる原因

追加ドメインコントローラーからメインADのSYSVOL共有(例: \\192.168.1.1\sysvol)を開く際に、ドメインに所属しているにもかかわらず資格情報を再度求められるケースがあります。これは、Windowsのセキュリティ機構が「IPアドレスによるアクセス」を別のフォレストや外部リソースからのアクセスとみなしているために起こりやすい事象です。

ドメイン名によるアクセスを推奨

  • 推奨アクセス方法: \\ドメイン名\sysvol
  • NetBIOS名でもDNS名でも、ドメインに関連付いた名前でアクセスすれば、ドメイン資格情報が自動的に適用され、余計なパスワード入力が不要になるケースがほとんどです。

もしドメイン名でアクセスしても依然として資格情報の入力を求められるなら、以下の可能性を疑ってみましょう:

  1. DNS設定: 追加DCが使用するプライマリDNSが正しいか、フォワーダー設定は正常か。
  2. 時刻同期: Kerberos認証が前提とする時刻のズレが大きすぎないか。
  3. グループポリシー: 共有アクセスを制限する設定が適用されていないか。
  4. ファイアウォール設定: DC間やクライアント間の通信がブロックされていないか。

トラブルを回避するためのポイント

実際に運用する中で、SYSVOLおよびグループポリシー関連のトラブルを最小化するにはどうしたらよいのでしょうか。いくつかのポイントを整理します。

1. レプリケーションモニタリングの習慣化

レプリケーションは常に動いているため、一度正常になったからといって放置してしまうと、知らないうちにエラーが蓄積している場合があります。定期的にrepadmin /replsumを確認したり、監視システムやイベントビューアーへのアラート設定を行うとよいでしょう。

2. 時刻同期の徹底

Active DirectoryはKerberos認証に依存するため、時刻が数分以上ずれていると認証失敗やレプリケーションエラーが発生しやすくなります。PDCエミュレーターは外部の正確な時刻源(例: NTPサーバー)と同期させ、他のDCやクライアントPCはPDCエミュレーターと同期する形を徹底してください。

3. DNSとNetlogonの健全性確認

DFS ReplicationやFRSによるSYSVOL同期には、正しいDNS解決とNetlogonサービスが密接に絡みます。特に追加ドメインコントローラーをセットアップした直後は、Netlogonの再登録やDNSレコードの更新に時間がかかることもあるため、dcdiag /test:DNSなどを使って問題がないかを早めに把握しましょう。

4. DFSR移行の完了確認

FRSからDFSRへ移行中の場合、実は「Migration State」が中途半端になっているケースが散見されます。dfsrmigコマンドを使い、移行ステージがELIMINATEDまできちんと到達しているかを定期的にチェックしましょう。

例:

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

ここで表示されるステートがPreparedRedirectedのままで止まっていたら、トラブルの原因になりやすいので要注意です。

まとめ

Windows Server 2016へのアップグレード後、追加ドメインコントローラーで「gpupdateエラー」と「SYSVOLが見つからない」などの問題は、レプリケーション(DFSR/FRS)の不備や時刻同期のズレが主な原因になることが多いです。まずはrepadminによる複製状態の確認とDNS・時刻の整合性をチェックし、問題がある場合には非権威的再同期の手順を慎重に実施してください。

また、SYSVOL共有には\\IPアドレス\sysvolではなく、\\ドメイン名\sysvolでアクセスするのが基本です。IP指定でアクセスすると資格情報の再入力が必要になり、トラブルシューティングを複雑にしてしまう場合があります。

いずれにしても、Active Directory環境の健全性を維持するには、定期的な検証と監視が不可欠です。小さなエラーを放置すると、後々大きな障害を引き起こすリスクがあります。ぜひ今回の手順やポイントを参考にして、快適なAD運用を実現してください。

コメント

コメントする