Event ID 5719: this computer could not set up a secure session with a DC

Fix it now

Netlogon could not set up a secure session with a domain controller for this domain. One occurrence within a minute of a reboot is usually the network not being ready in time. One that repeats, or that arrives while the machine is running, is name resolution, a blocked port or the machine account password.

nltest /sc_query:contoso.com
nltest /dsgetdc:contoso.com
Test-ComputerSecureChannel -Verbose

1. Check the timestamps before anything else. If every occurrence is within a minute of a start-up and nothing follows it, the channel came up afterwards and there is nothing to fix.
2. If nltest /dsgetdc fails, this is a domain controller location problem rather than a Netlogon one: check the machine’s DNS servers and the domain controller service records before touching the machine account.
3. If the channel is broken rather than absent, repair it in place: Test-ComputerSecureChannel -Repair -Credential *, or nltest /sc_reset:contoso.com. Neither of these needs a rejoin.
4. Check a domain controller’s System log for Event ID 5722 naming this computer. If the timestamp matches the machine account’s pwdLastSet, that 5722 is the routine password change and is not your fault.

On Windows 10, Windows Server 2016 and later, the start-up case is no longer written to the System log as 5719 – the condition is recorded in netlogon.log instead. Enable it with nltest /dbflag:2080ffff and read %windir%\debug\netlogon.log.

If the channel now reports as working and the event stops after a reboot, you are done. The next section covers the version-specific case that produces a harmless 5719 on every service restart.

Why it happens

The Netlogon secure channel is the authenticated connection between a domain member and a domain controller. Group Policy, share access and pass-through authentication all ride on it, which is why 5719 produces such a broad set of symptoms: policy does not apply, shares refuse, and cached credentials carry the user until they do not.

Most occurrences are a race rather than a fault. Microsoft’s documented causes for the start-up case are the network stack not being ready when Netlogon starts, 802.1X or health-check solutions delaying the connection, DHCP taking too long, and the general race between network initialisation, domain controller location and policy processing. If you can sign in to the domain normally, the guidance is that the event can safely be ignored – the computer retries once the network is up.

Two things change how you read it on current builds. First, on Windows 10 and Windows Server 2016 and later the start-up condition is written to netlogon.log rather than logged as 5719. Second, a Windows Server 2025 member server logs 5719 with the error 0xC00000E5, STATUS_INTERNAL_ERROR, every time the Netlogon service restarts while its authenticating domain controller runs Windows Server 2022 or 2019. That one is documented as expected and harmless: the newer member tries a Kerberos-based secure channel call the older domain controller does not support, then falls back to the legacy method and succeeds.

Full reference

Which machine logs what

5722 is not automatically a problem. Microsoft documents that it is logged when a computer updates its machine account password with a domain controller, which happens roughly every 30 days by default. Compare the event’s timestamp with the object’s pwdLastSet and check whether a valid secure channel exists with nltest /server:<computer> /sc_query:<domain> before treating it as a fault.

Reading netlogon.log when there is no 5719

1. Enable logging: nltest /dbflag:2080ffff.
2. Reproduce the condition, or wait for the next start-up.
3. Read %windir%\debug\netlogon.log. Entries such as a session setup that cannot pick a trusted domain controller, or a note that no IP addresses were present so the no-DC event was skipped, are the equivalent of the old 5719.
4. Turn it off again afterwards: nltest /dbflag:0.

The registry values Microsoft names for the start-up race

Repairing the channel without a rejoin

Removing a computer from the domain and adding it back changes its SID history in ways that break profile and permission assumptions, and it is almost never necessary. Test-ComputerSecureChannel -Repair -Credential * and nltest /sc_reset:<domain> both reset the channel in place. If they fail, work out which side holds the newer password before doing anything destructive: if the client is ahead, the fix is on the Active Directory side and no amount of resetting the client will help.

When it is none of the above

• Look for a second computer object with the same name in another OU or domain, which produces 3210 on one machine and confusion everywhere else.
• Check whether the machine has been offline longer than the machine account password history tolerates – a laptop restored from an old image behaves exactly like a password mismatch.
• Confirm the machine is not being pointed at a domain controller in a distant site by a stale site-to-subnet mapping.
• Where the errors coincide with a specific domain controller, test against another one with nltest /sc_query after nltest /dsgetdc:<domain> /force.

Every code this article covers

Confirm the fix worked

1. nltest /sc_query:<domain> reports a working secure channel and names a domain controller.
2. Test-ComputerSecureChannel returns True without the repair switch.
3. A reboot produces no new 5719, or only the documented single 0xC00000E5 entry on a Windows Server 2025 member.
4. gpresult /r shows policy applying from a domain controller rather than falling back.
5. No new 5722 or 3210 events on the domain controllers naming this computer, outside the routine password change.

Questions people ask about this