システムエンジニアXの「プログラミング以外」の話 50代会社員SEのお仕事・副業・システム運用の経験談
Windows トラブル

【GPOファイル配布】SYSVOLからは「置換」より「更新」で差分配信

公開:

※本記事には広告を含みます。

はじめに

グループポリシー基本設定（GPP）の「ファイル」機能を使って、ドメインコントローラーの SYSVOL 共有から全クライアント端末へ設定ファイルや業務ツールを配布する際、アクションを「置換（Replace）」にするか「更新（Update）」にするか迷ったことはないでしょうか。

私も過去に、数メガバイトある社内ツールのモジュールを「確実に最新化したいから」という理由で安易に「置換」で設定した結果、社内数千台のPCが90分ごとのGPO背景更新のたびに一斉にファイルを再ダウンロードし、拠点間WAN回線とドメインコントローラーのSMB帯域を逼迫させてしまった失敗経験があります。

「ファイルが更新されたときだけコピーしたい」と思っていても、GPPの「置換」と「更新」の内部挙動の違いを正確に理解していないと、不要なトラフィック発生や逆に「ファイルを差し替えたのにクライアント側が更新されない」といったトラブルを招きます。

この記事では、SYSVOLからファイルを配布する際のアクション種別の違いと、タイムスタンプを比較して差分コピーさせるための実践的な設定ルールを解説します。

読み終えるころには、帯域負荷を最小限に抑えつつ、確実に最新ファイルを端末へ届ける設計ができるようになります。

この記事の要点

  • 「置換（Replace）」 はファイルの変更有無にかかわらず、GPO更新周期（約90分）ごとに毎回ファイルを削除・再コピーするため大容量ファイルには不向き
  • 「更新（Update）」 はローカルにファイルが存在しない場合は新規作成し、存在する場合は属性や最終更新日時（タイムスタンプ）が変わったときのみ差分を反映する
  • ただし、クライアント側でユーザーがファイルを編集・上書きしてローカルのタイムスタンプが新しくなると、「更新」ではSYSVOL側から上書きされなくなる点に注意が必要
項目 動作確認・検証環境
検証年月 2026年9月
対象OS Windows Server 2022 / Windows 11 Pro 23H2・24H2
設定箇所 コンピューターの構成（またはユーザーの構成）＞ 基本設定 ＞ Windows の設定 ＞ ファイル
配布元パス例 \\<ドメイン名>\SYSVOL\<ドメイン名>\scripts\<ファイル名>

結論：SYSVOLからの通常配布は「更新（Update）」が基本

結論からお伝えすると、SYSVOLやファイルサーバーから定常的にファイルを配布する場合は、原則として 「更新（Update）」を選択するのがベストプラクティス です。

「更新」であれば、初回はファイルを作成し、2回目以降のGPO更新時には配布元（ソース）と配布先（ターゲット）を比較して、変更がある場合にのみファイルI/Oとネットワーク転送を行います。

1. GPP「ファイル」の4つのアクション比較表

GPPのファイル設定で選択できる4つのアクションの挙動とネットワーク負荷の違いは以下の通りです。

アクション 配布先にファイルがない場合 配布先に同名ファイルがある場合 90分ごとのGPO背景更新時の通信負荷 主な用途
作成 (Create) 新規コピーする 何もしない（スキップ） 極小（存在確認のみ） 初期テンプレート配布（後の変更を許容）
更新 (Update) 新規コピーする 差分・更新日時を比較して更新 小（変更時のみコピー） 定常的なモジュール・設定ファイル配布（推奨）
置換 (Replace) 新規コピーする 毎回削除して全量再コピー 大（毎回全量ダウンロード） 改ざんを絶対許さない極小の設定ファイル
削除 (Delete) 何もしない ファイルを削除する 極小 不要になったファイルの撤去

表の通り、グループポリシーのデフォルト選択値でもある「更新（Update）」が、機能性とネットワーク負荷のバランスに最も優れています。

2. 「置換（Replace）」が帯域を圧迫するメカニズム

「置換」を選択した場合、クライアントのGroup Policy Clientサービスは、バックグラウンド更新（既定で90分＋ランダム最大30分間隔）が走るたびに以下の処理を実行します。

  1. クライアントローカルの対象ファイルを一度削除（Delete）する
  2. \\<ドメイン名>\SYSVOL\... からファイルをSMB経由で全量ダウンロードして新規作成する

仮に10MBのファイルを1,000台のPCへ「置換」で配布すると、ファイルの中身が1バイトも変わっていなくても、約90分ごとに合計10GBの無駄なSMBトラフィックがドメインコントローラーに集中 します。

「更新（Update）」の動作仕様とハマりどころ

「更新」は非常に効率的ですが、どのような条件でファイルの中身を上書きするのか、その判定ロジックを知っておく必要があります。

1. タイムスタンプ（LastWriteTime）による差分判定

GPPの「更新」アクションは、配布元ファイルと配布先ファイルの 最終更新日時（LastWriteTime） および属性（読み取り専用・隠しファイル等）を比較します。

  • 配布元（SYSVOL）の最終更新日時 ＞ 配布先（PCローカル）の最終更新日時 → ファイルを上書きコピーする
  • 配布元と配布先の最終更新日時が同一 → ファイル本体のコピーはスキップし、属性のみ同期する

したがって、管理者がSYSVOL上のファイルを新しいバージョンのファイルで差し替えれば、タイムスタンプが新しくなるため、次回のGPO適用タイミングで全端末へ自動的に差分コピーされます。

2. ハマりどころ：古いタイムスタンプのファイルに戻す場合

障害切り分けなどで「SYSVOL上のファイルを、昨日バックアップしていた旧バージョンのファイルに戻した」というケースでは落とし穴があります。

