NetlogonイベントID 5719は、Windowsがドメインコントローラー（DC）とのセキュアセッションを確立できなかった場合などに記録されます。イベント番号だけで「ドメイン参加が壊れた」と判断しないことが重要です。起動直後の一時的なネットワーク準備遅延と、継続する認証障害では対処が異なります。
まず発生時刻、イベント本文、影響範囲を確認し、ネットワーク・DNS・DCの状態を順に調べます。初期対応としてDCを再起動したり、端末をドメインから離脱・再参加させたりする方法は勧めません。本記事はActive Directoryドメイン環境向けで、Entra ID参加だけのPCやワークグループの問題とは区別してください。
最初の判断：起動時だけか、業務中も続くか
起動直後に1回だけで、その後正常：ネットワーク準備前にNetlogonが動いた可能性があります。認証、共有フォルダー、グループポリシーなどが正常に利用できるか確認します。継続して発生しサインインや共有が失敗：DNS、VPN・経路、DCのサービス、セキュアチャネルなどの調査が必要です。
Microsoftは、ネットワーク準備前の起動タイミングによる5719について、その後問題なくドメインログオンできる場合は無視できると説明しています。ただし、キャッシュされた資格情報でデスクトップに入れただけでは、DCとの通信が正常とは限りません。起動スクリプトやGPOが失敗しているなら、無害として扱わないでください。
1．イベント本文と関連ログを保存する
イベントビューアーの「Windowsログ」→「システム」で、ソースがNETLOGONの5719を開きます。イベントIDだけでなく、対象ドメイン、状態コード、説明全文、発生日時、起動との前後関係を記録します。調査前にログを消さないでください。
近い時刻のネットワークアダプター、DHCP、DNS、GroupPolicyのイベントも照合します。特にグループポリシーの1129などが併発し、起動時処理が実行されていない場合は、ネットワーク接続の遅れが実害を出している可能性があります。
管理者がPowerShellで直近の対象イベントを確認する例です。必要な権限がない場合は担当者へ依頼します。
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5719} -MaxEvents 10 |
Select-Object TimeCreated, Id, Messageイベント本文や診断出力には内部ドメイン名、端末名、IPアドレスなどが含まれます。公開の掲示板へそのまま貼らず、組織の許可された窓口へ必要な範囲だけ共有します。
2．IP・DNS・VPNの状態を確認する
接続元端末で次のコマンドを実行し、IPアドレス、DNSサーバー、DNSサフィックス、使用中のアダプターを確認します。ネットが見られることと、社内DCに到達できることは別です。
ipconfig /allDHCPでアドレスが取得できているか、不要なアダプターやVPNがDNS・経路に影響していないかを確認します。ADの名前解決ができる組織指定のDNSを利用しているかが重要で、トラブル対策として端末のDNSを公開DNSへ勝手に変更しないでください。
在宅勤務では、VPNがつながる前のログオンと、VPN接続後の動作を分けて確認します。起動前・サインイン前のDC接続が必要な構成は、利用者ではなくネットワーク管理者が設計を確認します。
3．DNSのSRVレコードでDCを探せるか確認する
Active DirectoryはDNSのサービスレコードを使ってDCを見つけます。次の ad.example.com は架空の例なので、実際のAD DNSドメイン名に置き換えます。メールのドメインや短いNetBIOS名と同じとは限りません。
nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.com回答にDCのホスト名が返るか確認し、その名前のIPアドレスも引けるか調べます。タイムアウト、存在しないという回答、想定外のDNSサーバーへの問い合わせなどを区別します。DCのホスト名が引けても、必要なサービスへ接続できるとは限りません。
SRVレコードが不足している、DC名が古いIPへ解決されるなどの場合は、DNS／AD管理者が登録状態と複製を調査します。クライアントのhostsファイルへDCのIPを足すだけでは、SRVレコードによる検出を代替できません。
4．端末固有か、複数台・同じ拠点の障害かを比べる
同じ拠点の複数端末で同時に起きるなら、DNS、DHCP、スイッチ、VPN、認証基盤、DCの障害を優先して確認します。1台だけなら、その端末のNIC、設定変更、VPN、コンピューターアカウントの状態などを調べます。
pingが通るだけでAD認証に必要な通信がすべて正常とは判断できず、pingが拒否されるだけでDC停止とも断定できません。管理者は必要なADサービスの通信、名前解決、DCのログを合わせて確認します。ファイアウォールやIPsecを全面的に無効化する方法は避けてください。
5．セキュアチャネル確認はドメインメンバーに限定する
ネットワークとDNSが正常なのに端末固有の認証問題が続く場合、管理者はドメインメンバー端末で次のPowerShellを使って状態を確認できます。この例には修復オプションを付けていません。
Test-ComputerSecureChannel -Verboseこのコマンドはドメインメンバー向けです。DCで実行すると誤ったエラーを返すことがあるため、DCの健全性確認には使いません。Falseだけでパスワード不整合と断定せず、通信・DNS・サービスの問題も確認します。
-Repair、コンピューターアカウントのリセット、ドメイン再参加は状態を変更する別の操作です。管理者が原因、権限、ローカルでのサインイン手段、BitLocker回復情報や業務影響を確認したうえで計画します。イベントを消す目的で一律に実施しません。
起動時だけ発生する場合の対処
Microsoftの資料では、Netlogon開始よりネットワーク準備が遅れる要因として、NIC・スイッチの初期化、802.1Xなどのネットワーク認証、DHCP応答の遅れなどが挙げられています。イベント時刻とリンク確立・IP取得・認証完了時刻を比較して原因を絞ります。
対応するNICドライバーの更新、スイッチ側の構成確認、GPOのネットワーク待機などは、原因に合う場合に管理者が検討します。PortFastのようなスイッチ設定は誤用するとネットワークへ影響するため、端末利用者向けの一律手順にはしません。
NetlogonやGPOの待機時間に関するレジストリ値を長くする方法も、すべての5719に有効ではありません。起動遅延を増やすだけになる場合があるため、適用OS・発生条件・必要な待機時間・復元方法を確認します。古いOS向けの値をそのまま現在の端末へコピーしないでください。
DC側を調べるときに避けたいこと
DCのNetlogonサービス停止、DNS・ディレクトリサービスの障害、SYSVOL関連の問題なども認証に影響します。DC上のエラーと複数端末の影響を照合し、AD管理者が正式な手順で調査します。
「とりあえずDCを再起動」は他の利用者の認証や業務にも影響します。保守計画、冗長構成、依存サービスを確認せず実行しません。再起動で一時的に変化しても、原因が解消された証拠とは限りません。
再発防止と管理者へ渡すチェックリスト
再発防止は、発生頻度と業務影響を監視し、DNS・DHCP・VPN・ネットワーク認証の変更と関連付けることから始めます。更新は正規の経路と保守計画に従い、適用前後の結果を記録します。定期更新だけで必ず予防できるとは限りません。
問い合わせ時は、①OSとビルド、②ドメインメンバーかDCか、③イベント本文と時刻、④起動時限定か継続か、⑤影響する端末数と拠点、⑥DNS・IP・VPNの状況、⑦GPOや共有の実害、⑧直前の変更を伝えます。
まとめ・公式情報
5719は原因を示す単独の診断結果ではありません。起動時の一時的なDC検出遅延か、継続的な通信・認証障害かを分け、ログ、DNS、影響範囲を確認してから対処します。ここに掲載した確認コマンドは、実際のドメイン環境で今回検証した結果ではありません。
Microsoft：起動時のNetlogon 5719／GroupPolicy 1129／DNS SRVレコードの確認／Test-ComputerSecureChannelの制限／Netlogonサービス起動失敗の調査
コメント