GPO Fails to Apply — Broken Netlogon Secure Channel (Machine Account Password Desync) on Windows 10/11

Indicators

• gpupdate /force returns a network connectivity error or 'Access is denied'
• Test-ComputerSecureChannel (PowerShell) returns False on the affected workstation
• New computer or user Group Policy Objects fail to apply; existing cached policy remains in force
• Security baselines, drive maps, and software deployment profiles stop updating on the workstation
• Device drops out of compliance in Intune/SCCM due to stale or unapplied Group Policy
• Netlogon event ID 5719 ('No Domain Controller is available') or event ID 3210 logged in System event log on the workstation
• netlogon.log at C:\Windows\debug\netlogon.log contains authentication or secure channel failure entries

Likely causes

• Machine account password desync: the workstation's locally stored machine account password no longer matches the password held in Active Directory, causing the DC to reject the workstation's Netlogon authentication
• Workstation was offline (powered off, VPN disconnected, or isolated) during the scheduled 30-day machine account password renewal cycle, causing password drift that persists on reconnection

Diagnostic steps

1. Run gpupdate /force on the affected workstation and document the exact error returned.
   Confirms GPO application is actively failing and characterises the error type (network connectivity vs access denied) to distinguish a secure channel issue from other GPO failure modes such as WMI filter mismatch or link scope.
2. Open an elevated PowerShell session and run: Test-ComputerSecureChannel
   Directly tests whether the Netlogon secure channel to the AD DC is intact. A return value of False confirms the secure channel is broken and identifies this as the root cause of GPO failure.
3. Verify network connectivity to the Domain Controller: Test-NetConnection -ComputerName <DCName> -Port 445 and ping <DCName>
   Rules out a pure network connectivity failure before proceeding with secure channel remediation — if port 445 is unreachable, the workstation cannot contact the DC and no secure channel reset will succeed.
4. Review C:\Windows\debug\netlogon.log on the workstation for authentication failure entries referencing the domain controller name and failure reason.
   Provides additional detail about which DC is being contacted and the specific Netlogon failure mode, and helps distinguish a localised machine password mismatch from a broader Kerberos or DNS resolution issue.
5. Check the System and Application event logs on the workstation for Netlogon event IDs 5719 and 3210, and Group Policy event IDs in the Microsoft-Windows-GroupPolicy/Operational log, filtered to the time window of reported GPO failures.
   Establishes corroborating evidence and timeline for the secure channel / domain trust failure, and may surface secondary causes (e.g. DNS resolution failure preventing DC contact).

Resolution path

• Step 1 — Attempt non-destructive secure channel reset on the affected workstation from an elevated PowerShell session (supply domain admin credentials when prompted): Reset-ComputerSecureChannel -Credential (Get-Credential)
• Step 2 — Immediately after the reset, confirm success: run Test-ComputerSecureChannel — it must return True. Then run gpupdate /force and verify it completes without errors. Run gpresult /r to confirm current GPOs are listed with recent timestamps.
• Step 3 — If Reset-ComputerSecureChannel fails or Test-ComputerSecureChannel still returns False, perform a full domain rejoin: (a) Remove the computer from the domain by joining it to a workgroup (System Properties → Change → Workgroup) and reboot. (b) Rejoin the domain and reboot again. Note: rejoining requires local admin credentials during workgroup phase, and may require re-mapping of user profiles or drive mappings post-rejoin.
• Step 4 — If domain rejoin also fails, escalate to L3 to manually reset the computer account password in Active Directory using Set-ADAccountPassword or netdom resetpwd /server:<DC> /ud:<domain\admin> /pd:*, then retry Reset-ComputerSecureChannel on the workstation.

Prevention

• Monitor for Netlogon event ID 5719 and 3210 in the System event log across the workstation fleet using SIEM or monitoring tools; alert on any workstation logging these events so secure channel failures are caught before they cause GPO compliance drift.
• Implement scheduled automated secure channel validation using a script running Test-ComputerSecureChannel across all managed endpoints, with alerting when any workstation returns False — run weekly or after extended offline periods.
• Ensure domain-joined workstations (especially remote/laptop endpoints) connect to the corporate network or VPN at least once every 30 days to complete machine account password renewal before the prior password expires.
• Verify that machine account password synchronisation is functioning and DCs are reachable during scheduled password roll cycles; consider extending the machine account password maximum age (MaximumPasswordAge in Default Domain Policy) only as a temporary measure for chronic offline endpoints, and document the risk.

Tools

• Test-ComputerSecureChannel (PowerShell cmdlet — tests whether the workstation secure channel to AD is intact; returns True/False)
• Reset-ComputerSecureChannel (PowerShell cmdlet — resets the broken secure channel using supplied domain admin credentials)
• gpupdate /force (cmd — forces immediate Group Policy refresh; reveals GPO application errors)
• gpresult /r or gpresult /h report.html (cmd — displays Resultant Set of Policy for post-fix verification)
• Test-NetConnection (PowerShell cmdlet — verifies TCP connectivity to Domain Controller on port 445)
• Event Viewer / Get-WinEvent (System log, Microsoft-Windows-GroupPolicy/Operational log)
• netlogon.log at C:\Windows\debug\netlogon.log (Netlogon diagnostic log)

References

• Microsoft Docs — Test-ComputerSecureChannel
• Microsoft Docs — Reset-ComputerSecureChannel
• Microsoft Docs — Troubleshoot Group Policy