合同会社小村ソフト
相談する
メニュー

グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け

· · Windows, グループポリシー, Active Directory, Intune, PC管理, PowerShell, 情報システム

「この設定はGPOで配ってあります」「客先のPCはグループポリシーで縛られていて」── Windowsの業務システムに関わっていると、この「GPO」という言葉は日常的に飛び交います。ところが、いざ自分がAD環境の情シス業務を引き継いだり、客先のドメイン参加PCにアプリを導入したりする段になると、グループポリシーがいつ・どこから・どういう優先順位で適用されるのかを正確に説明できる人は意外に少ないものです。

「設定を変えたのに反映されない」「gpupdateを叩けと言われたが何が起きているのか分からない」「開発機では動くアプリが客先でだけ動かず、調べたらGPOだった」── 本記事は、こうした場面に直面する業務アプリ開発者と、AD環境を引き継いだ中小企業の情シス担当者を対象に、グループポリシーの仕組み(LSDOUの適用順序)、反映のタイミング、gpresultとイベントログでの切り分け、ADMXとセントラルストア、そしてIntune(MDM)との使い分けまでを、2026年8月時点の一次情報にもとづいて整理します。

1. まず結論

  • グループポリシーは「後勝ち」です。ローカル→サイト→ドメイン→OU(LSDOU)の順に処理され、後から処理されたGPOが競合時に優先します。ローカルGPO(gpedit.msc)は最も弱い層です。1
  • 反映のタイミングは「前景+背景」です。コンピューターの構成は起動時、ユーザーの構成はサインイン時に必ず適用され、加えて既定では約90分+0〜30分のランダムオフセットでバックグラウンド更新されます(ドメインコントローラーは5分)。2
  • gpupdate /force は「全設定の再適用」であって万能ではありません。ソフトウェアインストールやフォルダーリダイレクトのように、サインインや再起動でしか処理されない設定があります(/logoff・/bootオプションの存在理由です)。3
  • 切り分けの起点は gpresult /h のRSoPレポートです。適用されたGPOと拒否されたGPO(理由付き)が見えます。深掘りはGroupPolicy運用ログ(Microsoft-Windows-GroupPolicy/Operational)で行います。45
  • 管理用テンプレートのポリシーは、原則としてレジストリのポリシー専用キー(Software\Policies 等)に書かれます。ポリシー値はアプリ独自の設定より優先され、「未構成」は何も書きません。ただし専用キーの外へ書き込むポリシーも一部あります(5章)。6
  • ADMXのセントラルストアは SYSVOL の PolicyDefinitions フォルダーです。作成しておくとGPMCがドメイン共通のテンプレート定義を参照するようになります。7
  • GPOかIntuneかは端末のアイデンティティ基盤で決めます。同じ設定を両方で構成すると結果が保証されません。移行検討にはGroup Policy analyticsが使えます。89
  • 開発者にとってGPOは「客先でだけ動かない」の定番原因です。実行ポリシー、ファイアウォールのローカル規則マージ無効化、プロキシ・ドライブ構成など、アプリの前提を変える設定が集中管理で配布されています。1011

2. グループポリシーとは何か ── ローカルGPOとドメインGPO

グループポリシーは、Windowsの設定を管理者が集中定義し、対象のコンピューターとユーザーに強制的に適用する仕組みです。設定のかたまりをGPO(グループポリシーオブジェクト)と呼びます。GPOには2つの置き場所があります。

  ローカルGPO ドメインGPO
編集ツール gpedit.msc(ローカルグループポリシーエディター) GPMC(グループポリシー管理コンソール)+グループポリシー管理エディター
保存場所 そのPC自身。コンピューター向けは1つだが、ユーザー向けは「管理者/非管理者/特定ユーザー別」の複数ローカルGPO(MLGPO)も作れる12 Active Directory(サイト・ドメイン・OUにリンクして配布)
適用範囲 そのPCだけ リンク先の配下にあるコンピューター/ユーザー全体
優先順位 最も弱い(ドメインGPOに上書きされる)1 ローカルより強い。ドメインGPO同士はリンク先とリンク順で決まる
典型的な用途 ワークグループPC・検証機の単体設定 組織の標準設定の配布・強制

ワークグループ(ドメイン非参加)のPCが処理するのはローカルGPOだけです。1 つまり「GPOで管理されている」と言うとき、実務上はほぼドメインGPOを指しています。

どのGPOにも、中身は大きく2系統あります。

  • コンピューターの構成: そのPCにサインインする誰に対しても効く設定。起動時に適用されます。
  • ユーザーの構成: そのユーザーがどのPCにサインインしても効く設定。サインイン時に適用されます。

