ドメイン参加クライアントとメンバーサーバーのグループポリシーは、起動・サインイン時の前景処理に加え、既定では90分間隔に最大30分のランダムなずれを加えてバックグラウンド更新されます。したがって「何秒ごと」ではなく、おおむね90〜120分の範囲です。ドメインコントローラーは既定で5分ごとにコンピューターポリシーの変更を確認します。ただし、GPOのAD部分とSYSVOL部分の複製、クライアントが参照したDC、同期/非同期処理、クライアント側拡張機能（CSE）によって実際の反映時点は変わります。通常は待機またはgpupdateで確認し、周期を極端に短縮したり全端末で/forceを繰り返したりしません。
待つ・更新する・適用を確認する：目的別のコマンド
| 確認したいこと | 使うコマンド・操作 | 結果の読み方 |
|---|---|---|
| 通常の変更を対象端末で取り込む | gpupdate | ユーザーとコンピューターの両方を更新。既定は変更された設定の処理です。 |
| ユーザー設定だけを更新する | gpupdate /target:user | コンピューター設定の更新とは分けます。コンピューター側だけなら /target:computer です。 |
| 変更のない設定も再適用する必要がある | gpupdate /force | 全設定を再処理。フォルダーリダイレクトなどは次のサインインが必要な場合があります。 |
| 現在のユーザーに適用されたGPOを調べる | gpresult /scope:user /r | RSoPの概要を確認。コマンドの更新成功表示だけで、アプリの動作まで確認済みにはしません。 |
| コンピューター設定を含む結果を共有する | 管理者のコマンドプロンプトで gpresult /h gp.html | 現在の作業フォルダーへHTMLを保存します。書き込み可能な場所で実行し、既存ファイル名と重ならない名前を選びます。 |
更新コマンドは対象端末で実行します。通常更新後、RSoPで目的のGPOを確認し、その設定が再起動・サインインを要するかを確認してから業務動作を試します。コマンドの意味は gpupdate と gpresult の公式資料に沿っています。
gpupdate の既定待機時間は600秒です。/wait:0 で直ちにプロンプトへ戻っても更新処理は続きます。「コマンドが返った時刻」を適用完了時刻として記録しないでください。周期、実行結果、実際の反映は分けて確認します。
更新の種類を前景と背景に分ける
コンピューター設定はWindows起動時、ユーザー設定はサインイン時に前景処理されます。前景処理は同期または非同期です。同期なら処理完了まで起動やサインインが待機し、非同期ならデスクトップが先に利用可能になる場合があります。その後の定期更新はバックグラウンドで非同期に行われます。画面が出た時点を、すべての設定が反映済みという証拠にはできません。
「GPOを編集した時刻」「対象端末が参照可能になった時刻」「端末が取得した時刻」「CSEが設定を適用した時刻」を分けて記録します。起動直後にネットワークやDCへ到達できない端末、Wi-Fi認証後に接続する端末、VPN経由の在宅端末では前景処理の条件が異なります。端末、ユーザー、接続ネットワーク、参照DC、検証時刻をそろえて比較します。
既定値はクライアント90分＋0〜30分、DCは5分
Microsoftの現行処理資料では、クライアントとサーバーのバックグラウンド更新は既定90分で、最大30分のランダムオフセットが加わります。同時刻に多数端末がDCへ集中するのを避ける仕組みなので、各端末が同じ分に更新するわけではありません。最短90分、最長およそ120分という見方はできますが、スリープ、電源断、ネットワーク断、処理時間を含む保証時刻ではありません。
ドメインコントローラーはコンピューターポリシーの変更を既定5分ごとに確認します。DCの値を一般クライアントへ当てはめません。管理用テンプレートにはユーザー、コンピューター、DCの更新間隔を変更する設定がありますが、Microsoftは短縮によるネットワークトラフィックとDC負荷の増加を理由に推奨していません。緊急変更は通常周期の恒久短縮ではなく、対象を限定した更新で扱います。
周期を0分に設定しない
更新間隔の設定値0は「無効」や「即時一回」ではありません。公式資料では更新レートが約7秒になります。全端末へ誤って配れば、LDAP、SMB/SYSVOL、DNS、認証、DC、WANへ継続的な負荷を与え、障害時の診断ログも増やします。短縮を検討する前に、どの設定を何分以内に届ける必要があるか、対象台数、サイト間回線、DC余力を数値化します。
一時的な短縮GPOも、元へ戻す前に対象へ適用できなければ短周期が残ります。検証OU、少数端末、監視、終了時刻、明示的ロールバックを用意しても、通常は既定値の維持が安全です。セキュリティ事故の封じ込めはGPO更新だけに依存せず、アカウント無効化、ネットワーク隔離、EDRなど目的に合う即時手段をインシデント手順で選びます。
GPOが参照DCへ複製される時間を考える
GPOはActive Directory内のGroup Policy Containerと、SYSVOL内のGroup Policy Templateという二つの部分を持ちます。AD部分はADレプリケーション、SYSVOL部分はDFSRで別々に複製されます。編集したDCでは新しい内容でも、対象端末が別DCを参照すると、複製完了前は旧内容を取得する場合があります。GPMCの編集完了を全拠点への配布完了とみなしません。
公式処理資料では同一サイトのAD複製は通常1分未満のことが多い一方、SYSVOLのサイト内複製やサイト間処理はトポロジ、スケジュール、回線へ依存します。問題時は端末のecho %LOGONSERVER%、DNS、時刻、DC到達性と、AD/SYSVOLの複製正常性を確認します。単一GPOのために全DCへ強制複製を常用せず、異常ならAD担当が根本原因を診断します。
変更がないCSEは通常再適用を省略する
バックグラウンド更新が走っても、すべての値を毎回書き直すわけではありません。Microsoftは、既定ではクライアント側拡張機能がGPOまたは適用GPO一覧の変更を検出したときだけ設定を再適用すると説明しています。ユーザーが設定を変えた場合に必ず90〜120分で元へ戻るとは限らず、各ポリシーの「変更がなくても処理する」設定やCSE固有動作を確認します。
Group Policy PreferencesにはReplace、Update、Create、Delete、Apply once and do not reapply、項目レベルターゲティングなど独自の処理があります。ポリシーと基本設定を同じものとして扱わず、該当CSE、アクション、適用一回、エラー時停止をGPMCで確認します。意図した値を維持したいだけで、毎回Replaceや強制処理を選ぶとファイル、レジストリ、ネットワークへ不要な負荷が生じます。
背景更新だけでは完了しない設定を把握する
すべての拡張機能がバックグラウンドで完了するわけではありません。フォルダーリダイレクトはユーザーのサインイン、コンピューター対象のソフトウェアインストールは起動、ユーザー対象のソフトウェアインストールはサインインが必要です。スクリプト拡張が背景更新で処理されても、個々のスタートアップ、シャットダウン、ログオン、ログオフスクリプトは対応するイベント時に実行されます。
そのためgpupdate /forceが成功しても、ソフトウェアが即時インストールされたりフォルダーが即時移動したりする保証はありません。gpupdate /bootは起動処理を要するコンピューターCSEがある場合、/logoffはサインイン処理を要するユーザーCSEがある場合に使います。利用者へ保存を案内し、無断の再起動やサインアウトを行いません。
gpupdateは通常更新から始める
gpupdateはローカル端末のユーザーとコンピューターのポリシー更新を開始します。既定では変更された設定だけを処理し、/target:userまたは/target:computerで対象を絞れます。/waitはコマンドが処理完了を待つ秒数で、0は待たず、-1は無期限です。コマンドが戻ったことと、すべてのCSEが業務動作を完了したことを区別します。
gpupdate /forceは変更の有無にかかわらず全設定を再適用します。通常更新で足りる場面に常用せず、再現試験やMicrosoft手順で必要なときだけ限定します。/syncは次回の前景処理を同期化し、指定時は/forceと/waitが無視されます。オプションを意味なく併記せず、出力にサインアウト/再起動要求があれば影響を説明して保守時間に実施します。
大量端末の更新は対象と時刻を分散する
GPMCのOU向けGroup Policy UpdateやInvoke-GPUpdateは遠隔端末へ更新を要求できますが、OU配下の全端末へ無計画に実行しません。オンライン端末数、ファイアウォール、タスクスケジューラ、権限、サイト間回線、業務ピークを確認し、パイロット、部門、拠点の小さな波で進めます。オフライン端末は失敗扱いで大量再試行せず、次回接続時の通常処理を設計します。
変更自体も一つのGPOへ小さく分け、リンク先、セキュリティフィルター、WMIフィルター、Enforced、継承ブロックを変更前に記録します。Default Domain Policyへ実験設定を足しません。緊急配布でも、対象外OU、サーバー、VDI、キオスク、低速拠点を識別し、DCとネットワークのCPU、LDAP、SMB、待ち時間、エラーを監視しながら拡大します。
gpresultで適用結果を先に確認する
gpresult /rは現在のユーザー/コンピューターのRSoP概要を表示します。詳細を共有しやすくするなら、あらかじめ存在と書き込み権限を確認した保存先へgpresult /h C:\Temp\gpresult.htmlを出力します。ARM64版Windowsで/hを使う場合は、公式資料の注意に従ってSysWow64側のgpresultを使用します。適用GPOだけでなく、拒否されたGPOと理由、セキュリティグループ、ユーザー/端末のOUを確認します。HTMLには内部構成が含まれるため外部へ無加工で送信しません。
結果がないときにすぐ/forceを連打せず、GPOリンクが正しいか、ユーザー設定をコンピューターOUだけへリンクしていないか、ループバックが必要な設計か、Security FilteringでReadとApplyが許可されているか、WMIフィルターがTrueかを確認します。GPMCのGroup Policy Results/Modelingも使い、期待値ではなく実際の適用集合と優先順位を調べます。
イベントログをActivityID単位で追う
イベントビューアーのSystemログでGroup Policy警告/エラーを開き、詳細のActivityIDを取得します。次にApplications and Services LogsのMicrosoft/Windows/GroupPolicy/Operationalで同じActivityIDを絞り、前処理、処理、後処理、開始と終了、警告とエラーを一組として確認します。エラー番号、失敗CSE、処理時間、参照DCを記録し、一行だけで原因を決めません。
Microsoftのトラブルシューティング資料は、gpupdateを再実行するとActivityIDが変わるため、最新IDでカスタムビューを更新するよう注意しています。再試行のたびに時刻とIDを記録します。名前解決、DC探索、認証、時刻ずれ、低速リンク、DFSR、CSE固有ログを順に切り分け、ログ削除や端末プロファイル初期化で証拠を失わないようにします。
変更とロールバックを同じ条件で測る
検証用端末で変更前のgpresult、適用値、イベント時刻、参照DCを保存し、GPOを編集して複製を待ち、通常のgpupdate、必要なら起動/サインイン、業務機能の順に確認します。「更新コマンド成功」「RSoPにGPOがある」「レジストリ等へ値がある」「アプリが期待動作」の四段階を分けます。対象設定が再起動不要かは個別ポリシー/CSE資料で判断します。
ロールバックはGPOバックアップまたは変更前値へ戻し、同じDC複製、通常更新、必要な前景処理、RSoP、業務動作を再確認します。GPOリンク削除や未構成化では別GPOやローカル値が表面化することがあるため、削除だけを復旧確認にしません。適用時間の実測分布、未反映理由、例外端末を記録し、既定周期を変える前に運用手順で解決できるか評価します。
確認チェックリスト
- クライアント90分＋最大30分、DC5分を区別した
- 起動/サインインの前景処理と背景更新を区別した
- GPOのAD部分とSYSVOL部分の複製を確認した
- 周期0分が約7秒になるため設定していない
- 背景処理しないCSEは起動/サインインを計画した
- 通常gpupdateから始め、/forceを常用していない
- gpresultで適用/拒否理由とRSoPを確認した
- ActivityID単位のイベントと業務動作を記録した
コメント