Helpdesk: "PC-ACC-114 logs NETLOGON event 5719 every morning: 'This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following: There are currently no logon servers available to service the logon request.' Group Policy logged 1129 at the same minute, and the startup script that maps the scanner share didn't run. The user signs in fine with cached credentials. A forum thread says to rejoin the domain, run Test-ComputerSecureChannel -Repair on every PC that logs 5719, and turn on 'Always wait for the network' for the whole domain. Can we do that today?"
Not yet. Event 5719 means Netlogon couldn't find or reach a domain controller at that moment. The reason text and the timing tell you which layer failed. Microsoft's article for this event lists the first cause as "The Netlogon service starts before the network is ready." It also says: "If you can log on to the domain without a problem, you can safely ignore event ID 5719." A rejoin or a secure channel reset changes the computer account. Neither one makes the network adapter come up faster or fixes DNS. Work through it as a chain: the exact reason text, when it fires, and what role the machine has → the events and the Netlogon log around it → was the network ready when Netlogon started (link, DHCP, 802.1X, NAC, driver)? → DNS: can this machine's DNS servers answer the DC locator's SRV queries? → DC locator and the AD site: which DC, from which site, with or without the cache? → the ports between this machine and the DC → the DC side: Netlogon running, not paused, and its records in DNS → the Netlogon service on this machine, and the Windows 11 24H2 "internal error" pattern. Get-WinEvent, the Netlogon debug log, Get-NetAdapter, Get-NetConnectionProfile, ipconfig /all, Resolve-DnsName, nltest /dsgetdc, nltest /dsgetsite, Test-NetConnection, dcdiag, and sc qc netlogon are the sources for that chain. Rejoin a PC whose switch port takes 30 seconds to forward traffic, and it logs the same 5719 on the next boot.
If the machine finds a DC and the secure channel itself is broken (event 3210, nltest /sc_query returning ERROR_ACCESS_DENIED, "the trust relationship between this workstation and the primary domain failed"), read Trust Relationship Between This Workstation and the Primary Domain Failed. It covers the secure channel and machine password repair side, so this post doesn't repeat it. If the 5719 matters because startup Group Policy didn't apply, Group Policy Not Applying covers the GPO side. This post covers "a domain-joined Windows client, member server, or domain controller logs NETLOGON 5719 ('This computer was not able to set up a secure session with a domain controller in domain...'), at boot, at random, or after an upgrade, and you need a read-first path through boot timing, DNS, DC location, sites, ports, the DC side, and the Netlogon service before you rejoin, reset the channel, or change Group Policy wait settings."
TL;DR
- 5719 at boot with a normal sign-in is often harmless. Microsoft: "If you can log on to the domain without a problem, you can safely ignore event ID 5719." It matters when startup Group Policy, startup scripts, or sign-in also fail.
- Read the reason text. "There are currently no logon servers available" points at finding a DC. "An internal error occurred" on Windows 11 24H2 has its own pattern (Step 8). An access-denied reason points at the secure channel (the trust relationship post). These pairings are our reading.
- Boot timing is Microsoft's first cause. "Some network adapters and switches have link arbitration and MAC address uniqueness checks that take longer to complete than the wait time that is set for Netlogon to detect network connectivity." Microsoft's first fix: a current NIC driver, or "enable the PortFast option on the network switches."
- On Windows 10 and later, the boot race may not log 5719 at all. Microsoft: "In Windows 10 and later versions, event 5719 is no longer logged in this situation." On a Windows 11 PC, a 5719 at every boot deserves a look at the reason text before you blame timing (our reading).
- Discovery is DNS plus a UDP LDAP ping. Microsoft: "UDP/389: This port is required to discover AD services." Check DNS and that port before you touch the computer account.
-
nltest /sc_verifyisn't a read. Microsoft: if the secure channel doesn't work, "this parameter removes the existing channel, and then builds a new one."
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Reason text, timing, role, and OS version written down | "5719 again" with nothing else |
| 2. Events and Netlogon log | 5719 lined up against boot time, 1129, and the Netlogon log | 5719s nobody compared with the boot time |
| 3. Network ready at boot | Link, IP address, and domain network profile up before Netlogon gives up | 5719 and 1129 at every boot, fine a minute later |
| 4. DNS | Every DNS server the client uses can answer the _msdcs SRV queries |
SRV lookups fail, or work on one DNS server only |
| 5. DC locator and site |
nltest /dsgetdc /force returns a DC in the right site |
Wrong site, no site, or a DC across the WAN |
| 6. Ports | UDP 389 and 53, plus Kerberos, LDAP, and RPC to the DC | DNS works, the DC never answers |
| 7. The DC side | Netlogon running and not paused on the DCs; SRV records registered | Every client in a site logs 5719 at once |
| 8. Netlogon on this machine | Netlogon and its dependencies start; OS build current | Service Control Manager 7001; "An internal error occurred" on 24H2 |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Rejoined, reset, still logging 5719 |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| The reason text after "due to the following:" | Each reason points at a different layer (table below) |
| When it fires | At every boot, after resume or a network change, at random during the day, or after the Netlogon service restarts |
| What else failed | Sign-in, startup Group Policy (1129), startup scripts, drive maps, or nothing |
| Role | Client, member server, or domain controller. A DC sets up its secure session with the PDC emulator (Step 7) |
| Wired, Wi-Fi, or VPN | 802.1X, NAC, and VPN timing each delay the first DC contact (Step 3) |
| OS version and build | The Windows 11 24H2 "internal error" pattern (Step 8) |
| What changed? | New switch or switch config, NIC driver, DHCP scope, DNS servers, a new subnet, an OS upgrade, a DC retired |
Then branch on the reason text and the timing:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| "There are currently no logon servers available to service the logon request." at boot only, sign-in fine | Netlogon looked for a DC before the network was ready | Steps 2, 3 |
| The same text at random times during the day | DNS, the DC locator, ports, or a DC that stopped answering | Steps 4-7 |
| "We can't sign you in with this credential because your domain isn't available." | Microsoft's sample of this text is for DCs whose Netlogon service is stopped. Read it as no DC answered | Steps 5-7 |
| "An internal error occurred." on Windows 11 24H2 or later, even after restarting Netlogon | Not timing. The Microsoft Q&A pattern in Step 8 | Step 8 |
| An access-denied reason, or event 3210 next to it | The DC was found. The secure channel is the problem | The trust relationship post |
| Only on Wi-Fi or only on VPN | 802.1X, NAC, or a tunnel that comes up after Netlogon looked | Step 3 |
| Every machine in one site at once | A DC, a site, DNS, or a firewall change, not the clients | Steps 5-7 |
| Logged on a domain controller | Its secure session to the PDC emulator, or its own DNS | Step 7 |
Step 2: Read the events and the Netlogon log (read-only)
Start with the System log. Line the 5719s up against the last boot, and read the other events in the same minute:
# Read-only. NETLOGON 5719s in the last 7 days, with the reason text
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'NETLOGON'
Id = 5719
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Message | Format-List
# Read-only. When did this boot start? (our helper)
(Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
# Read-only. Group Policy 1129s and Service Control Manager start failures in the same window
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-GroupPolicy'; Id = 1129 } -MaxEvents 10 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Service Control Manager'; Id = 7000, 7001, 7003 } -MaxEvents 10 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message
The 1129 text Microsoft documents: "The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition." A 5719 and a 1129 within a minute or two of boot, then a clean background refresh later, is the boot-timing pattern (our reading).
One Microsoft detail changes how you read a Windows 10 or 11 machine. In the boot-timing scenario its KB describes: "In Windows 10 and later versions, event 5719 is no longer logged in this situation." The evidence moves to the Netlogon log and to "events by components, depending on the Domain Controller connectivity (such as Group Policy)." So a modern client can have the boot race with no 5719 at all, and a modern client with a 5719 at every boot may have something else (our reading).
When the events don't settle it, turn on the Netlogon debug log for one or two boots. This is a diagnostic change, not a fix. Microsoft's commands:
Nltest /DBFlag:2080FFFF
Microsoft: "It's typically unnecessary to stop and restart the Netlogon service for Windows Server 2012 R2 or later to enable Netlogon logging." The log is %windir%\debug\netlogon.log, and by default it rolls to Netlogon.bak at 20 MB. Reboot once, then read it:
# Read-only. The discovery and session-setup lines from Microsoft's samples (pattern is ours)
Select-String -Path "$env:windir\debug\netlogon.log" -Pattern 'NlDiscoverDc|cannot pick trusted DC|No IP addresses present|Winsock Addrs|Transport Added|Eventlog: 5719' |
Select-Object -Last 40
What Microsoft's sample lines mean:
| Line (from Microsoft's KB samples) | Read it as (our reading unless noted) |
|---|---|
NlSessionSetup: Session setup: cannot pick trusted DC |
Netlogon tried to set up its session and had no DC to use |
No IP addresses present, skipping No DC event log |
No IP address yet. On Windows 10 and later, this line takes the place of the 5719 (Microsoft) |
Winsock Addrs: 10.1.1.80 (1) List used to be empty. |
The address arrived after Netlogon started. Compare its time with the first failure |
NlDiscoverDc: Cannot find DC. |
Discovery failed. Steps 3-6 decide why |
Transport Added (10.0.64.232) |
Microsoft's sample annotates this line: "Getting a proper IP address takes >15 seconds." |
Turn it off when you're done: Nltest /DBFlag:0x0. Microsoft also warns against enabling Netlogon logging "in policies that apply to all systems, such as the Default Domain Policy."
For the Group Policy side, Microsoft's troubleshooting guide turns on the Group Policy Service debug log with a GPSvcDebugLevel DWORD of 30002 (hex) under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics, written to %windir%\debug\usermode\gpsvc.log ("If the usermode folder doesn't exist, create it under %windir%\debug."). In Microsoft's 5719 KB sample, that log shows the wait it calculated (Taking min of 776 and 30000), then NlaGetIntranetCapability returned Not Ready error, then There is no connectivity. That sequence is the network missing the startup window.
Step 3: Was the network ready when Netlogon started? (read-only)
Microsoft's causes for the boot-time 5719, from the KB:
| Microsoft's cause | What to read |
|---|---|
| "The Netlogon service starts before the network is ready." | The Netlogon log timeline in Step 2 |
| Link arbitration and "MAC address uniqueness checks" on some adapters and switches take longer than Netlogon waits | NIC driver version; switch port spanning-tree settings (PortFast) |
| "Solutions that verify the health of the new network member delay the network connection" (NAP, NAC, DirectAccess) | When the port moves from the quarantine network to the production network |
| "The 802.1X authentication process delays connections to the domain controllers." | Wired or wireless 802.1X timing |
| "The client experiences a delay to retrieve an IP address from the DHCP server." | DHCP response time at boot |
Read the adapter, the address, and the network profile Windows assigned. Run it right after a boot that logged 5719, and again a few minutes later:
# Read-only. Adapter, link, and driver (the selected properties are ours)
Get-NetAdapter -Physical | Select-Object Name, InterfaceDescription, Status, LinkSpeed, DriverVersion, DriverDate
# Read-only. IP address, gateway, and DNS servers per interface
Get-NetIPConfiguration -Detailed
# Read-only. Did Windows recognize the domain network?
Get-NetConnectionProfile | Select-Object InterfaceAlias, Name, NetworkCategory, IPv4Connectivity
NetworkCategory should read DomainAuthenticated, which Microsoft defines as "Networks at a workplace that are joined to a domain." A domain PC on its office network that shows Public or Private hasn't been able to reach a DC on that network, which lines up with the NlaGetIntranetCapability lines in Step 2 (our reading).
Then read the values Microsoft's KB names, so you know what someone already changed. A missing value means the default:
# Read-only. Netlogon, TCP/IP, and Group Policy values from Microsoft's 5719 KB (missing = not set)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -ErrorAction SilentlyContinue |
Select-Object ExpectedDialupDelay, NegativeCachePeriod, DynamicSiteName
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -ErrorAction SilentlyContinue |
Select-Object ArpRetryCount, DisableDHCPMediaSense
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -ErrorAction SilentlyContinue |
Select-Object DisabledComponents
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' -ErrorAction SilentlyContinue |
Select-Object GpNetworkStartTimeoutPolicyValue
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History' -ErrorAction SilentlyContinue |
Select-Object AvgWaitTimeoutAtStartup, CurrentWaitAtStartup
The Tcpip6 path for DisabledComponents is ours. Microsoft's KB names the value but not the key.
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| Address arrives several seconds after Netlogon's first try; same at every boot | The boot race. Microsoft's first resolution: "install the most current driver for the Gigabit network adapter. Or, enable the PortFast option on the network switches." | Step 9: driver or switch port first |
| Wired 802.1X or NAC on the port | The port isn't forwarding to the DCs yet when Netlogon looks | Step 9: NAC/firewall timing, then ExpectedDialupDelay
|
DisabledComponents is 0xfffffff
|
Microsoft: "system startup will be delayed for five seconds if IPv6 is disabled incorrectly by setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value is 0xff." | Step 9 |
AvgWaitTimeoutAtStartup set, no wait-time policy configured |
Microsoft's KB on this: "the time-out is miscalculated, and the Group Policy Service doesn't wait for the default 30 seconds for the network to be available." Fixed in updates released from August 22, 2023 (client) and September 12, 2023 (Windows Server 2022 and 2019) | Install current updates, or configure the wait policy (Step 9) |
Values already set by someone (NegativeCachePeriod, ExpectedDialupDelay) |
A previous fix attempt. Find out why before you add another | Read the change record |
| Wi-Fi only, before sign-in | The wireless profile may only connect after the user signs in (our reading) | Machine-level Wi-Fi profile; see Step 9 |
| VPN only | The tunnel comes up after logon, so startup never saw a DC (our reading) | The VPN section of the Group Policy post |
Step 4: DNS: can every DNS server this machine uses answer the locator? (read-only)
Microsoft's DC locator article: "Clients query DNS for the appropriate SRV records and then ping those servers by using UDP-based LDAP pings." Its domain-not-found article names two DNS causes: "The client's Domain Name System (DNS) configuration isn't correct." and "The DNS server configuration on the domain controller isn't correct." Read both sides:
# Read-only. Microsoft's first look: the adapter's IP, suffix, and DNS server list
ipconfig /all
# Read-only. The SRV queries the locator makes (corp.contoso.com and site HQ are examples)
Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.corp.contoso.com' -Type SRV -DnsOnly
Resolve-DnsName -Name '_ldap._tcp.HQ._sites.dc._msdcs.corp.contoso.com' -Type SRV -DnsOnly
Resolve-DnsName -Name 'DC01.corp.contoso.com' -Type A -DnsOnly
# Read-only. Ask each DNS server from ipconfig directly; one bad server in the list is enough (our habit)
foreach ($dns in '10.20.0.10', '10.20.0.11') {
Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.corp.contoso.com' -Type SRV -Server $dns -DnsOnly -ErrorAction SilentlyContinue |
Select-Object @{ n = 'DnsServer'; e = { $dns } }, Name, NameTarget, Port
}
Microsoft's nslookup method for the same record expects SRV answers with priority= 0 weight= 100 port= 389 and the DC's host name and address. The site-specific name format (_ldap._tcp.SiteName._sites.dc._msdcs.DomainName) comes from Microsoft's archived TechNet wiki on how DCs are located. The -Server loop is ours.
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| A router, firewall, or public resolver in the DNS server list | It can't answer _msdcs queries for your domain. The accepted answer on a Microsoft Q&A thread about 5719 says the same: DNS on the DC and the member should be the DC's address "and no others such as router or public DNS" (community answer) |
Fix the DHCP option or the static setting (Step 9) |
| SRV query works on one DNS server, fails on another | Zone replication or a forwarder problem on that server | Fix that DNS server before any client change |
| No SRV answer from any server | The DCs' records are missing. Microsoft: "To force the domain controller service registration, stop and restart the Netlogon service." on the DC | Step 7 |
| Domain SRV works, site SRV returns nothing | No DC registers in that site, or the site name is wrong | Step 5 |
| Works now, failed at boot | A negative answer cached during the boot window. ipconfig /displaydns shows the cache; Microsoft says /flushdns can "discard negative cache entries from the cache" |
Step 3 for the timing |
Microsoft's other DNS check is on the DC side: the Netlogon.dns file in %systemroot%\System32\Config lists the records a DC tries to register. "The first record in the file is the domain controller's Lightweight Directory Access Protocol (LDAP) SRV record."
Step 5: DC locator and the AD site (read-only)
Microsoft's summary of the locator: "Locator finds which domain controllers are registered." and "An LDAP User Datagram Protocol (UDP) lookup is then sent to one or more of the domain controllers listed in the response to ensure their availability. Finally, the Netlogon service caches the discovered domain controller to aid in resolving future requests." That cache matters when you test. Microsoft's nltest reference for /FORCE: "Forces the computer to run the command against the DNS server instead of looking in the cache for the information."
:: Read-only. Cached answer first, then a forced rediscovery, then a KDC specifically
nltest /dsgetdc:corp.contoso.com
nltest /dsgetdc:corp.contoso.com /force
nltest /dsgetdc:corp.contoso.com /force /kdc
:: Read-only. The site Netlogon has for this machine, and the DCs it can list
nltest /dsgetsite
nltest /dclist:corp.contoso.com
/force /kdc is the exact form in Microsoft's domain-not-found article. Microsoft's note on the output: "The list might not include all the available domain controllers." If you have the AD module, the same reads in PowerShell:
# Read-only. Forced discovery, the cached site name, and the AD subnets that map IPs to sites
Get-ADDomainController -Discover -DomainName corp.contoso.com -ForceDiscover | Select-Object Name, Site, IPv4Address
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name DynamicSiteName -ErrorAction SilentlyContinue
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site, Location | Sort-Object Name
DynamicSiteName as the place Windows stores its AD site comes from Microsoft's archived TechNet wiki. How the site gets picked, from the DC locator article: "the domain controller identifies which site the client is in based on the client's IP subnet." And: "If the domain controller isn't in the optimal site, the client flushes the cache after 15 minutes and discards the cache entry."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
/dsgetdc works, /dsgetdc /force fails |
The cache hides a break that's real right now | Steps 4, 6 |
/force works now, 5719 at boot |
Discovery is healthy once the network is up. The timing is the problem | Step 3 |
/dsgetsite is empty, or the site is wrong |
The client's subnet isn't in AD Sites and Services, or it maps to the wrong site | Step 9: add or fix the subnet |
/dsgetdc returns a DC across the WAN |
No reachable DC in the client's site, or the site's DCs don't register | Steps 6, 7 |
nltest fails with 1355 |
Microsoft lists error 1355 for a locator failure, with the message "The specified domain either doesn't exist or couldn't be contacted." (1355 is ERROR_NO_SUCH_DOMAIN, our note) |
Steps 4, 6 |
| A Windows Server 2025 member can't find DCs by a short (NetBIOS) domain name | Microsoft: "Beginning with Windows Server 2025, DC locator doesn't allow the use of NetBIOS-style location." | Use the DNS domain name; read Microsoft's BlockNetBIOSDiscovery section before you change it |
On that last row, Microsoft's guidance for the BlockNetBIOSDiscovery policy: "We recommend that you keep it set to TRUE. Disable it only for temporary periods while you're pursuing other mitigations."
Step 6: The ports between this machine and the DC (read-only)
Microsoft's domain-not-found article starts with the firewalls: "Make sure that traffic is allowed on UDP port 389 (LDAP) and UDP port 53 (DNS)." Its Kerberos troubleshooting guidance lists the rest of the path (server port side):
| Service | Server port (Microsoft) |
|---|---|
| DNS | 53 (TCP, UDP) |
| LDAP, including DC Locator | 389 (TCP, UDP) |
| Kerberos | 88 (TCP, UDP) |
| RPC endpoint mapper | 135 (TCP) |
| RPC for LSA, SAM, NetLogon | 49152-65535 (TCP) |
| SMB | 445 (TCP) |
# Read-only. TCP reachability to one DC (DC01 is an example)
foreach ($port in 53, 88, 135, 389, 445) {
Test-NetConnection -ComputerName DC01.corp.contoso.com -Port $port -WarningAction SilentlyContinue |
Select-Object ComputerName, RemotePort, TcpTestSucceeded
}
Microsoft's Test-NetConnection page describes -Port as "the TCP port number on the remote computer," so this loop can't prove UDP 389 or UDP 53. A successful nltest /dsgetdc /force from Step 5 is the practical proof that the UDP LDAP ping got through, because that's how the locator checks a DC (our reading). Microsoft's own DC location article uses the PortQryUI tool for the UDP side.
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
TCP 389 and 88 open, /dsgetdc /force fails |
UDP 389 or UDP 53 blocked on the path | Firewall team, with Microsoft's port list |
| 135 open, the dynamic range blocked | Discovery can work while RPC to Netlogon fails | The RPC range from the table |
| Fails only right after boot | A NAC or IPsec policy that opens the path late. Microsoft's Method 1: adjust the firewall settings or IPsec policies "that are changed to allow DC connectivity" | Step 9 |
| Fails to one DC, works to another | That DC, or a firewall in front of it | Step 7 |
Step 7: The DC side (read-only)
When a whole site logs 5719 at once, look at the DCs before the clients. Microsoft's Netlogon service article lists what Netlogon does on a DC, including "Domain Name System (DNS) registration of NTDS records (A, AAAA, and SRV)." If Netlogon on the DC isn't running, or is paused, clients can't use it.
:: Read-only. Netlogon state on each DC (run from an admin workstation; DC01/DC02 are examples)
sc.exe \\DC01 query netlogon
sc.exe \\DC02 query netlogon
:: Read-only. On a DC: does it advertise, and can it register its locator records?
dcdiag /test:Advertising
dcdiag /test:RegisterInDNS /DnsDomain:corp.contoso.com
Microsoft's dcdiag reference: the Advertising test "fails if the Netlogon Service has stopped or failed to start," and RegisterInDNS "Tests whether the directory server can register the directory Server Locator DNS records." The sc.exe \\DC01 form is ours.
A paused Netlogon is easy to miss. Microsoft: "When the Netlogon service is paused, the DC doesn't respond to DC Locator requests (on LDAP port UDP/389)." Its Netlogon log reasons:
| Netlogon.log entry on the DC (Microsoft) | Microsoft's cause | Next |
|---|---|---|
Netlogon Service Paused |
"The Netlogon service is paused by an administrator." |
net continue netlogon after you find out why |
NlInit: DS is paused |
"The Directory service is paused." | The DC's directory service |
Waiting for RPCSS |
"RPC Subsystem startup pending." | The DC's RPC service |
SysVol not ready |
"The DFSR Initial replication not completed." | The DFS Replication post (SYSVOL section) |
When the DC itself logs 5719. Microsoft: "If this computer is a DC for the specified domain, it sets up a secure session with the primary domain controller (PDC) emulator in the specified domain. Otherwise, this computer sets up a secure session with any DC in the specified domain." So on a DC, read whether it can reach the PDC emulator (nltest /dsgetdc:corp.contoso.com /pdc /force) and whether its own DNS client settings can resolve the domain. One suspect for a 5719 at DC boot that clears by itself is a DC whose only DNS servers aren't answering yet when it starts (our reading).
Step 8: The Netlogon service on this machine, and the 24H2 "internal error" (read-only)
Netlogon didn't start. Microsoft's Netlogon startup article: "The Netlogon service depends on the Workstation service." When a dependency fails, the System log shows Service Control Manager errors like "The Netlogon service depends on the LanmanWorkstation service which failed to start because of the following error: The dependency service or group failed to start."
:: Read-only. Netlogon's configuration and dependencies (Microsoft's sc.exe example)
sc qc netlogon
sc query netlogon
sc qc lanmanworkstation
Other symptoms Microsoft lists when Netlogon isn't running: Time-Service event 159 ("W32time is unable to communicate with Netlogon Service."), nltest /sc_query failing with 1722 0x6ba RPC_S_SERVER_UNAVAILABLE, and "System error 1792 has occurred. An attempt was made to logon, but the network logon service was not started." Microsoft's resolutions run from fixing a disabled dependency to SFC for a missing DLL, so read which service failed first.
"An internal error occurred" on Windows 11 24H2. A long Microsoft Q&A thread (community reports, not a Learn reference page) describes 5719 with that reason text on Windows 11 24H2 clients, starting after the upgrade and logged "even when I restart servrice NETLOGON" (sic), so it isn't boot timing. Several posters there tie it to machine passwords that stopped rotating, and one cites the April 2025 cumulative update. Microsoft's own pages confirm the update side. The KB5055523 release notes for Windows 11 24H2: "This update addresses an issue affecting machine password rotation in the Identity Update Manager certificate/ Public Key Cryptography for Initial Authentication (PKNIT) path." And Microsoft Learn: "Starting with the April Windows security update (KB5055523), Credential Guard protected machine accounts is temporarily disabled in Windows Server 2025 and Windows 11, version 24H2."
# Read-only. OS build, and the secure channel test (members only; no -Repair)
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber
Test-ComputerSecureChannel -Verbose
Microsoft on Test-ComputerSecureChannel: it "returns $true if the channel is working correctly and $false if it is not," and "When you run it on Domain Controllers, it returns false positive errors." Without -Repair it only tests. The Q&A posters report the channel testing True while 5719 kept appearing, so a True here doesn't close the ticket (community reports).
| 24H2 finding | What to do (our reading unless noted) |
|---|---|
| Build older than the April 2025 update | Update first. Microsoft's note above is the documented fix for the password rotation path |
Channel True, machine password not rotating |
Read the password age in AD (the trust relationship post has the reads) |
| Someone set Machine Identity Isolation by GPO | Read Microsoft's page before you change it. Microsoft: if it "was previously set to Enabled in enforcement mode, the device must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise." |
Channel False
|
The secure channel side, in the trust relationship post |
One more read that isn't a read: Microsoft's nltest reference for /sc_verify says that if the secure channel doesn't work, "this parameter removes the existing channel, and then builds a new one." Use nltest /sc_query:corp.contoso.com to look. Microsoft: it "Reports on the state of the secure channel the last time that you used it."
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Rejoining the domain because of 5719 | Changes the computer account and doesn't touch the adapter, DNS, or the switch port. The next boot logs the same event | Steps 2-6: find the layer first |
Test-ComputerSecureChannel -Repair on every PC that logs 5719 |
A reset for a channel that may be fine. The boot race happens before any DC is reachable, so there's nothing to repair yet (our reading) | Test without -Repair (Step 8), and only reset when the trust relationship post's checks say so |
nltest /sc_verify as a "check" |
Microsoft: if the channel isn't working, it "removes the existing channel, and then builds a new one" | nltest /sc_query |
| "Always wait for the network" for the whole domain | Microsoft: "On servers running Windows Server 2008 or later, this policy setting is ignored during Group Policy processing at computer startup." On clients it makes sign-in wait, and it doesn't make Netlogon find a DC sooner (our reading) | Step 3: fix the timing; use the setting only where foreground processing is the point |
Disabling IPv6 with a 0xfffffff value |
Microsoft: "We do not recommend that you disable IPv6 or its components." A wrong DisabledComponents value adds a five-second startup delay |
Step 9: correct the value to 0xff if someone set it |
| Adding a public DNS server as "backup" | It can't answer _msdcs queries for your domain, so the client sometimes gets no DC at all (our reading) |
Step 4: only DNS servers that host or forward the AD zones |
ExpectedDialupDelay at 600 everywhere |
Microsoft's own note: "This is only effective if the machine already has an IP address." It fits a quarantine network, not a slow DHCP or link | Step 3: find the delay first |
| Ignoring every 5719 because Microsoft calls it safe to ignore | Microsoft's line is conditional: safe "If you can log on to the domain without a problem." Missed startup GPOs and scripts count as a problem (our reading) | Step 1: list what else failed |
Flipping MachineIdentityIsolation from a forum post |
Microsoft: after enforcement mode, the device "must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise." | Step 8: update first, then read Microsoft's page |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1-8 point at. Do the network fixes first, because Microsoft lists them first. Save the keys before any registry change:
# Low-risk write. Save the Netlogon, TCP/IP, and Winlogon keys before you change them (our habit)
reg export HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters C:\Temp\netlogon-params-before.reg /y
reg export HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters C:\Temp\tcpip-params-before.reg /y
reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" C:\Temp\winlogon-before.reg /y
The boot race (Step 3), network side. Microsoft's Resolution 1: the current driver for the network adapter, or PortFast on the switch port. Both are owned outside Windows: the driver by whoever packages drivers, the switch port by the network team. For 802.1X or NAC, Microsoft's Method 1 is to adjust the firewall settings or IPsec policies so DC traffic is allowed as soon as the client has its address.
The boot race, Group Policy side. Microsoft's Method 7: set "Specify startup policy processing wait time" (Computer Configuration\Administrative Templates\System\Group Policy). Microsoft: "The time it takes Netlogon to acquire a working IP can be the basis for the setting." Measure it from the Netlogon log in Step 2 (the gap between the first failure and the Winsock Addrs line), add a margin, and set that. The policy's own text: "If you disable or don't configure this policy setting, Group Policy will use the default wait time of 30 seconds on computers running Windows Vista operating system." Configuring it also works around the miscalculated-wait issue from Step 3. Microsoft's Method 9 is a registry value with the same goal, under Winlogon, set to 60 (decimal). Pick the GPO or the registry value, not both (our preference: the GPO):
# Change, on one test PC first. Microsoft's Method 9 value; restart after. Dry-run first
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name GpNetworkStartTimeoutPolicyValue -Value 60 -Type DWord -WhatIf
Microsoft: "If the Group Policy startup script doesn't run, increase the value of the GpNetworkStartTimeoutPolicyValue registry entry."
A NAC quarantine network that releases the PC late (Step 3). Microsoft's Method 2, ExpectedDialupDelay in seconds, "Data Range is between 0 and 600 seconds (10 minutes)," and only when the PC already has an address:
# Change. Example: 60 seconds, from your measured delay. Dry-run first
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name ExpectedDialupDelay -Value 60 -Type DWord -WhatIf
Netlogon gives up on DCs too long after one failure. Microsoft's Method 4, NegativeCachePeriod: with it reduced, "the Netlogon service doesn't behave as if the domain controllers are offline for 45 seconds." Microsoft's suggestion: "Try to set a low value, such as three seconds. In LAN environments, you can use a value of 0 to turn off the negative cache." And: "The event 5719 is still logged." So this shortens the outage, not the event (our reading).
# Change. Microsoft's suggested low value. Dry-run first
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' -Name NegativeCachePeriod -Value 3 -Type DWord -WhatIf
Slow address uniqueness checks. Microsoft's Method 3: ArpRetryCount = 1 under Tcpip\Parameters ("The Data Range is between 0 and 3 (3 is default)."):
# Change. Microsoft's Method 3 value. Dry-run first
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name ArpRetryCount -Value 1 -Type DWord -WhatIf
A wrong DisabledComponents value. Microsoft's Method 8: delete it, or change it to 0xff. The path is ours, as in Step 3:
# Change. Only if Step 3 found 0xfffffff. Dry-run first
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -Name DisabledComponents -Value 0xff -Type DWord -WhatIf
Microsoft's KB lists more methods: a Kerberos MaxPacketSize value that "applies only to Windows XP and Windows Server 2003 or earlier versions," and DisableDHCPMediaSense. We'd skip the first on anything current and keep media sense as a last resort (our view).
DNS (Step 4). Fix the DNS server list where it's set: the DHCP scope option, or the static adapter setting. Then, on the client, ipconfig /flushdns and a reboot test. If a DC's records are missing, Microsoft's steps on that DC: ipconfig /registerdns for its host record, and restart Netlogon to re-register the locator records:
# Change, on the DC with missing records (DC01). Clients on that DC fail over briefly. Dry-run first
Restart-Service -Name Netlogon -WhatIf
A missing or wrong AD subnet (Step 5). Add the subnet to the right site. The subnet and site below are examples:
# Change. Map the client subnet to its site. Dry-run first
New-ADReplicationSubnet -Name '10.20.30.0/24' -Site HQ -Location 'HQ, 3rd floor' -WhatIf
The client picks up the new site on a later locator call. Microsoft's 15-minute cache rule from Step 5 applies to a DC in the wrong site.
A paused or stopped Netlogon on a DC (Step 7). Find the cause from the Netlogon log reasons first. For SysVol not ready, fix SYSVOL replication; don't force the service.
The 24H2 "internal error" (Step 8). Install the current cumulative update. Leave Machine Identity Isolation alone until you've read Microsoft's mode descriptions, because backing out of enforcement mode means a rejoin.
Then prove it with a boot. Restart the PC and read only this boot's events:
# Read-only. 5719 and 1129 since this boot, a forced locator call, and the channel test
$boot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'NETLOGON'; Id = 5719; StartTime = $boot } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-GroupPolicy'; Id = 1129; StartTime = $boot } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message
nltest /dsgetdc:corp.contoso.com /force
Test-ComputerSecureChannel
Watch five or more boots, not one, because Microsoft notes the delay can alternate "between startups." Check that the startup script ran. Then turn the diagnostics back off: Nltest /DBFlag:0x0, and remove GPSvcDebugLevel if you set it.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Boot race on wired PCs, same switch model | Current NIC driver or PortFast on access ports | Rejoining PCs |
| 802.1X or NAC releases the port late | NAC/firewall timing, then ExpectedDialupDelay for the quarantine case |
ExpectedDialupDelay 600 on every PC |
| Startup GPO or script misses the window | "Specify startup policy processing wait time" from a measured delay | "Always wait for the network" for the whole domain |
| A public or router DNS server in the list | AD DNS servers only, via DHCP or the static setting | Hosts-file entries for DCs |
| No site, or the wrong site |
New-ADReplicationSubnet for the client subnet |
Hard-coding a DC on the client |
| DC records missing |
ipconfig /registerdns and a Netlogon restart on that DC |
Hand-made SRV records |
| Windows 11 24H2 "internal error" | Current cumulative update, then read the password age | Registry flips from forum threads |
| DC found, channel broken | The trust relationship post's repair path | Rejoin as the first move |
FAQ
What does Netlogon event ID 5719 mean?
The computer couldn't set up a secure session with a domain controller when Netlogon tried. The reason text after "due to the following:" says why. "There are currently no logon servers available to service the logon request" means no DC was found or answered at that moment. Microsoft's main causes are a network that wasn't ready yet, DNS that can't answer the locator's SRV queries, and blocked ports.
Can I ignore event ID 5719?
Sometimes. Microsoft: "If you can log on to the domain without a problem, you can safely ignore event ID 5719." Check what else failed at the same time. A 1129 from Group Policy, a startup script that didn't run, or users who can't reach shares is a reason to work through the chain.
Why does 5719 only happen at startup?
Usually because Netlogon looked for a DC before the network was ready: link negotiation, an 802.1X or NAC check, or a slow DHCP answer. Microsoft's first fixes are a current NIC driver and PortFast on the switch, then Group Policy's startup wait time. The Netlogon debug log shows the gap between the first failure and the address arriving.
Why does Windows 11 24H2 log 5719 "An internal error occurred"?
Microsoft Q&A threads report it on Windows 11 24H2 after the upgrade, even when Netlogon restarts, so it isn't boot timing. Microsoft's April 2025 update (KB5055523) fixed a machine password rotation issue and temporarily disabled Credential Guard protected machine accounts. Update first, then check whether the machine password is rotating.
What does 5719 mean on a domain controller?
Microsoft: a DC "sets up a secure session with the primary domain controller (PDC) emulator in the specified domain." So check that the DC can reach the PDC emulator (nltest /dsgetdc:yourdomain /pdc /force) and that its own DNS servers answer at boot. On a DC, Test-ComputerSecureChannel "returns false positive errors," so use nltest there.
Related posts
- Trust Relationship Between This Workstation and the Primary Domain Failed (the secure channel and machine password repair side, once the machine can find a DC)
- Group Policy Not Applying (event 1129, startup processing, and VPN users whose startup run never saw a DC)
- Windows Time Not Syncing With Domain Controller (Time-Service events that show up when a machine can't find a DC, and the Kerberos five-minute window)
Free checklist
A startup policy that never ran because the network wasn't ready is a change that didn't land where you thought. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=netlogon-event-id-5719
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: Get-WinEvent, Get-CimInstance, Select-String on the Netlogon log, Get-NetAdapter, Get-NetIPConfiguration, Get-NetConnectionProfile, Get-ItemProperty, ipconfig /all / /displaydns, Resolve-DnsName, nltest /dsgetdc / /dsgetsite / /dclist / /sc_query, Get-ADDomainController -Discover, Get-ADReplicationSubnet, Test-NetConnection, sc qc / sc query, dcdiag /test:Advertising / RegisterInDNS, and Test-ComputerSecureChannel without -Repair. Nltest /DBFlag and GPSvcDebugLevel are diagnostic changes; reg export writes local files. Driver and switch changes, the Group Policy wait time, GpNetworkStartTimeoutPolicyValue, ExpectedDialupDelay, NegativeCachePeriod, ArpRetryCount, DisabledComponents, DNS server changes, ipconfig /flushdns / /registerdns, restarting Netlogon on a DC, new AD subnets, nltest /sc_verify, and secure channel repairs are deliberate changes. Change one layer at a time, test on one machine first, and check current Microsoft Learn for version-specific behavior.