「PCに紐づく設定か、人に紐づく設定か」という軸は、このあとの適用順序でも反映確認でも一貫して登場します。同じ項目が両方の構成に存在する設定もあるので、設定を探すときは必ず両方の系統を見る癖をつけてください。

3. 適用の仕組み ── LSDOUの「後勝ち」と継承の制御

3.1. LSDOU: ローカル→サイト→ドメイン→OU

ドメイン参加PCでは、GPOは次の順序で処理されます。1

  1. ローカルGPO
  2. サイトにリンクされたGPO
  3. ドメインにリンクされたGPO
  4. OU(組織単位)にリンクされたGPO ── 上位のOUから順に処理され、最後に対象のコンピューター/ユーザーが直接所属するOUのGPOが処理される

頭文字を取ってLSDOUと呼ばれる順序です。重要なのは、これが「優先順位の高い順」ではなく処理される順であることです。同じ設定を複数のGPOが構成している場合、後から処理されたGPOが勝ちます(競合しない設定は単純に足し合わされます)。1 つまり、対象に一番近いOUのGPOが最強で、ローカルGPOが最弱です。「gpedit.mscで直したのに元に戻る」のは故障ではなく、この仕様どおりの動作です。

同じサイト・ドメイン・OUに複数のGPOがリンクされている場合は、GPMCの「リンクされたグループポリシーオブジェクト」タブのリンク順で決まります。リンク順の番号が最も小さいGPOが最後に処理され、最も優先されます。1

3.2. 継承のブロックと強制(Enforced)

既定の順序には例外を作れます。1

  • 継承のブロック: ドメインやOUに設定すると、上位からのGPOの継承を止められます。「このOUだけは全社標準を受けたくない」場合の道具です。
  • 強制(Enforced、旧称: 上書き禁止): GPOのリンクに設定すると、そのGPOは下位で継承ブロックされていても必ず適用され、下位のGPOに上書きされなくなります。継承ブロックと強制が衝突したときは強制が勝ちます。1

強制は「後勝ち」の原則を壊す仕組みなので、多用するとRSoPを読んでも直感に反する結果が増えます。全社で必ず守らせたいセキュリティ設定に限定するのが定石です。

3.3. セキュリティフィルター処理

リンクの場所だけでなく、誰に適用するかもGPO単位で絞れます。GPOが適用されるには、対象のユーザーまたはコンピューターがそのGPOに対して「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持っている必要があります。既定ではAuthenticated Users(ユーザーとコンピューターの両方を含む)に両方が許可されているため、リンク先の配下全員に適用されます。これを特定のセキュリティグループに絞るのがセキュリティフィルター処理です。フィルターはGPO全体に効くもので、GPO内の設定ごとに変えることはできません。13

ひとつ重要な注意があります。適用先を絞る際に、既定のAuthenticated Usersから「読み取り」まで外してはいけません。セキュリティ更新プログラムMS16-072(2016年)以降、ユーザー向けポリシーはコンピューターのセキュリティコンテキストで取得されるため、コンピューターアカウントがGPOを読めないと、対象ユーザーに両方の許可を与えていてもユーザー向けGPOが適用されなくなります。14 絞り込むときは、対象グループに「読み取り+グループポリシーの適用」を与えたうえで、Authenticated Users(またはDomain Computers)に「読み取り」だけを残すのが正しい形です。14

実務では「グループに入れたのに適用されない(コンピューター向け設定なのにユーザーだけグループに入れていた)」「グループから外したのに適用され続けている」が定番のつまずきです。後者はバックグラウンド更新を待っても解消しません。グループメンバーシップはサインイン時に作られたセキュリティトークンで評価されるため、ユーザーのグループ変更はサインアウト→サインイン、コンピューターのグループ変更は再起動で、新しいトークンになって初めてフィルターに反映されます。

なお、共有PCやリモートデスクトップサーバーのように「そのPCにサインインした人全員に、ユーザーの構成を差し替えたい」場面のために、ループバック処理という特殊モードもあります(コンピューターの場所にもとづいてユーザー設定を適用する仕組みで、置換とマージの2モードがあります)。15 キオスク端末や教室PCで使われる応用機能なので、本記事では存在の紹介にとどめます。

4. いつ反映されるか ── 前景処理とバックグラウンド更新

「設定したのに反映されない」の半分は、単にまだ適用タイミングが来ていないだけです。適用には2種類あります。2

