Active Directoryのグループポリシーをトラブルシューティング
ADのグループポリシーはたくさんのクライアントPCに共通設定を反映させることのできる便利な機能です。
しかし、せっかく設定したポリシーがクライアントPCに反映されていない、思ったような結果が得られていないということはよくあります。
そこで今回は私が良く使うグループポリシー設定のトラブルシューティング方法をご紹介します。
トラブルシューティングフロー
大体こんな感じで攻めていきます。
クライアントPCのポリシー適用チェック
ここでは、ADサーバに設定したポリシーがそもそもクライアントPCに反映されていない可能性を模索していきます。
ポリシーが反映されていない原因としては、時間差で反映されていないだけの場合や、そのアカウントやPC自体にポリシーのアクセス権が無い、OUにリンクされていない等があります。
ポリシー適用のチェックはクライアントPCにて管理者でコマンドプロンプトを起動し、gpresult /rコマンドを実行します。
このコマンドの”適用されたグループポリシーオブジェクト”という項目には適用されているグループポリシー名が表示されます。
ここにADサーバに設定したグループポリシー名が表示されていない場合は、引き続き原因を探しましょう。
表示されている場合はポリシー適用はOKなので”設定値の変化チェック”に進んでください。
※ユーザーの構成ポリシーは一般ユーザ権限のコマンドプロンプトでもチェックできますが、コンピュータの構成ポリシーをチェックするには管理者権限が必要です。
ポリシー更新、クライアントPC再起動
もしかしたら時間差でポリシーが適用されていないだけかもしれません。
ということでポリシーを手動で再適用させてみます。ポリシーを再読み込みするコマンドは同じく管理者権限のコマンドプロンプトで gpupdate /force を実行しましょう。
正常更新完了後、もう一度gpresult /rコマンドで適用の確認をしてください。あっさり適用されることもあります。
gpupdateコマンドで何かエラーが出てきたらとりあえず再起動しましょう（再起動は正義）。
それでもエラーが出る場合は、そもそもADサーバとの通信やドメイン参加処理自体が怪しいので後述のドメイン再参加を試してください。
ADサーバの制約条件、フィルタ等調査
ADサーバはいろいろな設定で適用するポリシーの条件を制御することができます。
これらの制御が誤作動して思わぬフィルタがかかっているかもしれないので、その原因調査です。
経験上、多い順に並べてみました。
- OUのリンクで設定対象になっていないかも？
- セキュリティフィルター処理でフィルタされているかも？
- グループポリシーの継承で設定が打ち消されているかも？
- 委任アクセス許可が無いかも？
- WMIフィルターの設定ミスかも？（本記事では割愛）
OUのリンクで設定対象になっていないかも？
ADサーバのグループポリシーの管理画面を開きます。
画面左側にツリー構造が現れますが、グループポリシーオブジェクトは作成しただけではクライアントPCに一切反映されません。
ドメインやOU（組織単位）にリンクして初めて設定が順次クライアントPCに反映されていきます。
下記画像の例ではsyanaise-soudan.localというドメイン配下に”リモートデスクトップ許可”というグループポリシーオブジェクトがリンクしています。
この場合、このドメインに参加したPC、サーバは全てこのグループポリシー設定が適用されます。
下記のように”ProvisioningPC”OUにリンクしている場合は、ProvisioningPCというOUにユーザーやコンピュータが格納されている必要があります。
どのOUにどのユーザーやコンピュータが格納されているかはActive Directoryユーザーとコンピューター管理画面で確認します。
下記画像の場合はPC-754とPC-992というコンピュータが対象になります。
ただし、ここで注意点があります。
グループポリシーで設定できる内容は大きく分けて”コンピュータの構成”と”ユーザーの構成”に分かれます。
このうち、”コンピュータの構成”の設定対象になるには、リンクしたOUにコンピュータオブジェクトが含まれる必要があります。
このうち、”ユーザーの構成”の設定対象になるには、リンクしたOUにユーザーオブジェクトが含まれる必要があります。
例えば、下記画像の場合はコンピュータの構成がPC-754とPC-992に反映されますが、”市井 唯”というユーザーがログインしている”PC-001”というコンピュータには反映されません。
反映させるには”PC-001”というコンピュータオブジェクトもProvisioningPC OUに含んでいる必要があります。
逆に、ユーザーの構成は”市井 唯”というユーザーがログインするすべてのドメイン参加PCに反映されますが、PC-754とPC-992には反映されません。
そのため、現在こまっているドメイングループポリシー設定はコンピューターの構成なのかユーザーの構成なのかは意識して使い分ける必要があります。
セキュリティフィルター処理でフィルタされているかも？
グループポリシーオブジェクトのスコープタブを開くと、セキュリティフィルター処理の項目があります。
このフィルターを設定すると同じリンク先のOUでも、○○というユーザーだけ、××というユーザーグループだけ、などの設定が可能です。
下記のようにデフォルト設定のAuthenticated Usersのみになっている場合はフィルタなしと同義とお考え下さい。
（Authenticated Usersはドメイン参加するすべてのユーザーとコンピューターオブジェクトという意味です）
下記のような感じだと、たとえドメイン全体にGPOをリンクしても反映されるのはPC-992のコンピュータ設定のみです。
（私はポリシーの事前検証時にこのような設定をして、そのままもとに戻し忘れる、ということがあります・・・）
委任アクセス許可が無いかも？
あまり変更することはありませんが、GPOの委任設定もセキュリティフィルター設定同様にチェックしてください。
WMIフィルターの設定ミスかも？（本記事では割愛）
WMIフィルターを使うと、クライアントPCのOSやそのバージョン、メモリ容量やディスク容量などなどで超柔軟なフィルタを構成できます。
ここの説明だけでも相当長くなる（というか説明しきれない）ので詳細は割愛・・・<m( _ _ )m>
ドメイン再参加
ADサーバの制約条件やフィルタに問題が無いのに設定が入ってこない、gpupdateができない、などの場合はクライアントPCを一度ドメインから外して、もう一度参加してみてください。
ADサーバとクライアントPCの間で整合性に不具合があったり、実はADサーバとの通信自体に失敗している可能性があります。
設定値の変化チェック
さて、無事gpresult /rコマンドでGPOが適用されたとします。
しかし、それでもやりたいことが実現できていない場合は、GPOが適用されているけど設定値が変化していない可能性があります。
ここでいう設定値とは、”このポリシーが反映されると変化するはずの値”です。
例えばログオンスクリプトを実行して、とあるファイルをサーバからローカルにコピーする、という設定の場合はローカルにファイルがあるかどうかのチェックになります。
また、ある設定を変更する場合は、その設定に関連するレジストリの値なんかもチェックしやすいです。
想定していた設定値が変化していない場合は、下記を確認していきましょう。
自作プログラムの確認
コマンドが正しくないかも？
ログオンスクリプトのように、何かのアクションで自前で作ったバッチやスクリプトを動かす場合、そのバッチやスクリプトに原因があるというパターンはよくあります。
また、コードの中に管理者権限が必要なコマンドが含まれる場合はログオンスクリプトではなくスタートアップスクリプトでないと動作しないことがあります（ログオンスクリプトはあくまでログインした時に、そのユーザーの権限で実行します）。
ADサーバの設定確認
ポリシーで設定する項目が違うかも？
単純ですが私も時々やってしまいます、そもそも設定する項目を間違えている場合です。
実現したいことがそもそもそのポリシー設定で確実にあっているのかどうか見直してみましょう。
また、”ユーザーの構成”と”コンピュータの構成”で同じような設定項目が存在する場合があり、どちらを対象にしたいのか間違えていることもあります。
ポリシーの対応条件を満たしていないかも？
グループポリシーによっては対応OSのバージョンや前提条件などがあります。
これらの前提条件を満たしているかどうかチェックしましょう。
他のポリシーで設定が無効になっているかも？
ポリシーの設定によっては、他の設定を上書きするポリシーもあります。
今回設定が反映できずに困っているポリシー設定が他のポリシーによって上書き対象になっていないかどうか確認してください。
また、1つのOUに複数のGPOがリンクしている場合は他のGPOのポリシー設定の影響を受けている可能性もあります。
グループポリシーの継承で設定が打ち消されているかも？
1つのOUに複数のGPOがリンクしていて、お互いに相反する設定が含まれている場合、そのどちらの設定が優先されるかは”グループポリシーの継承”設定で決まります。
少し紛らわしいですが、優先順位1番のポリシーから順番に適用されていきます。そのため、相反する設定がされている場合は優先順位の数字が最も大きいポリシーの設定が優先されます。
下記画像の場合、仮にリモートデスクトップGPOでリモート許可の設定をしていても、Default Domain設定でリモート拒否の設定になっているとリモートは拒否の設定になります。
複数のグループポリシーが設定されている場合、相反する設定があるかどうか、継承の優先順位はどうなっているかチェックしてみてください。
そもそも設定対象が違うかも？
さて、設定対象の設定値も想定通りに変化するようになりました。
それでもやりたいことが実現できない場合は、そもそもやりたいことに対して設定対象が違うかもしれません。
私もたまにありますが、”おっ、このポリシーでいけそうやん！”と思って設定するも思うような結果が得られず、よくよくMicrosoft Learn等で情報収集すると勘違いしてました、というパターンです。
根気よく違う方法でやりたいことが実現できないか、情報を収集しましょう。
まとめ
なんでもそうですが、グループポリシーのトラブルシューティングも1つずつ切り分けながら原因を特定していきましょう。
慣れると短時間で原因を探すことができるようになりますが、私は今でもこの順番で攻めていくことが多いです。
（複雑でニッチな個別対応みたいな設定はできるだけやめた方がいいよ、トラブルシューティングが超面倒だよ！）