旧バージョンのファイルは最終更新日時が古いため、クライアントローカルにあるファイルの方が「新しい」と判定され、「更新（Update）」アクションでは古いファイルへの巻き戻し（ダウングレード）が行われない ことがあります。

古いファイルへ強制的に戻したい場合は、以下のいずれかの対処が必要です。
- 戻したいファイルの最終更新日時を現在時刻に更新（タッチ）してからSYSVOLに配置する
- 一時的にGPPのアクションを「置換（Replace）」に変更して強制上書きさせる

3. SYSVOL上のファイルのタイムスタンプを現在時刻に更新するPowerShell

旧ファイルを配布し直す際や、確実に「更新」トリガーを発火させたい場合は、以下のPowerShellコマンドでSYSVOL上のファイルの更新日時を最新化できます。

# SYSVOL上の配布対象ファイルのパスを指定
$TargetFile = "\\corp.example.com\SYSVOL\corp.example.com\scripts\config.xml"

# 最終更新日時（LastWriteTime）を現在時刻に更新してGPP「更新」の対象にする
if (Test-Path -Path $TargetFile) {
    (Get-Item -Path $TargetFile).LastWriteTime = Get-Date
    Get-Item -Path $TargetFile | Select-Object Name, LastWriteTime
} else {
    Write-Warning "指定されたファイルが見つかりません: $TargetFile"
}

このコマンドを実行すると、ファイルの中身を変えずに LastWriteTime プロパティのみを現在日時に書き換えます。これにより、DFSR（DFSレプリケーション）で他ドメインコントローラーへ変更が同期され、クライアント側でも確実に「更新あり」と判定されます。

SYSVOLから安全にファイルを配布する推奨設定手順

帯域負荷を抑え、かつ認証トラブルを避けるための具体的なGPP設定手順を解説します。

1. パス指定と「コンピューターの構成」利用時の注意点

GPPのファイル設定は、以下のパスから作成します。

コンピューターの構成（またはユーザーの構成）
 └ 基本設定
    └ Windows の設定
       └ ファイル ＞ 新規 ＞ ファイル

ここで設定する各項目の推奨値は以下の通りです。

  1. 操作（Action）: 更新
  2. 元のファイル（Source file(s)）: \\<ドメイン名>\SYSVOL\<ドメイン名>\scripts\<ファイル名>（必ずFQDNのUNCパスで指定する）
  3. 目的のファイル（Destination File）: C:\Tools\<ファイル名> など、ローカルのフルパスを指定する
  4. 属性: ユーザーに書き換えられたくない場合は 読み取り専用 にチェックを入れる

なお、「コンピューターの構成」でファイルを配布する場合、通信はログインユーザーではなくPC自身のアカウント（SYSTEM ＝ AD上の Domain Computers）で行われます。一般的なファイルサーバーを配布元にするとコンピュータアカウントの読み取り権限不足（エラー 0x80070005）で失敗しやすいため、Authenticated Users に読み取り権限が標準付与されている SYSVOL または NETLOGON 配下に置くのが最も確実です。

2. 「1回限り適用する」を組み合わせる判断基準

「更新」アクションであっても、将来にわたって更新する予定がない初期キッティング用ファイルであれば、「共通」タブの 「1回限り適用する、再適用しない（Apply once and do not reapply）」 にチェックを入れることで、2回目以降の存在確認処理すら完全にスキップできます。

ただし、「1回限り適用する」をオンにすると、後日SYSVOL側のファイルを更新してもクライアント側には二度と反映されなくなるため、定期更新するファイルには絶対に使用しないでください。

よくある質問（FAQ）

Q: 「適用できなくなった場合はこの項目を削除する」と「更新」は併用できますか？

A: 併用できません。「共通」タブで「適用できなくなった場合はこの項目を削除する」にチェックを入れると、GPPの仕様によりアクションが強制的に「置換（Replace）」へと変更されます。差分コピー（「更新」）を優先する場合は、このオプションはオフのまま運用してください。

Q: SYSVOLに数100MBのインストーラー（.msi / .exe）を置いてGPPで配っても大丈夫ですか？

A: 非推奨です。SYSVOLはドメインコントローラー間でDFSRによって常に同期される領域であり、大容量ファイルを配置するとSYSVOL肥大化やADレプリケーション遅延の原因になります。数十MB〜数百MBを超えるインストーラーは専用の中継ファイルサーバー（DFS名前空間等）に配置し、Domain Computers に読み取り権限を付与して「更新」または「1回限り適用」で配布してください。

Q: 配布先フォルダが端末に存在しない場合、フォルダも自動作成されますか？

A: はい、自動作成されます。「目的のファイル」に C:\CompanyTools\SubFolder\app.ini のように存在しない階層を指定した場合でも、GPPが親フォルダを自動的に作成した上でファイルを配置します。

まとめ

GPPでSYSVOLからファイルを配布する際の設計ポイントは以下の通りです。

  • 90分ごとの全量再ダウンロードを防ぐため、アクションは原則 「更新（Update）」 を選択する
  • 「更新」は配布元ファイルの 最終更新日時（タイムスタンプ） が新しい場合にファイルを上書きコピーする
  • ユーザーがローカルで書き換えてしまうのを防ぐため、必要に応じて 「読み取り専用」属性 を付与する
  • 「コンピューターの構成」で配る場合は、コンピュータアカウントのアクセス権トラブルが起きないよう \\<ドメインFQDN>\SYSVOL\... のパスを指定する

「置換」と「更新」の特性を正しく使い分けることで、ネットワーク帯域を守りながら安定したファイル配信基盤を構築できます。

関連記事

免責規定

この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。

OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。 また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。

この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。 すべての操作は自己責任で行ってください。

最後までお読みいただきありがとうございました。
またお会いしましょう！
← 記事一覧に戻る