種類 タイミング 対象
前景(フォアグラウンド)処理 コンピューターの構成: 起動時/ユーザーの構成: サインイン時 すべての設定
バックグラウンド更新 既定で約90分ごと+0〜30分のランダムオフセット(全端末が一斉に取りに来ないようずらされる) バックグラウンド処理に対応する設定のみ
バックグラウンド更新(ドメインコントローラー) 既定で5分ごと 同上

つまり、ドメインコントローラーに到達できる稼働中の端末であれば、GPOを変更してから何もしなくても、バックグラウンド更新に対応する設定は2時間程度で行き渡ります。オフラインの端末やVPN未接続の持ち出しPCには、次にDCへつながるまで届きません。前景処理でしか適用されない設定は、さらに起動やサインインを待つことになります。急ぐ場合は対象PCで gpupdate を実行します。既定では変更があった設定だけが適用され、/force を付けると変更の有無にかかわらず全設定を再適用します。3

rem 変更分のみ更新(通常はこれで十分)
gpupdate

rem 全設定を再適用(キャッシュ済みの状態を疑うとき)
gpupdate /force

注意すべきは、gpupdateでは反映されない設定があることです。ユーザー向けのソフトウェアインストールやフォルダーリダイレクトはサインイン時、コンピューター向けのソフトウェアインストールは起動時にしか処理されません。gpupdateにはこのための /logoff(更新後にサインアウト)と /boot(更新後に再起動)オプションが用意されています。3 「gpupdate /forceを実行したのに入らない」と騒ぐ前に、その設定が再起動・サインインを要する種類でないかを確認してください。

5. 反映されない時の切り分け ── gpresult・イベントログ・レジストリ

5.1. gpresult /h でRSoPを確認する

複数のGPOが重なり合った最終結果(RSoP: ポリシーの結果セット)を確認する標準ツールが gpresult です。管理者権限のコマンドプロンプトからHTMLレポートを出力するのが一番読みやすい方法です。45

rem ユーザー+コンピューター両方のRSoPをHTMLレポートに出力
gpresult /h C:\temp\gp-report.html /f

rem コンソールで概要だけ確認する場合
gpresult /r
gpresult /scope computer /r

レポートで最初に見るべきは次の3点です。

  1. 適用されたGPOの一覧 ── 目的のGPOが入っているか
  2. 拒否されたGPOの一覧と理由 ── セキュリティフィルターやWMIフィルター、空のGPOなど、適用されなかった理由が表示されます5
  3. 設定ごとの「優先するGPO」 ── 目的の設定がどのGPOの値で決まったか。別のGPOが勝っていれば3章の優先順位を見直します

5.2. GroupPolicy運用ログ

gpresultで足りないとき(そもそも処理が失敗している、時間がかかりすぎる等)は、イベントビューアーのGroupPolicy運用ログを見ます。場所は「アプリケーションとサービス ログ > Microsoft > Windows > GroupPolicy > Operational」(ログ名 Microsoft-Windows-GroupPolicy/Operational)です。ここには、ポリシー処理の開始から終了までが、適用されたGPOの一覧・拒否されたGPOの一覧(理由付き)とともに記録されます。ポリシー処理の1回ごとに一意のActivityIDが割り当てられるため、システムログの警告・エラーイベントからActivityIDを拾い、カスタムビューでその1回分だけを絞り込むのがMicrosoft推奨の手順です。5

5.3. レジストリのPoliciesキーとの関係

管理用テンプレート(次章)のポリシーは、最終的にはレジストリ値として書き込まれます。書き込み先は、原則として次のポリシー専用キーです。6

  • HKEY_LOCAL_MACHINE\Software\Policies(コンピューターの構成。推奨の場所)
  • HKEY_CURRENT_USER\Software\Policies(ユーザーの構成。推奨の場所)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

ここには重要な設計思想があります。ポリシー対応のアプリは、まずPoliciesキーを読み、あればその値を優先し、なければ自分の設定(プリファレンス)や既定値を使うという動きをします。「未構成」のポリシーはレジストリに何も書きません。6 つまり、管理用テンプレートのポリシーはアプリ自身の設定を書き換えて「刺青(tattooing)」を残すのではなく、別の場所に置かれた強制値が優先参照される仕組みです。ポリシーの構成をやめれば、アプリは自分の設定値に従う状態へ戻れます。

ただし、すべてのポリシーが専用キーに書くわけではありません。OS組み込みの設定の一部(たとえば「Win32の長いパスを有効にする」は HKLM\SYSTEM\CurrentControlSet\Control\FileSystem の LongPathsEnabled に書き込みます)や、古い世代・サードパーティ製のテンプレートには、専用キーの外の任意のパスへ書くものがあります。この種の設定は、ポリシーの構成をやめても値がそのまま残ります。目的の設定が実際にどのキーに書くかは、ADMXの定義や設定の説明文、gpresult のレポートで確認してください。

