Event 5719 — no domain controller available for the domain
Netlogon could not find a DC when it needed one. At startup this is usually a race with the network coming up; at other times it is a real DC location failure.
What you see
Event 5719 in the System log, often paired with Group Policy 1129. Sometimes only at boot with no user impact, sometimes with sign-in failures.
What is actually wrong
The network stack is not ready when Netlogon starts, DNS is pointing at the wrong resolver, a VPN or teamed NIC is slow to initialise, or the site topology has no DC in the client's subnet.
Codes and articles
Fixes (2)
Make the machine wait for the network before logging on
Only at startup, with no impact afterwards. This is a race, not a fault.
Confirm the event only ever appears within a minute of boot.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=5719} -MaxEvents 20 | Format-Table TimeCreated, Message -AutoSizeGet-WinEvent -FilterHashtable @{LogName='System'; Id=6005} -MaxEvents 5 | Format-Table TimeCreated
Event 6005 is the event log starting, which is as close to boot time as you get. If every 5719 lands within a minute of a 6005, it is the race.
Turn on Always wait for the network at computer startup and logon in Group Policy, under Computer Configuration → Administrative Templates → System → Logon.
New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name 'SyncForegroundPolicy' -Force -ErrorAction SilentlyContinueSet-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name SyncForegroundPolicy -Value 1 -Type DWord
It costs a few seconds of boot time and removes a whole class of intermittent policy and drive-mapping failures.
Disable NIC power saving, which delays link-up on wake.
Get-NetAdapter | ForEach-Object { Set-NetAdapterPowerManagement -Name $_.Name -AllowComputerToTurnOffDevice Disabled -ErrorAction SilentlyContinue }On a Wi-Fi machine, enable the machine-account authentication option so the network is up before sign-in.
Repair DC location
It happens outside of boot, or users are seeing failures.
Ask the machine to locate a DC and show its reasoning.
nltest /dsgetdc:example.local /forcenltest /dsgetsite
Check the DNS servers configured — a public resolver here breaks DC location entirely.
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, ServerAddresses -AutoSizeConfirm the SRV records exist.
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.example.local -Type SRV | Format-Table Name, NameTarget, Port -AutoSizeCheck the client's subnet is defined in Sites and Services — an undefined subnet sends clients to a random site.
Get-ADReplicationSubnet -Filter * | Format-Table Name, Site -AutoSizeA missing subnet definition makes clients authenticate across a WAN link to whichever DC answers first, which produces intermittent 5719s and slow logons that look like a network fault.
Add the missing subnet.
New-ADReplicationSubnet -Name '10.20.0.0/24' -Site 'Branch-Office'Reset the secure channel if it is broken.
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
nltest /dsgetdc:example.localRelated faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.