GPO（グループポリシー）が適用されないときの確認順——gpupdate・gpresultで原因を切り分ける

GPO（グループポリシー）を変更したあと、私も反映確認のために、まず gpupdate /force を実行することがあります。正常終了したのに設定が変わらないときは、次に gpresult で適用結果を確認します。

もちろん便利なコマンドですが、正常に完了しても、目的のGPOがそのPCやユーザーへ適用されたとは限りません。また、/force は変更のない設定も含めて再適用するため、毎回必要というわけでもありません。

以下は確認先を順番に並べたものです。更新がすでに正常終了している場合は、「確認2：gpresult /r」から進めて構いません。

忙しい人向けの結論

大切なのは、gpupdate /force を何度も繰り返すことではなく、その次に gpresult で結果を見ることです。目的のGPOが一覧に出ていなければ、再実行よりもリンク先や適用対象を確認した方が早く原因へ近づけます。

最初に「ユーザー」と「コンピューター」を分ける

GPOには「ユーザーの構成」と「コンピューターの構成」があります。ここを曖昧にしたまま調べ始めると、正しいOUを見ているつもりでも適用先がずれてしまいます。

たとえば、ドライブマップは通常「ユーザーの構成」です。PCが入っているOUだけへGPOをリンクしても、対象ユーザーへは届きません。反対に、コンピューターの構成をユーザーOUだけへリンクしても、通常は目的のPCへ適用されません。

ループバック処理を使う構成もありますが、まずは「設定がユーザー向けか、PC向けか」「対象オブジェクトがどのOUにいるか」を確認するところからで大丈夫です。

確認1：gpupdate /forceの結果を読む

クライアントPCでコマンドプロンプトを開き、次を実行します。

gpupdate /force

「ユーザーポリシーの更新が正常に完了しました」「コンピューターポリシーの更新が正常に完了しました」と表示されれば、更新処理そのものは完了しています。ここではまず、エラーが出ていないかを確認します。通常更新と /force の違いは、このあとで整理します。

ただし、これは作成したGPOが適用されたという意味ではありません。対象外のGPOがあっても、ほかのポリシー更新が正常に終われば正常終了と表示されることがあります。

ログオフや再起動を求められた場合は、作業中のデータを保存してから案内に従います。フォルダーリダイレクトやソフトウェアインストールなど、ログオン時・起動時に処理される設定は、gpupdate /forceだけでは反映が完了しない場合があります。

実務では更新対象を絞ると分かりやすい

毎回すべてを強制更新する必要はありません。調べている設定がユーザー向けか、コンピューター向けか分かっている場合は、/target で対象を絞れます。

ドライブマップなど、ユーザーの構成だけを更新する場合：

gpupdate /target:user

PC全体の設定など、コンピューターの構成だけを更新する場合：

gpupdate /target:computer

通常更新と /force は何が違う？

通常の gpupdate は、原則として、前回の更新後に変更があったとWindowsが判断したポリシー設定を処理します。

たとえば、GPOで配布しているドライブマップの共有先を変更した場合は、GPO側に変更があるため、通常は次のコマンドで更新対象になります。

gpupdate /target:user

反対に、前回の更新後からGPO側に変更がなければ、同じコマンドを実行しても、変更のない設定をすべて最初から適用し直すわけではありません。

/force を付けると、変更の有無にかかわらず、対象となるポリシー設定をすべて再適用します。

gpupdate /target:user /force
gpupdate /target:computer /force

検証やトラブルシューティングで /force がよく使われるのは、「変更を検出できているか」に左右されず、一度すべて再処理させて動作を確認できるためです。ただし、OUやセキュリティフィルタリングが間違っていて、そもそも適用対象になっていないGPOまで強制的に適用する機能ではありません。

そのため、普段の反映確認ではまず /target:user または /target:computer を使い、再適用して比較したい場合に /force を加える、と考えると分かりやすいです。

gpupdate は、実行したクライアントPC自身のポリシーを更新するコマンドです。ドメインコントローラー上で実行しても、すべてのクライアントPCが一斉に更新されるわけではありません。まずは問題が起きている端末で実行してください。

/logoff や /boot というオプションもありますが、サインアウトや再起動につながるため、普段から何となく付ける必要はありません。Windowsから再ログオン・再起動を求められた場合に、作業中のデータを保存して対応する方が安心です。

ユーザー設定は、問題が起きているユーザー本人の通常権限のコマンドプロンプトで確認します。別の管理者アカウントで開くと、その管理者の結果を見てしまいます。コンピューター設定を調べるときだけ、管理者として開いた画面を使います。

確認2：gpresult /rで適用結果を見る

次に、現在のユーザーとPCへどのGPOが適用されているか確認します。

gpresult /r

「適用されたグループポリシー オブジェクト」に、調べたいGPO名が表示されるか確認します。

• 表示される：GPO自体は適用対象。設定内容や競合、再起動の要否を確認する
• 表示されない：OU、リンク、セキュリティフィルタリングなどを確認する
• 拒否されたGPOに表示される：拒否理由やフィルター条件を確認する

ユーザー側だけを確認したい場合は、次のようにスコープを指定できます。

gpresult /r /scope:user

コンピューター側を確認する場合は、管理者として開いたコマンドプロンプトで実行します。

gpresult /r /scope:computer

確認3：gpresult /hで詳しいレポートを作る

gpresult /r だけでは分かりにくい場合は、HTML形式のレポートを作成します。