逆に言うと、前述の行儀の良さは管理用テンプレート(ポリシー専用キー)の枠内の話です。スクリプトやグループポリシー基本設定(Preferences)でPoliciesキーの外に書き込んだ値は普通のレジストリ値と同じで、配布をやめても自動で元に戻す仕組みはこの枠組みにはありません。切り分けの実務では、「目的の設定がPoliciesキーに書かれているか」を直接見るのが手っ取り早く、確実です。

# ポリシーで配布された値を直接確認する例(多くのポリシーは Policies 配下に書かれる)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

6. 管理用テンプレート(ADMX)とセントラルストア

GPMCの「管理用テンプレート」に並ぶ設定項目の定義は、ADMXファイル(設定の定義本体)とADMLファイル(言語ごとの表示文字列)で記述されています。各PCには C:\Windows\PolicyDefinitions にOS付属の定義が入っており、管理ツールはこれを読み込んで設定画面を組み立てます。7

ドメインで運用するなら、セントラルストアを作るのが基本です。ドメインコントローラーのSYSVOL配下に PolicyDefinitions フォルダーを作成すると(例: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)、その内容はドメイン内の全ドメインコントローラーに複製され、グループポリシーツールは既定でセントラルストアを参照するようになります。7 これで「編集する管理端末ごとにテンプレートのバージョンが違い、見える設定項目が食い違う」問題がなくなります。ADMLは言語別のサブフォルダー(日本語なら ja-JP)に置きます。7

運用上の注意は2つです。第一に、新しいWindowsバージョン向けのADMXはMicrosoftがバージョンごとに配布しており、更新するときはセントラルストア側を入れ替えます。各PCの C:\Windows\PolicyDefinitions をダウンロード版で置き換えるのはサポートされていません。7 第二に、既存のセントラルストアを更新するときは、本番の PolicyDefinitions を直接上書きせず、PolicyDefinitions-24H2 のようなバージョン名の作業フォルダーにOS分とアプリ分(OfficeやEdgeなど)のADMX一式をそろえ、現行フォルダーを PolicyDefinitions-23H2 などへリネームして退避したうえで、作業フォルダーを PolicyDefinitions にリネームして本番化する手順が案内されています。7 グループポリシーツールが参照するのは PolicyDefinitions という名前のフォルダーだけなので、バージョン名フォルダーに置いただけでは反映されません。問題が起きたら退避した旧フォルダーに戻せるのがこの方式の利点です。7

7. GPO vs Intune(MDM/CSP) vs 手動・スクリプト ── 判断表

Windows端末の構成管理の選択肢は、いまはGPOだけではありません。Intuneに代表されるMDMは、CSP(構成サービスプロバイダー)という仕組みを通じてOS設定を構成します。どれを軸にするかの判断表です。

観点 ドメインGPO Intune(MDM/CSP) 手動・スクリプト配布
前提 ADドメイン参加+ドメインコントローラーへの接続 Intuneライセンス+端末のIntune登録(Entra参加/ハイブリッド参加のほか、BYOD等のEntra登録デバイスも登録方式しだいで対象) なし(だからこそ統制もない)
社外・在宅端末への到達 VPN等でDCに届かないと更新されない インターネット経由で届く 手作業次第
設定の粒度・網羅性 最も広い(管理用テンプレート+セキュリティ設定+スクリプト等) 拡大中だが、GPO全設定と同等ではない9 書いた分だけ
強制力 ポリシーとして強制(Policiesキー優先)6 ポリシーとして強制(CSP) ユーザーが変更すれば戻らない
適用の確認手段 gpresult / GroupPolicy運用ログ45 Intune管理センターのレポート 自前で仕組みを作る
向いている環境 オンプレAD中心・社内LAN常駐の端末 クラウド中心・持ち出し端末・拠点分散 数台規模、または他の手段の補完

判断の軸はシンプルで、端末のアイデンティティ基盤(ADか、Microsoft Entraか)と、端末がどこにいるかです。オンプレADにフル参加した社内据え置きPCの集団にはGPOが最も確実で、Entra参加のモバイルPCにはGPOはそもそも届きません。

現実の中小企業はその中間、つまりハイブリッド(ドメイン参加+Intune登録)が多く、ここで最悪なのが「同じ設定をGPOとMDMの両方で構成する」ことです。Policy CSPにはGPOとMDMが競合したときにMDMを勝たせるMDMWinsOverGPというポリシーがありますが、適用範囲はPolicy CSP内の対応ポリシーに限られます。Microsoft自身が、この制御下にない設定をGPOとMDMの両方で構成すると競合状態になりどちらが勝つか保証されないとして、二重構成を避けるよう明言しています。8 設定領域ごとに「これはGPO、これはIntune」と管理主体を決めて片方に寄せるのが、ハイブリッド運用の第一原則です。

