- Delegate permissions for domain join - Mon, Jun 5 2023
- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
If you are confronted with the message that a program cannot connect to the domain, you should first rule out a few obvious causes. This includes checking the availability of a domain controller, for example, with ping.

Management tools such as the Group Policy Management Console will report an error if no DC is reachable
If the DC is accessible, then take a look at the hosts file to see whether there is an invalid entry for the domain or a DC. If everything is okay so far, then you should turn your attention to the DNS configuration.
Check the DNS server
A common cause of connection problems to a DC is that an invalid (public) DNS server has been assigned to the computer. This then lacks the SRV entries for the Active Directory DCs.
Using the following command, your first step can be to verify whether the name of the domain can be resolved:
Test-NetConnection -TraceRoute <name-of-domain>
If this test fails, you can use nslookup to verify that the SRV entries mentioned are missing. To do so, enter the following commands:
nslookup set type=all _ldap._tcp.dc._msdcs.<DomainName> quit
In the third line, you must, of course, use your own domain.
Query assigned DNS servers
If the suspicion that the client is using the wrong DNS server is confirmed, check the corresponding entry in the IP settings. You can do this with the PowerShell cmdlet
Get-DnsClientServerAddress | Format-List or with ipconfig /all
Determining the origin of the DNS configuration
If the correct DNS servers are not entered here, you now have to find out where the computer gets this configuration from. You should not only check the configuration of IPv4 but also of IPv6.
Even if the IPv4 settings are OK, the domain cannot be found if the IPv6 setting for the DNS server is invalid because Windows prioritizes IPv6 by default.
With the help of the commands
netsh interface ipv4 show dnsservers and netsh interface ipv6 show dnsservers
it is possible to determine whether the DNS servers were assigned manually or via DHCP.
Alternatively, the GUI for the adapter settings is also available for this purpose.
Correcting the DHCP configuration
If the manual configuration of the DNS server is incorrect, it can be corrected on the spot. If the interface obtains its settings for the DNS server via DHCP, then you should check option 006 for the relevant IPv4 scope and correct it if necessary.
With IPv6, the case is a bit more complicated because there, DHCP is not necessary as an alternative to a manual configuration. Instead, the IPv6 clients can create a basic configuration for themselves using stateless address autoconfiguration (SLAAC). Each host then gets the global prefix and the IPv6 address of the DNS server via the router (RDNSS option).
Especially in smaller networks, you might not want to switch to a stateful address configuration to explicitly assign the IPv6 settings to the clients. In this case, one solution is to prioritize IPv4 over IPv6.
To do so, you need to create a registry key called DisabledComponents under HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters. The easiest way to do this is to save the following code in a file with the extension .reg and execute it by double-clicking it:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters] "DisabledComponents"=dword:00000020
Microsoft, on the other hand, advises against disabling IPv6 altogether because it could affect the functioning of the system. Prioritizing IPv4 should be sufficient to allow clients to reach a domain controller again.
Summary
In most cases, the lack of connectivity to an AD domain is due to a network problem. Once you have ruled out some simple causes, such as whether a DC is online, then you can move on to analyzing the DNS configuration.
Subscribe to 4sysops newsletter!
An incorrectly assigned DNS server without SRV records for the DCs may then prove to be the culprit. It is not enough if the IPv4 settings are OK because Windows prefers IPv6. In this case, it helps to prioritize IPv4 over IPv6.
Handy troubleshooting steps. Thank you!
It is the PDC role holder that is a default target domain controller for Group Policy updates.
So when we troubleshoot, we need to check for
_ldap._tcp.pdc._msdcs. – “pdc” instead of “dc”.
If it resolves into another server, other than your actual PDC, then that is your problem.