gpresult /h "%USERPROFILE%\gpresult.html" /f

%USERPROFILE% は、現在ログオンしているユーザーのプロファイルフォルダー（通常は C:\Users\ユーザー名）を表す環境変数です。保存先はデスクトップ以外でも構いません。既に存在するフォルダーであれば、C:\Users\user01\Documents\gpresult.html のように実際のフルパスを指定することもできます。

ユーザープロファイルフォルダーに作成された gpresult.html を開き、次を確認します。

• 適用されたGPO
• 拒否されたGPOと理由
• ユーザー・コンピューターが所属するOU
• セキュリティグループ
• 実際に適用された設定値

「GPOを作った場所」ではなく、クライアントPCが実際に受け取った結果を確認できるのがポイントです。GPMCの設定画面だけを見続けるより、ここで一度クライアント側の事実を確認した方が切り分けやすくなります。

確認4：OU・リンク・GPOの状態を確認する

目的のGPOが gpresult に出てこない場合は、グループポリシーの管理（GPMC）で次を確認します。

• GPOが対象ユーザーまたはコンピューターのOUへリンクされているか
• リンクが有効になっているか
• GPOの状態で、必要な「ユーザーの構成」または「コンピューターの構成」が無効になっていないか
• 上位OUで継承がブロックされていないか
• 別のGPOと設定が競合していないか

検証中にOUを移動した場合は、AD上で対象オブジェクトが本当に移動できているかも確認します。似た名前のユーザーやPCがあると、別のオブジェクトを見ていた……ということもあります。

確認5：セキュリティフィルタリングとグループを確認する

GPOの「スコープ」タブにあるセキュリティフィルタリングで、対象を限定している場合もあります。対象ユーザーやコンピューターに、GPOの読み取りと適用に必要な権限があるか確認します。

WMIフィルターを設定している場合は、対象PCのOSや端末条件がフィルターに一致しているかも確認します。条件に一致しないGPOは、gpresultで拒否・除外されたGPOとして確認できる場合があります。

また、セキュリティグループへユーザーを追加した直後は、gpupdate /forceだけではログオン中のグループ情報が更新されない場合があります。一度サインアウトして、サインインし直してから確認してください。

現在のログオンセッションが認識しているグループは、次のコマンドでも確認できます。対象グループが表示されなければ、サインアウト・サインイン後にもう一度確認します。

whoami /groups

ドライブマップなどで「項目レベルのターゲット設定」を使っている場合は、GPO全体のフィルタリングだけでなく、各項目の「共通」タブも確認します。GPOは適用済みなのに特定のドライブだけ出ない場合は、こちらが原因になっていることがあります。

確認6：DNSとドメイン接続を確認する

GPOはActive DirectoryとSYSVOLから情報を取得します。クライアントPCのDNS設定が、社内のAD DNSではなくルーターやパブリックDNSだけを向いていると、ドメインコントローラーを正しく見つけられない場合があります。

まず、次のコマンドでDNSサーバーを確認します。

ipconfig /all

次はコマンドプロンプト用です。%LOGONSERVER% はログオンに使ったサーバーの手掛かりで、現在そこへ通信できることまでは証明しません。PowerShellでは $env:LOGONSERVER を使います。

echo %LOGONSERVER%

続いて、ドメインコントローラーを検出できるか確認します。以下の example.local は、自分のADドメイン名へ置き換えてください。

nltest /dsgetdc:example.local

DC名やアドレスが返らない場合は、GPOより先にDNS、ネットワーク、VPN接続、時刻同期などを確認します。

確認7：それでも分からなければイベントログを見る

ここまで確認しても原因が分からない場合は、クライアントPCでイベントビューアーを開きます。

アプリケーションとサービス ログ → Microsoft → Windows → GroupPolicy → Operational

このログでは、GPOの処理状況や拒否理由、処理中に発生したエラーを確認できます。イベントIDを最初からすべて覚える必要はありません。まずエラーや警告が発生した時刻と、gpupdate /forceを実行した時刻を合わせて見るだけでも、かなり絞り込みやすくなります。

掲載画像で選択しているイベント8004は処理完了の記録です。エラーの例ではありません。自分のPCでは、問題が起きた時刻のエラー・警告を開き、メッセージとイベントIDを控えます。

「適用されているのに見えない」こともある

GPOが適用されていても、確認方法の違いで「反映されていないように見える」ことがあります。

ネットワークドライブの検証では、エクスプローラーにSドライブが表示されているのに、管理者として開いたコマンドプロンプトの net use には表示されないことがありました。通常権限のコマンドプロンプトで確認すると表示され、原因はGPOではなくUACによる実行コンテキストの違いでした。

このように、「GPOが届いていない」のか「届いているけれど確認する場所が違う」のかでも対応が変わります。先に gpresult でGPO自体の適用状況を確認しておくと、設定を何度も作り直さずに済みます。

ドライブマップの具体的な設定は、GPOでネットワークドライブを自動割り当てする方法でまとめています。

よくある状態から確認先を絞る

GPOの適用確認ができたあと、遠隔保守用の通信を整えたい場合は、PingとRDPをGPOで許可する手順へ進めます。通信できないときも、先に本記事の順番でGPOの適用有無を分けておくと調査しやすくなります。

参考資料

• Microsoft Learn「gpupdate」
• Microsoft Learn「gpresult」
• Microsoft Learn「グループポリシーの適用に関するトラブルシューティング」