GPOからIntuneへの移行を考える段階では、IntuneのGroup Policy analyticsが入口になります。GPMCからエクスポートしたGPO(XML)をインポートすると、各設定がMDMでサポートされているか、非推奨・対応不能かを分析でき、対応済みの設定はIntuneの設定カタログポリシーへ移行できます。9 「全部移す」ではなく「移せるもの・移せないもの・捨てるものを仕分ける」ためのツールと捉えるのが実態に合っています。なお、Windows Updateの管理主体も同じ文脈で再編が進んでいます。「WSUS非推奨後のWindows Update管理」もあわせて参照してください。

8. 開発者視点の落とし穴 ── 客先GPOがアプリの動作を変える

最後に、受託開発の立場で押さえておくべき話です。客先のGPOは、あなたのアプリの前提条件を静かに書き換えます。「開発機では動くのに客先で動かない」の一因として、ファイアウォールやウイルス対策と並んでGPOは常連です。実例ベースで挙げます。

  • PowerShellの実行ポリシー: 実行ポリシーはGPOで集中構成でき、GPO由来のMachinePolicy/UserPolicyスコープは、ローカルやプロセスで設定した値より常に優先されます。10 インストーラーや運用スクリプトが「-ExecutionPolicy Bypassを付ければ動くはず」という前提で作られていると、GPO管理下では起動すらしません。詳細は「PowerShellの実行ポリシーとスクリプト署名」を参照してください。
  • ファイアウォールのローカル規則マージ無効化: GPO/Intuneでファイアウォールを集中管理している環境では、プロファイル単位で「ローカル規則のマージ」(AllowLocalPolicyMerge)を無効化できます。無効の環境では、インストーラーがローカルに登録した受信規則は存在していても適用されません。11 サーバー型アプリの導入前に必ず確認すべきポイントで、「Windowsファイアウォールと業務アプリ」で詳しく扱っています。
  • ドライブ割り当て・プロキシなどの環境構成: ネットワークドライブの割り当てやプリンターなどはグループポリシー基本設定(Preferences)で配布されているのが定番です。16 「Zドライブがあるはず」「プロキシは直結のはず」といった環境仮定は、サインインするユーザーやPCの所属OUによって崩れます。ユーザーの構成で配布された設定はサービスやタスクの実行アカウントには当然適用されないことも、常駐型アプリでは見落としがちです。
  • そもそも設定が「戻せない」: 管理用テンプレート由来の設定はユーザーが画面から変更できなくなっている(項目がグレーアウトする)のが普通です。「お客様側で設定を変えてもらえば直ります」が通用しない、というのは対応方針の設計に効いてきます。

開発側の現実的な備えは3つです。第一に、アプリが依存する環境前提(実行ポリシー、待ち受けポート、書き込み先、プロキシ経路など)を導入要件として文書化し、導入前に客先情シスへ確認を依頼する。第二に、トラブル時は憶測ではなく gpresult /h のレポートと HKLM\Software\Policies 配下の実値を確認する(5章)。第三に、管理者権限が必要な処理とそうでない処理を設計段階で分けておくことです(この線引きは「管理者特権はいつ必要か」で扱っています)。GPOは敵ではなく、環境の仕様です。仕様として扱えば、切り分けは機械的にできます。

9. まとめ

  • グループポリシーはGPO単位の設定をローカル→サイト→ドメイン→OU(LSDOU)の順に処理する仕組みで、競合は後勝ちです。対象に近いOUのGPOが最も強く、ローカルGPOが最も弱い層です。
  • 継承のブロック・強制(Enforced)・セキュリティフィルター処理で既定の流れを制御できます。強制は継承ブロックにも勝つため、多用は禁物です。
  • 適用は起動時・サインイン時の前景処理と、既定約90分+ランダムオフセットのバックグラウンド更新の二本立てです。gpupdate /forceは全設定の再適用であり、サインインや再起動でしか処理されない設定には効きません。
  • 反映されないときは gpresult /h → GroupPolicy運用ログ → レジストリのPoliciesキー、の順で機械的に切り分けます。拒否されたGPOには理由が表示されます。
  • 管理用テンプレートの定義はADMX/ADMLで、ドメイン運用ではSYSVOLのセントラルストアに集約します。更新時はローカルのPolicyDefinitions置き換えではなくセントラルストア側を入れ替えます。
  • GPOかIntuneかは端末のアイデンティティ基盤と所在で決め、ハイブリッドでは同じ設定の二重構成を避けて管理主体を片方に寄せます。移行の仕分けにはGroup Policy analyticsが使えます。
  • 開発者にとって客先GPOは環境仕様の一部です。実行ポリシー・ファイアウォール・ドライブやプロキシ構成などの前提を文書化し、gpresultで確認できる体制を作っておけば、「客先でだけ動かない」の多くは怖くありません。

