「ドメイン コントローラーへのネットワーク接続が存在しないため、グループ ポリシーの処理に失敗しました」と表示されたら、Pingが通るだけでは正常と判断できません。GPO処理にはDNSによるDC検出、Kerberos、LDAP、SMB、RPC、時刻同期、コンピューターの信頼チャネルが関係します。まずイベントIDとActivityID、適用結果、IP/DNS、DC検出を読み取り専用で記録し、次に必要ポートとSYSVOL到達性を確認します。原因を特定する前にDNSを公開DNSへ変える、IPv6やファイアウォールを無効にする、ドメインへ再参加する操作は避けてください。
エラーの時刻と対象スコープを確定する
エラーがコンピューターポリシー、ユーザーポリシー、または両方のどれに出たかを記録します。起動直後だけか、VPN接続後も続くか、1台だけか、同じサイトやOUの複数端末かを確認します。イベントビューアーの「Windowsログ」「システム」でGroupPolicyの警告またはエラーを開き、イベントID、エラーコード、DC名、時刻、詳細タブのActivityIDを控えます。
Microsoftのガイダンスでは、ActivityIDで「アプリケーションとサービスログ」「Microsoft」「Windows」「GroupPolicy」「Operational」を絞り、同じ処理インスタンスの開始から終了まで追う方法が案内されています。イベント1129はDCへのネットワーク接続不足で記録されますが、原因はDNS、LDAP遮断、起動時の回線遅延、資格情報状態など複数あります。メッセージ文だけで決め打ちしません。
gpresultで適用済みと拒否理由を保存する
管理者のコマンドプロンプトで、まずgpresult /rを実行し、適用済みGPOと拒否されたGPOを確認します。詳細をHTMLへ保存する場合は、機密でないローカル作業フォルダーを用意してgpresult /h gp.htmlを使います。ユーザー名、グループ、OU、GPO名など組織情報を含むため、公開共有や個人クラウドへアップロードしません。
GPOが一覧にない場合はリンク、セキュリティフィルター、継承、WMIフィルター、ユーザー/コンピューター構成の対象違いを確認します。一覧にあり設定だけ失敗する場合はクライアント側拡張やSYSVOL読み取りを疑います。gpresultは結果セットの確認でありGPOを変更しません。先にこの証跡を取ることで、更新後に状態が変わっても比較できます。
IP構成とDNSサーバーを最優先で確認する
ipconfig /allでIPv4/IPv6、サブネット、デフォルトゲートウェイ、接続固有DNSサフィックス、DHCP、DNSサーバーを記録します。AD参加端末は、対象ドメインのAD統合DNSゾーンとSRVレコードを解決できる社内DNSを使う必要があります。インターネットが見えることやDCのIPへPingが返ることは、AD用DNSが正しい証明ではありません。
端末の優先DNSにパブリックDNS、家庭用ルーター、VPN接続前のDNSだけが入っている場合、DCを名前で検出できません。ただし現場判断でアドレスを上書きせず、DHCP、VPN、NRPT、条件付きフォワーダー、サイト設計の管理者へ確認します。nslookupまたはResolve-DnsNameでドメイン名とDCのFQDNが想定IPへ解決されるかを読み取ります。
SRVレコードとDCロケーターを確認する
Active DirectoryはDNS SRVレコードでLDAPやKerberosを提供するDCを公開します。対象ドメインがexample.comなら、nslookup -type=SRV _ldap._tcp.dc._msdcs.example.comのように照会し、1台以上のDC名が返るか確認します。返ったDC名を通常のA/AAAA照会でも解決し、誤った旧IPや廃止DCが残っていないかを確認します。
MicrosoftのDCロケーターは、NetlogonがDNSのSRV/Aレコードを照会し、応答可能なDCを選択してキャッシュすると説明しています。クライアントではnltest /dsgetdc:example.comで検出結果を確認できます。別サイトのDCしか返らない場合は、Active Directory Sites and Servicesのサブネット定義やDNS登録をAD管理者が調べます。DNSキャッシュ削除は証跡取得後に必要性を判断します。
DC名への到達性をサービス単位で調べる
PingはICMPだけの確認です。名前解決後、Test-NetConnection dc01.example.com -Port 389でLDAPのTCP接続を確認し、環境に応じてKerberos 88、SMB 445、RPC Endpoint Mapper 135なども管理者の許可範囲で調べます。DNS 53やKerberosにはUDPも使われ、Test-NetConnectionのPort確認はTCP中心なので、単一結果を全通信の保証にしません。
Microsoftの公式ポート一覧では、ADはDNS、Kerberos、LDAP、SMB、RPCと動的RPCポートなどを利用し、シナリオごとに必要範囲が異なります。端末のWindows Firewall、拠点間FW、VPN、ゼロトラスト製品、802.1X、NACのログを時刻で照合します。切り分け目的でファイアウォールを全面無効にせず、遮断された宛先・ポート・方向を特定して承認済みルールを修正します。
SYSVOLとNETLOGONを読み取れるか確認する
GPOのテンプレートはSYSVOLから取得されるため、エクスプローラーまたは読み取りコマンドで\\example.com\SYSVOLと\\example.com\NETLOGONへ到達できるか確認します。資格情報をURLやスクリプトへ埋め込まず、現在のドメイン資格情報で読み取ります。パスが開かない場合はDNS、SMB 445、Kerberos/NTLM、DFS名前空間、DC側共有のどこで失敗したかを分けます。
特定DCのSYSVOLだけ失敗し、別DCでは成功するなら、クライアントを何度も更新するよりAD管理者がDFSR、SYSVOL共有、DCレプリケーション、DNS登録を確認します。共有のアクセス許可を「Everyoneフルコントロール」へ広げたり、GPOファイルを端末へ手作業コピーしたりしません。GPOのAD部分とSYSVOL部分の版ずれもGPMCの状態とDCログで調べます。
時刻と安全なチャネルを読み取り専用で調べる
Kerberos認証は時刻差の影響を受けます。w32tm /query /statusとw32tm /query /sourceで同期元、最終同期、ずれを確認し、端末の日時、タイムゾーン、仮想基盤の時刻同期も記録します。原因を確認せず手動で時刻を大きく変更すると監査ログや認証へ影響するため、Windows Time階層とPDC Emulatorの状態を管理者が修正します。
ドメインメンバーでは管理者PowerShellのTest-ComputerSecureChannel -Verboseが、コンピューターとドメインの信頼チャネルを確認します。MicrosoftはこのコマンドをDCで使うと偽のエラーを返す場合があると説明しているため、DCでは使いません。-Repairは状態を変更し資格情報も必要なので、読み取り確認でfalseが出ても直ちに実行せず、コンピューターアカウントと複製を確認します。
起動直後・VPN接続時だけ失敗する場合を切り分ける
起動時のみ1129やNetlogon関連エラーが出て、ネットワーク確立後のバックグラウンド更新は成功するなら、NIC初期化、DHCP、スイッチのリンクネゴシエーション、802.1X、NAC、デバイストンネルVPNがDC検出より遅い可能性があります。Microsoftの5719/1129資料も、Netlogon開始時にネットワークが未準備となる競合を挙げています。
この場合も、ネットワーク待機時間のレジストリ値を全端末へ推測で追加しません。現行ドライバー、スイッチ設定、Always On VPNのデバイストンネル、コンピューター認証、起動時ログを確認します。「コンピューターの起動およびログオンで常にネットワークを待つ」などのポリシーはログオン時間へ影響するため、限定端末で必要性と効果を測り、変更前値を残します。
原因を直してから最小範囲で更新する
DNS、VPN、ポート、時刻、信頼チャネル、DC側障害の原因を修正した後、通常のバックグラウンド更新を待つか、影響の少ない対象でgpupdate /target:userまたはgpupdate /target:computerを使います。/forceは変更分だけでなく全ポリシーを再適用する指定です。スペルはgpupdate /forceであり、元記事にある/foreceは誤りです。
ソフトウェア配布、フォルダーリダイレクト、スクリプト、証明書、更新関連など他のクライアント側拡張へ影響するため、本番サーバーで無条件に/forceを繰り返しません。MicrosoftはWindows Server 2016/2019で/forceが保留中の更新を予期せず進める事例も案内しています。再ログオンや再起動が必要な設定は利用者と調整し、業務時間外の変更手順に従います。
成功イベントと再発有無まで確認する
更新後にコマンドの成功表示だけで終えず、新しいActivityIDのGroupPolicy Operationalログ、システムログ、gpresultを再取得します。対象GPOが適用済みとなり、設定が実際に反映され、1129が繰り返されないことを確認します。起動時問題なら再起動テスト、VPN問題なら切断・再接続テストを承認済み検証端末で行います。
複数端末や特定サイトで再発する場合は、DCごとのDNS、SYSVOL、LDAP応答、ADレプリケーション、サイト/サブネット、拠点FWをAD管理者へ引き継ぎます。端末をドメインから離脱・再参加させるのは最終手段で、BitLocker回復情報、ローカル管理アクセス、ユーザープロファイル、証明書、管理ツールへの影響を計画せず実施しません。診断値、変更、承認者、結果、戻し手順を残します。
確認チェックリスト
- エラー時刻、ユーザー/コンピュータースコープ、イベントID、ActivityIDを記録した
- gpresultで適用・拒否GPOを変更前に保存した
- IP構成とAD用DNSサーバー、DNSサフィックスを確認した
- SRVレコードとDCロケーターでDCをFQDNから検出できた
- LDAP、Kerberos、SMB、RPCなど必要サービスの到達性を確認した
- SYSVOL/NETLOGON、時刻、ドメインメンバーの安全なチャネルを確認した
- DNS公開化、IPv6/FW全面無効、無計画なドメイン再参加を行っていない
- 原因修正後に最小対象で更新し、成功イベントと再発有無を確認した
公式情報・参考資料
- Microsoft Learn：グループポリシー適用のトラブルシューティングガイダンス
- Microsoft Learn：WindowsとWindows Serverのドメインコントローラーロケーター
- Microsoft Learn：ドメインコントローラーのDNS SRVレコードを確認する
- Microsoft Learn：Active Directoryドメインと信頼関係のファイアウォール構成
- Microsoft Learn：Test-ComputerSecureChannel
- Microsoft Learn：gpupdateコマンド
- Microsoft Learn：Netlogon 5719とGroup Policy 1129の原因と対処
コメント