ERROR_DS_UNAVAILABLE (0X0000200F): Directory service is unavailable

Quick answer

Check DNS resolution for the domain and ensure LDAP (389/TCP) and Kerberos (88/UDP) are open between client and domain controller.

What's actually happening here

ERROR_DS_UNAVAILABLE (0X0000200F) fires when a Windows machine or server tries to contact Active Directory but gets no response. The DC is either unreachable, not resolving, or rejecting the connection. In my experience, 90% of cases come from bad DNS—the client can't find a DC because its DNS server doesn't point to one, or the SRV records are stale. The other 10% is firewalls silently dropping LDAP traffic or the DC service itself being stopped.

This error looks like "The directory service is unavailable" and shows up in event logs, AD tools, or when you try to join a domain. On Windows Server 2022, 2019, or even Windows 10/11 clients, the behavior is identical: the computer gives up after a timeout.

Fix steps

1. Validate DNS on the client
   Open a command prompt and run ipconfig /all. Check that the DNS server points to a domain controller (not an external DNS like 8.8.8.8). Then run nslookup yourdomain.local. If it fails, your DNS is broken—fix that first.
2. Test DC discovery
   Run nltest /dsgetdc:yourdomain.local. If it returns ERROR_DS_UNAVAILABLE, the client can't find a DC via DNS. Try nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.local. No results? Your DC's SRV records are missing or the DNS zone is misconfigured.
3. Check LDAP port from the client
   telnet dc-ip 389 should connect. If it hangs or fails, a firewall (Windows Defender Firewall, third-party, or network firewall) is blocking LDAP. Kerberos (88 UDP) and global catalog (3268/TCP) also need to be open.
4. Verify the DC's NTDS service
   On the domain controller, run net start | find "Active Directory Domain Services". If it's not running, start it: net start ntds. Then check event logs for reasons why it stopped.
5. Flush and reregister DNS
   On the DC, run ipconfig /flushdns and ipconfig /registerdns. Then restart the Netlogon service: net stop netlogon && net start netlogon. This forces SRV record reregistration.

If the main fix doesn't work

Sometimes the client's DNS is fine but the DC itself has issues. Try these alternative fixes:

• Check time sync — Kerberos is picky: more than 5 minutes skew between client and DC will silently fail any auth. Run w32tm /query /status on both sides.
• Disable IPv6 temporarily — On some networks, IPv6 queries for AD cause resolution hangs. Uncheck IPv6 in the NIC properties, reboot, and test.
• Use the DC's IP directly in DNS — Add a manual A record on the client's hosts file (C:\Windows\System32\drivers\etc\hosts) mapping the domain to the DC's IP. This is a crutch, not a fix, but it tells you if the problem is DNS or network.

Preventing this from happening again

Set up secondary DNS servers on all clients—multiple DCs if you have them. Use a monitoring tool (like PRTG or Zabbix) to ping the LDAP port every 5 minutes. Also, configure DNS scavenging on the AD zone so stale DC records auto-delete. I've seen this error pop up months after a DC was decommissioned because no one cleaned up DNS.

Lastly, enable Kerberos logging on DCs (reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v LogLevel /t REG_DWORD /d 1) to catch failing auths early.