関連記事

関連する相談領域

合同会社小村ソフトでは、GPO管理下の客先環境で業務アプリが動かない事象の原因調査、導入要件(実行ポリシー・ファイアウォール・ネットワーク前提)の整理、AD環境を引き継いだ情シス担当者向けのポリシー棚卸しやIntune併用方針の技術相談を扱っています。「gpresultのレポートを一緒に読んでほしい」といった段階からで構いません。

参考リンク

  1. Microsoft Learn, Group Policy processing and precedence. グループポリシーがローカルGPO→サイト→ドメイン→OUの順に処理され、後から処理されたGPOが競合時に上書きすること(競合しない設定は集約される)、同一コンテナー内の複数GPOはリンク順で処理されリンク順最小のGPOが最後に処理されて最優先になること、強制(Enforced)・リンク無効化・ユーザー/コンピューター設定の無効化・継承のブロックという例外、強制されたGPOは下位の継承ブロックがあっても適用され続けること、ワークグループのコンピューターはローカルGPOのみ処理すること、起動時にコンピューターポリシー・サインイン時にユーザーポリシーが適用される流れについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, ADMX_GroupPolicy Policy CSP. コンピューターのグループポリシーがシステム起動時に必ず適用され、既定で90分ごと+0〜30分のランダムオフセットでバックグラウンド更新されること、ユーザーのグループポリシーがサインイン時に必ず適用され同じく既定90分+0〜30分オフセットで更新されること、ドメインコントローラーの既定更新間隔が5分であること、更新間隔を0〜64,800分の範囲で構成できることについて。 ↩ ↩2

  3. Microsoft Learn, gpupdate. gpupdateが既定では変更のあったポリシー設定のみ適用し/forceで全設定を再適用すること、ユーザー向けソフトウェアインストールやフォルダーリダイレクトのようにバックグラウンド更新では処理されずサインイン時に処理される拡張のための/logoff、コンピューター向けソフトウェアインストールのように起動時に処理される拡張のための/boot、/target:{computer user}や/waitの各オプションについて。

    ↩ ↩2 ↩3

  4. Microsoft Learn, gpresult. gpresultがポリシーの結果セット(RSoP)を表示するコマンドであること、/hでHTML・/xでXMLのレポートを出力し/fで上書きできること、/rで概要表示・/v・/zで詳細表示ができること、/scope {user computer}で対象を絞れること、サイト・ドメイン・OUのメンバーシップにもとづいて重なり合ったポリシーの結果セットが生成されることについて。

    ↩ ↩2 ↩3

  5. Microsoft Learn, Applying Group Policy troubleshooting guidance. グループポリシーの切り分けで管理者権限のコマンドプロンプトからgpresult /hを実行してGPOが適用されない理由を確認する手順、GroupPolicy運用ログ(Microsoft-Windows-GroupPolicy/Operational)に適用されたGPOの一覧と拒否されたGPOの一覧が拒否理由とともに記録されること、ポリシー処理のインスタンスごとに一意のActivityIDが割り当てられ、カスタムビューで該当インスタンスのイベントだけを絞り込む手順、GPSvcのデバッグログの有効化について。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Implementing Registry-based Policy. レジストリベースのポリシーの格納先がHKCU\Software\PoliciesとHKLM\Software\Policies(推奨の場所)およびHKCU/HKLMのSoftware\Microsoft\Windows\CurrentVersion\Policiesに限られること、「未構成」状態ではレジストリに値を書かないこと、アプリはまずポリシーキーを読み、無ければプリファレンス値を読むべきでポリシーキーが常にプリファレンスキーに優先すること、格納できるデータ型がREG_DWORD・REG_SZ・REG_EXPAND_SZであること、ポリシー更新時にアプリがポリシーキーを再確認すべきことについて。 ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, How to create and manage the Central Store for Group Policy Administrative Templates in Windows. 管理用テンプレートが定義本体のADMXと言語別表示文字列のADMLに分かれていること、セントラルストアをドメインコントローラーのSYSVOL配下のPolicyDefinitionsフォルダー(例: \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions)として作成すること、内容がドメイン内の全ドメインコントローラーに複製されグループポリシーツールが既定でセントラルストアを参照すること、ADMLがen-USやko-KRのような言語別フォルダーに置かれること、ダウンロード版ADMXでC:\Windows\PolicyDefinitionsを置き換えるのはサポートされないこと、更新時はPolicyDefinitions-24H2のようなバージョン名の新フォルダーにOS分とアプリ拡張分のADMX/ADML一式をそろえ、現行フォルダーをPolicyDefinitions-23H2等にリネームして退避したうえで新フォルダーを本番名のPolicyDefinitionsへリネームする手順が案内されていること、重大な問題が起きた場合に旧フォルダーへ戻せることがこの方式の利点とされることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Microsoft Learn, ControlPolicyConflict Policy CSP. MDMWinsOverGPポリシー(既定値0)を1に設定するとPolicy CSP内の対応ポリシーについてMDM設定がグループポリシーに優先すること、適用対象がPolicy CSP内のポリシーに限られDefender CSPなど他のCSPには適用されないこと、この制御下にない設定をGPOとMDMの両方で構成すると競合状態になりどちらが勝つか保証されないため二重構成を避けるべきとされていることについて。 ↩ ↩2

  9. Microsoft Learn, Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune. Group Policy analyticsがオンプレミスのGPOをインポート・分析し、Intuneを含むMDMプロバイダーがサポートする設定と非推奨・利用不能な設定を表示すること、GPMCからXML形式でエクスポートしたGPOをインポートすること、インポートしたGPOを設定カタログポリシーへ移行してデバイスに展開できることについて。 ↩ ↩2 ↩3

  10. Microsoft Learn, about_Execution_Policies. 実行ポリシーのスコープがMachinePolicy・UserPolicy・Process・CurrentUser・LocalMachineの優先順で評価されること、MachinePolicyとUserPolicyがグループポリシーによって設定されるスコープであり、下位のスコープでより緩い(または厳しい)ポリシーを設定しても優先順位の高いポリシーが有効になること、Get-ExecutionPolicy -Listで全スコープの設定を確認できることについて。 ↩ ↩2

  11. Microsoft Learn, Windows Firewall rules. GPOやCSPによるファイアウォールの集中管理環境でプロファイル単位に「ローカル規則のマージ」(AllowLocalPolicyMerge)を無効化でき、無効の場合はローカルで作成した規則が適用されず、受信接続が必要なアプリの規則は集中配布が必須になることについて。 ↩ ↩2

  12. Microsoft Learn, Step-by-Step Guide to Managing Multiple Local Group Policy Objects. Windows Vista以降のローカルGPOが「ローカルコンピューターポリシー」「管理者/非管理者用」「特定ユーザー用」の複数レイヤー(MLGPO)を持つこと、ローカルコンピューター→管理者/非管理者→ユーザー別の順に処理され最後に読まれるユーザー別が最も優先されること、ドメイン非参加PCの管理向けの機能であることについて。 ↩

  13. Microsoft Learn, Security filtering using GPMC. セキュリティフィルター処理がGPOの設定を受け取るユーザーとコンピューターを絞り込む仕組みであること、GPOが適用されるには対象のユーザーまたはコンピューターが「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持つ必要があること、既定で全GPOにAuthenticated Users(ユーザーとコンピューターを含む)へ両許可が与えられていること、フィルターはGPO全体に働き設定ごとには使えないことについて。 ↩

  14. Microsoft Learn, Deploying Group Policy Security Update MS16-072 (KB3163622). MS16-072適用後はユーザーのグループポリシーがコンピューターのセキュリティコンテキストで取得されるという設計変更、そのためコンピューターアカウントがGPOの読み取りアクセスを必要とすること、セキュリティフィルター処理等でAuthenticated Usersの許可を外している場合はAuthenticated UsersまたはDomain Computersに「読み取り」(「グループポリシーの適用」は不要)を追加する必要があることについて。 ↩ ↩2

  15. Microsoft Learn, Loopback processing of Group Policy. ループバック処理が、コンピューターオブジェクトの場所にもとづいてユーザー設定のGPOセットを適用する機能であること、公共エリア・ラボ・教室のような特殊用途のコンピューターを想定した仕組みであること、Active Directory環境でのみサポートされ、マージと置換のモードがあることについて。 ↩

  16. Microsoft Learn, Group Policy Preferences Getting Started Guide. グループポリシー基本設定(Preferences)がドライブの割り当て・プリンター・スケジュールされたタスク・サービス・フォルダーオプションなどを構成するGPMCの拡張群であること、アイテムレベルターゲット処理による絞り込みができること、ユーザーによる変更を制限せずに設定を配布でき、強制する設定としない設定を選べる(ポリシーとは性格が異なる)ことについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

