問題は、クライアントが新しく起動したときにグループ ポリシーが適用されないことです。起動直後、クライアントはイベント ログにソース「GroupPolicy (Microsoft-Windows-GroupPolicy)」とイベント ID 1058「グループ ポリシーの処理に失敗しました。[...]」というエラー メッセージを投稿します。[詳細] タブの ErrorCode は 50 で、これは ERROR_NOT_SUPPORTED を表します。これは単なる表面的な問題ではありません。ポリシーは実際には正しく適用されていません。たとえば、マップされたネットワーク ドライブが存在しません。しばらく待つと、「gpupdate」を実行すると、ポリシーが正常に適用され、マップされたネットワーク ドライブが表示されます。
問題を再現できた最も単純なシナリオ: 新しくインストールされた Windows Server 2012R2 上に新しく作成されたドメイン、クライアントは新しくインストールされた Windows 10 64 ビット マシンです。ドメインは 1 つのドメイン コントローラーのみで構成され、他のドメインとは関係がありません。
エラー メッセージには、Windows がドメインの Sysvol 共有から .GPT ファイルを読み取ることができないと記載されているため、コマンド プロンプトから同じファイルにアクセスしようとしました。実際、起動直後にコマンド プロンプトを開くと、次のメッセージが表示されます。
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
1 ～ 2 分待ってから同じコマンドを実行すると、ディレクトリの一覧が表示されます。この時点で gpupdate を実行すると問題なく動作します。
グループ ポリシー設定「コンピューターの起動時およびログオン時に常にネットワークを待機する」を「有効」に設定し、このポリシーが適用されていることはわかっています。同じポリシー オブジェクトでレジストリ設定が指定されており、クライアントのレジストリを確認すると、指定された設定がそこにあります。
関連する可能性のあるその他の要因:
- NTLM はドメイン内で制限されていますが、これは問題ではないようです。NTLM を有効にし、ポリシーを更新してすべてのマシンを再起動した後でも、症状は同じままです。
- サーバーが DHCP を使用して構成されているか、静的構成で構成されているかは関係ありません。
- ドメインの DNS サーバーは動的更新をサポートしていません。必要なレコードは手動で追加されました (C:\Windows\System32\config\netlogon.dns から)
- クライアント側では休止状態が無効になっている
powercfg /h offため（ を使用）、各ブートは高速ブートではなく完全ブートになります。 - ポリシーのスタートアップポリシー処理待機時間は120秒に設定されています
- DC への接続は正常に機能します。ping は機能します。クライアントをオフにし、AD でアカウントを無効にし、クライアントをオンにすると、クライアントにログインできなくなります。アカウントが無効になっていることがすぐに認識されます。
- この問題以外には、異常な点は見当たりません。
これはグループ ポリシーの問題というよりも、SMB の問題であると思われます。サーバー側で接続をスニッフィングすると、興味深いことがわかります。コマンドを初めて実行するとdir \\domain.example.com\sysvol、DC 上の Microsoft Message Analyzer に次の内容が表示されます。
- クライアントは DC のポート 445 への TCP 接続を確立し、ComNegotiation が正常に実行されます (DialectRevision: 0x02FF)。
- その後すぐに、Negotiate が正常に実行されます。DialectRevision は 0x0302 です。
- その後すぐに、クライアントは TCP RST (??) で TCP 接続を閉じます。
次回コマンドを発行してエラーが発生するたびに、手順 2 と 3 が発生します。
コマンドが機能し始めると、手順 1 と 2 が実行されますが、クライアントが TCP RST を送信する代わりに、SessionSetup が実行され、次に TreeConnect が実行され、その後、大量の (一見通常の) SMB チャタリングが発生します。
そのため、クライアントは起動後 1 ～ 2 分までは DC と SMB を適切に通信できず、グループ ポリシーの処理が失敗するようです。
この問題をデバッグして解決する方法を知っている人はいますか?
答え1
Windows 8 以降、Microsoft は「高速起動」という概念を導入しました。これは、OS をシャットダウンすると、通常の休止状態シナリオで休止状態が機能するのと同じように、OS のメモリ フットプリントを休止状態にするものです。これにより、OS の起動が速くなりますが、起動時にコンピューターごとの GP 処理が無効になるという副作用もあります。おそらくこれが表示されているもので、コンピューターの構成\ポリシー\管理用テンプレート\システム\シャットダウン\高速起動の使用を要求するのポリシーを無効にすることで無効にできます。
それでも問題が解決しない場合は、ネットワーク スタックのタイミングの問題である可能性が高く、ネットワーク スタックが完全に初期化される前にコンピューターの GP 処理が開始されます。この問題は XP 以降発生しており、Windows 7 以降では、Microsoft はコンピューターの構成\ポリシー\管理用テンプレート\システム\グループ ポリシー\スタートアップ ポリシー処理待機時間の下にポリシーを追加しました。このポリシーでは、GP が開始するまでの待機時間を長くすることができます。これを 60 秒に設定して、改善されるかどうかを確認してください。
ダレン
答え2
私はこの問題を自分で解決することができました。参照私の問題を解決したのは次の通りです:
まず、NTLMのブロックをすべて無効にすると、同じ症状が発生するという私の考えは間違っていました。違う症状は、たまたま同じ効果がありました。NTLM ブロッキング ポリシーが有効になっていないため、dirコマンドを実行するとアクセス拒否エラーが発生します。グループ ポリシーは依然として適用されませんが、これは当然です。SYSVOL にはまだアクセスできません。
少し Web 検索してみたところ、もっと一般的な問題があることがわかりました。どうやら、Windows 10 クライアントはドメイン コントローラーの SYSVOL 共有 (おそらく NETLOGON 共有も) へのアクセスに問題が発生することがあります。おそらく、Windows 10 ではこれらの共有へのアクセス方法が変更になったため、問題が発生する可能性があります。回避策は、Windows 10 クライアントの「強化された UNC パス」グループ ポリシーを次のように設定して、クライアントでこれらの共有の UNC パス強化を無効にすることです。
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(Windows 10 クライアントから Netlogon 共有にアクセスする際に問題が発生している場合は、その共有の 3 つのパラメータをすべて 0 に設定すると問題が解決する可能性があります。)
を参照してくださいMS15-011 に関する Microsoft の記事詳細については、こちらをご覧ください。この設定を変更した場合のセキュリティ上の影響と、ポリシーを変更する詳細な手順が詳しく説明されています。
警告: 上記の設定に注意してください無効にするセキュリティ問題 MS15-011 に対する保護の一部またはすべてが作成されました。しないでください盲目的にコピー/貼り付けするのではなく、関連するリスクに基づいて情報に基づいた決定を下してください。また、この問題は将来解決される可能性があります。その場合は、このポリシーを MS15-011 に記載されている推奨値に設定することを忘れないでください。
答え3
このスレッドを見つけた他の方のために参考までに、相互認証を 0 に設定して UNC 強化をオフにすると、セキュリティの一部が無効になります。私たちも win7 クライアントで同じ問題が発生しており、Microsoft と協力して解決しようとしています。Microsoft は、これはバグだと言いましたが、今のところ、バグがいつ解決されるかを追跡する方法は教えてくれませんでした。
詳細については、この他のスレッドを参照してください。 https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64
答え4
レジストリの変更やローカル グループ ポリシーの変更など、いくつかの提案を試しましたが、どれも問題を解決しませんでした。マップされたドライブは起動時に X で閉じられたままでした。gpupdate を実行すると毎回修正されますが、ユーザーにとっては余分な手順が必要でした。
最終的にこの問題を解決したのは、ネットワーク ドライブを手動でマッピングし、それぞれの GPO エントリを置き換えることでした。切断して置き換える必要はなく、マッピングしたのと同じように、手動でマッピングしました。