There Are Currently No Logon Servers Available to Service the Logon Request

Introduction

Someone cannot log in. The screen says there are no logon servers available, and depending on the machine you might also see it when a scheduled task runs, when gpupdate is invoked, or when someone tries to map a drive. Other users on other machines are fine. The domain is up. Yet this one endpoint behaves as though Active Directory does not exist.

The message is literal: the machine asked for a domain controller and got none it could use. That can happen because it could not find one, could not reach the one it found, or found and reached one but could not authenticate to it. Each of those is a different fix, and the diagnostic path below separates them in a couple of minutes.

What You’re Seeing

The exact wording shows up across several operations, which is a useful clue in itself — it is a domain-reachability problem, not an application one:

There are currently no logon servers available
to service the logon request.

# The same underlying failure from the command line
C:\> gpupdate /force
Computer policy could not be updated successfully.
There are currently no logon servers available...

# DC discovery run by hand also comes back empty
C:\> nltest /dsgetdc:corp.example.com
Getting DC name failed: Status = 1355 0x54b
ERROR_NO_SUCH_DOMAIN

What It Actually Means

When a machine needs a DC, Netlogon runs the DC Locator. It asks DNS for the service records that advertise domain controllers — records like _ldap._tcp.dc._msdcs.corp.example.com — picks a candidate, and opens a connection. If DNS on the client points at the wrong server (a home router, a public resolver, an ISP address), those records cannot be found and discovery dies immediately. If DNS is correct but a firewall or routing problem blocks the DC’s ports, discovery finds a DC it cannot reach.

Even when discovery and connectivity are perfect, logon can still fail at the last step: the machine has to prove its identity using its own account password, and if that secure channel is broken — the same fault behind the trust relationship failed error — or the clocks are more than five minutes apart, Kerberos refuses and you get the same message. So this one error spans the whole chain from name resolution to authentication.

Step 1: Run DC Discovery by Hand

Start where the machine starts. nltest /dsgetdc exercises the exact locator process the logon used, and tells you whether a DC can be found and which one.

# Find a DC for the domain - forces discovery instead of using the cache
nltest /dsgetdc:corp.example.com /force

# List every DC the client knows for the domain
nltest /dclist:corp.example.com

# From PowerShell, the same discovery with more detail
Get-ADDomainController -Discover -Domain corp.example.com

# Is the secure channel itself healthy? (only meaningful if a DC is found)
nltest /sc_query:corp.example.com

Step 2: Check DNS and the SRV Records

DC location is a DNS problem more often than anything else. The client must be pointed at an internal DNS server that hosts the AD zone, and the domain’s service records must resolve.

# What DNS server is the client actually using? It must be internal.
ipconfig /all

# Can the domain's DC locator records be resolved?
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com

# Resolve the domain to its DCs
nslookup corp.example.com

# Flush a stale cache and re-register, then retry discovery
ipconfig /flushdns
ipconfig /registerdns

Step 3: Services, Ports, and Time

If a DC resolves and answers ping but logon still fails, look at the machine’s own services, the network path to the DC’s ports, and the clock.

# These must be running on the client for domain logon to work
Get-Service Netlogon, Dnscache, W32Time | Select-Object Name, Status

# Can the client reach the core DC ports? (DNS 53, Kerberos 88, LDAP 389, SMB 445)
Test-NetConnection DC01.corp.example.com -Port 88
Test-NetConnection DC01.corp.example.com -Port 389

# Kerberos fails if the clock is more than 5 minutes off the DC
w32tm /resync
w32tm /query /status

Common Causes

Work down the list. The first three account for the large majority of cases.

Working Through a Fix

Split the problem with one command. Run nltest /dsgetdc:<domain> /force. If it fails, you are in the discovery half: check ipconfig /all for the DNS server, confirm the SRV records resolve, and verify the path to the DC’s ports. Correcting the client’s DNS resolves the majority of these outright.

If discovery succeeds but logon still fails, you are in the authentication half: check the secure channel with nltest /sc_query and repair it if needed, and confirm the clock is within five minutes of the DC. When every client on a subnet fails at once, stop looking at clients — a DC, a site link, or a firewall change is the real event, and the fix belongs there.

How to Prevent It

The durable fixes are unglamorous. Hand out internal DNS servers through DHCP and never external ones, so no client can drift onto a public resolver. Keep the AD DNS zones healthy and the DC locator records registered — monitoring SRV-record presence catches a whole class of these before a user does. Keep DC ports open consistently across sites, and keep time synchronised from the PDC emulator down, because skew produces this same message with no DNS fault in sight.

For remote and roaming machines, plan for the gap between boot and network: cached credentials and pre-logon VPN keep users working when no DC is reachable yet. The deeper the DNS and locator foundations, the rarer this call becomes — both are covered in the DNS post.

Quick Reference

Final Thoughts

“No logon servers available” sounds like the domain vanished, but it is a reachability statement about one machine at one moment. Find a DC, reach it, prove yourself to it — the error lives at whichever of those three the machine could not complete. Run the locator by hand and the failing step names itself.

Once you split discovery from authentication with a single nltest, the same call that used to end in a reflexive rejoin or reboot resolves to a specific, explainable cause — usually a client looking at the wrong DNS server.