Event ID 5719 is one of the most common Netlogon errors in Active Directory environments. It logs when a domain-joined Windows computer fails to find or authenticate with any domain controller. Per Microsoft, the most frequent cause is network timing at boot: Netlogon starts before the NIC is fully initialized, fails to reach a DC, and logs the event. The secure channel establishes successfully seconds later.
Key takeaways
- Event 5719 means Netlogon couldn't establish a secure channel with any domain controller.
- At boot, it's usually transient: the network isn't ready before Netlogon tries to connect.
- Persistent 5719 after boot signals DNS, firewall, or broken computer trust issues.
- Fix broken trust with Test-ComputerSecureChannel -Repair or domain rejoin.
- Key ports: TCP 88 (Kerberos), 389 (LDAP), 445 (SMB), 636 (LDAPS).
Quick explanation
In simple terms
Event 5719 means a domain-joined computer couldn't reach a domain controller to verify its identity. It's like trying to badge into a building but the card reader can't reach the security server.
Technical definition
Event 5719 (Source: Netlogon) indicates that the Netlogon secure channel establishment with a domain controller failed. The computer could not locate a DC via DNS SRV records, could not connect on required ports, or the machine account authentication failed.
Analogy
Think of it like a phone trying to connect to a cell tower. At startup, the phone (computer) looks for towers (domain controllers). If it can't find one in time (Event 5719), it keeps trying. Usually it connects seconds later. But if the tower is down or the SIM card (computer account) is invalid, you have a real problem.
Definition
Event ID 5719 is a Netlogon error that logs when a domain-joined Windows computer cannot establish a secure session with any domain controller, typically due to network timing at boot, DNS misconfiguration, or a broken computer account trust.
Event ID 5719 is a System event log entry with source Netlogon, logged when a domain-joined Windows computer fails to establish a secure channel with any available domain controller. Per Microsoft, the error message typically reads: 'This computer was not able to set up a secure session with a domain controller in domain [DOMAIN] due to the following: [reason].'
The secure channel is the trust relationship between a domain member and a DC, authenticated using the computer account password stored in AD. This password is automatically rotated every 30 days. If the local and AD copies go out of sync (e.g., after restoring a VM snapshot), the secure channel breaks.
Why it matters
Core concepts
Secure Channel
An authenticated connection between a domain-joined computer and a domain controller, used for machine authentication and pass-through user logon.
Every domain-joined computer maintains a secure channel with a DC. The channel uses the computer account password (rotated automatically every 30 days by default). If the password gets out of sync, the secure channel breaks and Event 5719 or 5722 is logged.
Example
A member server uses its secure channel to forward user logon requests to the DC for Kerberos ticket validation.
Why it matters — A broken secure channel prevents the computer from authenticating users, applying Group Policy, and accessing domain resources.
Netlogon Service
The Windows service responsible for maintaining the secure channel between domain members and domain controllers.
Netlogon starts early in the boot process. It uses DNS SRV records to locate a DC, then authenticates using the computer account password. If the network stack isn't ready or DNS fails, Netlogon can't find a DC, and Event 5719 is logged.
Example
On boot, the Netlogon service queries DNS for _ldap._tcp.dc._msdcs.contoso.com to find a DC.
Why it matters — Netlogon failures prevent domain authentication. The service is also the target of the Zerologon vulnerability (CVE-2020-1472).
How it works
Netlogon service starts at boot
When a domain-joined Windows machine boots, the Netlogon service starts early in the boot sequence. It immediately tries to locate a domain controller.
Boot → Netlogon starts
DNS lookup for domain controllers
Netlogon queries DNS for SRV records (_ldap._tcp.dc._msdcs.domain.com) to find available DCs. If DNS is unreachable or SRV records are missing, the lookup fails.
Netlogon → DNS SRV query
Secure channel authentication
Netlogon connects to the DC and authenticates using the computer account password stored locally. If the password matches the one in AD, the secure channel is established.
Client → DC secure channel
Failure triggers Event 5719
If any step fails (DNS unreachable, DC unreachable, password mismatch), Netlogon logs Event 5719 in the System event log with the domain name and error details.
Failure → Event 5719
Use cases
Boot timing on wireless/VPN devices
IT adminsA laptop logs Event 5719 at boot on a wireless network. The secure channel establishes seconds later when Wi-Fi connects.
Benefit — Reduces unnecessary troubleshooting.
VM snapshot restore breaks trust
IT adminsA VM restored from a 3-month-old snapshot can't authenticate because the computer account password has changed in AD.
Benefit — Identifies the need for secure channel repair or domain rejoin.
Site-wide DC connectivity failure
IT adminsAll machines in a branch office log Event 5719 because the local DC is offline and WAN DNS can't resolve the headquarters DCs.
Benefit — Reveals infrastructure-wide DNS or DC availability issues.
Benefits
Signals domain connectivity issues early
Event 5719 alerts administrators to machines that can't communicate with domain controllers, which affects user logon, Group Policy application, and resource access.
Helps identify DNS and network problems
Persistent 5719 events often reveal DNS misconfigurations, network segmentation problems, or broken computer account trust relationships that would otherwise go unnoticed.
Limitations
Doesn't distinguish transient from persistent failures
MediumEvent 5719 doesn't tell you whether the failure is a transient boot issue or a critical trust breakdown. You need additional context (other events, timing, user impact) to determine severity.
Workaround — Check if Event 5719 recurs after boot. Correlate with Event 5722 (password mismatch) and Event 1054 (GPO failure) for more context.
Common false positives on slow-initializing networks
LowOn machines with slow network initialization (wireless, VPN, USB Ethernet adapters), Event 5719 appears at every boot even though the system functions normally.
Workaround — Per Microsoft, configure the Netlogon service to delay startup by creating a dependency on the NlaSvc (Network Location Awareness) service.
Architecture
Event 5719 sits in the Netlogon authentication flow between a domain-joined computer and Active Directory. The secure channel is the trust relationship that allows the computer to authenticate users and access domain resources.
Netlogon service
Manages the secure channel between domain members and domain controllers for authentication.
The Netlogon service on a member server failing to reach DC1.contoso.com at boot.
Domain Controller (DC)
Authenticates machines and users, hosts AD DS, and responds to secure channel requests.
DC1.contoso.com handling authentication requests on port 389 (LDAP) and 88 (Kerberos).
DNS SRV records
Allow domain members to locate domain controllers dynamically.
_ldap._tcp.dc._msdcs.contoso.com SRV record pointing to DC1.
Data flow
At boot, the Netlogon service queries DNS for DC locator SRV records (_ldap._tcp.dc._msdcs.domain), connects to a DC over TCP 389/636 (LDAP) and TCP 88 (Kerberos), and establishes a secure channel using the computer account password. If this fails, Event 5719 is logged.
Architecture limitations
Examples
Transient boot timing (most common)
A domain-joined laptop logs Event 5719 every morning at boot but functions normally after login.
This is the most common scenario. Per Microsoft, Netlogon starts before the network stack is fully initialized, especially on machines with slow NIC drivers, wireless connections, or VPN-dependent connectivity. The secure channel establishes successfully seconds later.
Broken secure channel trust
A VM restored from a snapshot taken 3 months ago logs persistent Event 5719 and can't authenticate users.
The computer account password in AD no longer matches the locally stored password. This happens when a VM is restored from an old snapshot, the machine was offline for extended periods, or the computer account was reset in AD.
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) or by rejoining the domain.Comparisons
Event 5719 vs. Event 1054
Event 5719 vs. Event 5722
Myths, corrected
Myth
Event 5719 always means the computer is broken or needs to be rejoined to the domain
Correction
Per Microsoft, Event 5719 at boot is usually a timing issue. The computer connects to a DC seconds later. Only persistent 5719 events after the system is fully booted indicate a real problem.
Why it happens: IT admins see the event and assume the worst. Boot-time 5719 is extremely common on laptops and VMs with slow network initialization.
Myth
Increasing the Netlogon timeout fixes Event 5719
Correction
Adjusting the NegativeCachePeriod or ExpectedDialupDelay registry values helps in some cases but doesn't fix the root cause. If DNS is wrong or the trust is broken, timeout changes don't help.
Why it happens: Blog posts recommend timeout tuning as a universal fix, but it only addresses the boot timing variant.
Practical implications
For admins
Monitor for persistent Event 5719 across multiple machines, which signals a site-wide DC connectivity issue. Boot-time 5719 on individual machines is usually benign.
For MSPs
Event 5719 is one of the most common support tickets in AD environments. Educate clients about the boot-timing variant to reduce unnecessary escalations.
For business
Persistent 5719 prevents user logon, Group Policy, and domain resource access. Business impact depends on whether it's transient or persistent.
For security
Persistent Netlogon failures can indicate network attacks (DC spoofing, DNS poisoning) or compromised infrastructure. Correlate with security event logs.
Operational impact
A machine with persistent 5719 can't authenticate domain users, apply Group Policy, or access network shares.
Decision guide
Use when
- Event 5719 persists after the system is fully booted.
- Multiple domain-joined machines log 5719 simultaneously.
- Users report 'no logon servers available' errors.
Avoid when
- Event 5719 only appears once at boot and the system functions normally afterward (transient, non-actionable).
- You're troubleshooting a user authentication issue (check Kerberos events instead).
Requirements
- Access to Event Viewer on the affected machine.
- DNS and network connectivity to domain controllers.
- Domain admin or equivalent for secure channel repair.
Alternatives
- Check Event 5722 for specific trust failures
- Use dcdiag /test:NetLogons for DC-side verification
- Review Group Policy event logs for related failures
Related terms
Netlogon
The Windows service that manages the secure channel between domain members and domain controllers.
Secure Channel
The authenticated connection between a domain-joined computer and a DC, using the computer account password.
AD DS
Active Directory Domain Services, the directory service that domain controllers host.
Frequently asked questions
What does Event ID 5719 mean?
It means the Netlogon service on a domain-joined computer failed to establish a secure session with any domain controller. The computer can't authenticate against Active Directory.
Is Event 5719 always a problem?
Usually not. Per Microsoft, Event 5719 at boot is common when the network isn't ready before Netlogon tries to contact a DC. If the system works normally after login, the event is transient and non-actionable.
How do I fix a broken secure channel?
Run Test-ComputerSecureChannel -Repair -Credential (Get-Credential) from an elevated PowerShell prompt using domain admin credentials. If this fails, disjoin and rejoin the domain.
What causes persistent Event 5719?
DNS misconfiguration (missing SRV records), firewall blocking DC ports (TCP 88, 389, 445, 636), broken computer account trust, network issues at boot, or the computer being in the wrong site/subnet.
How do I diagnose Event 5719?
Use nltest /sc_query:domain.com to check the secure channel status. Use dcdiag /test:NetLogons on the DC side. Check DNS with nslookup -type=srv _ldap._tcp.dc._msdcs.domain.com.
Conclusion
Event ID 5719 logs when the Netlogon service can't establish a secure channel with a domain controller. Per Microsoft, it commonly appears at boot before the network is ready and resolves itself once connectivity is established.
Persistent Event 5719 after boot points to real issues: DNS SRV record misconfiguration, firewall blocking DC ports (TCP 88, 389, 445, 636), or a broken computer account trust. For broken trust, resetting the secure channel with Test-ComputerSecureChannel -Repair or rejoining the domain resolves the issue.
Main takeaway
Review Microsoft's Netlogon troubleshooting documentation and ensure DNS health monitoring is in place for your domain controllers.
-640x640.webp&w=3840&q=75)