gpupdate /force を実行したのに設定が反映されません。なぜですか？
まず、その設定が「バックグラウンド更新では反映されない種類」でないかを確認してください。ユーザー向けソフトウェアインストールやフォルダーリダイレクトはサインイン時に、コンピューター向けソフトウェアインストールは起動時にしか処理されないため、gpupdateの完了後にサインアウト(/logoff)や再起動(/boot)が必要です。次に gpresult /h でRSoPレポートを出力し、そのGPOが「適用されたGPO」に入っているか、「拒否されたGPO」に理由付きで入っていないかを確認します。適用されているのに動作が変わらない場合は、より優先順位の高い別のGPOが同じ設定を上書きしている(後勝ち)可能性を疑ってください。レポートには各設定の「優先するGPO」が表示されるので、どのGPOが勝っているかまで特定できます。
gpresult に「フィルターで拒否」と表示されるのはどういう意味ですか？
そのGPOはリンクの場所としては対象に入っているものの、フィルター処理によって適用対象から外された、という意味です。代表的な原因はセキュリティフィルター処理で、GPOを適用するにはユーザーまたはコンピューターがそのGPOに対して「読み取り」と「グループポリシーの適用」の両方のアクセス許可を持っている必要があります。既定ではAuthenticated Usersに両方が許可されていますが、特定のグループに絞る運用をしている場合、グループへの追加漏れやコンピューターアカウントの入れ忘れで拒否されます。またユーザー向けGPOでは、対象ユーザーに両方の許可を与えるだけでは足りません。MS16-072以降、ユーザーポリシーはコンピューターのセキュリティコンテキストで取得されるため、Authenticated UsersまたはDomain Computersに「読み取り」(「適用」は不要)を残しておく必要があります。ほかにWMIフィルターの条件不一致や、GPO側でユーザー/コンピューター側の設定が無効化されているケースもあります。拒否理由はgpresultのレポートとGroupPolicy運用ログの両方に記録されます。
GPOとIntuneのどちらで管理すべきですか？
端末のアイデンティティ基盤に合わせるのが基本です。オンプレミスADにドメイン参加している端末が中心で、社内ネットワークに常時つながっているなら、GPOが最も確実で粒度も細かい選択肢です。Microsoft Entra参加の端末やドメインコントローラーに接続しない在宅端末が増えているなら、社外でも構成が届くIntune(MDM/CSP)が適します。両方が混在するハイブリッド環境では、同じ設定をGPOとMDMの両方で構成すると競合して結果が保証されないため、設定領域ごとにどちらで管理するかを決めて片方に寄せるのが原則です。移行を検討する段階では、IntuneのGroup Policy analyticsで既存GPOをインポートすると、MDMで対応済みの設定と非対応・非推奨の設定を仕分けできます。
ローカルグループポリシー(gpedit.msc)で設定した内容が、ドメインの設定に上書きされます。仕様ですか？
仕様です。グループポリシーはローカル→サイト→ドメイン→OUの順(LSDOU)で処理され、後から処理されたものが競合時に勝つため、ローカルGPOは最も弱い層になります。ドメインGPOが同じ設定を構成していれば、ローカルでの変更は常に上書きされます。逆に、ドメイン側が「未構成」にしている設定であれば、ローカルGPOの値がそのまま生きます。検証などでどうしてもローカル設定を優先したい場合でも、ドメイン参加PCでこの優先順位を覆す方法はないため、検証用OUを作ってドメイン側のGPOを調整するか、ドメイン非参加の検証機を使うのが現実的です。
開発した業務アプリが客先環境でだけ動きません。GPOが原因か確かめる方法はありますか？
客先の管理者に依頼して、問題のPCで管理者権限のコマンドプロンプトから gpresult /h report.html を実行してもらい、RSoPレポートを確認するのが第一歩です。実行ポリシーによるスクリプト停止、ファイアウォールのローカル規則マージ無効化、プロキシやドライブ割り当ての構成など、アプリの動作を変える設定が適用されていないかを見ます。あわせて、レジストリの HKLM\Software\Policies と HKCU\Software\Policies 配下に関連製品のポリシー値が書かれていないかを確認すると、管理用テンプレート由来の強制設定を機械的に洗い出せます。開発側でできる備えとしては、アプリが依存する前提(実行ポリシー、受信ポート、書き込み先フォルダーなど)を導入手順書に明記し、導入前に客先の情シスに確認してもらうことです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る