The AD Best Practice Analyzer and dcdiag.exe can be excellent tools for diagnosing weird AD issues, but before you start with those, here are some common settings that are wrong with almost all of the domain controllers I come across, including some brand-new Windows Server 2019 servers.
In the settings for the ethernet adapter or vNIC:
- IPv4 DNS: A domain controller should not point to itself for primary DNS! It should point to a different domain controller, preferably the domain controller listed as the primary name server for the primary zone of the AD domain. This is necessary for dynamic record registration and finding other domain controllers. Domain controllers that point to themselves for primary DNS are in danger of becoming an island server.
- IPv4 DNS: A domain controller should point to its RFC1918 IP address for secondary DNS, but not the loopback address!
- IPv6 A domain controller should not point to ::1 for primary in IPv6 settings, but I guarantee that any new domain controller you promote will have this bad setting.
- Receive-side scaling should be enabled on NICs in servers with multiple CPUs/cores/vCPUs.
DNS Server settings:
- Forwards should be external servers outside the domain, like your ISP’s DNS servers or Cloudflare’s 1.1 servers. They should not be other domain controllers. Domain controllers already replicate DNS with each other, so there’s no reason to use one as a forwarder. GRC’s DNS Benchmark can help you determine what is the best forwarder for you. Your ISP’s DNS servers are likely the fewest hops away from you, and Cloudflare’s are likely a very close second, maybe even just a few extra hops in the very same datacenter if your ISP is a big player and there is a big city is nearby. (For example, lots of big companies that do business in the mid-west US region have servers in the datacenter at 350 E. Cermak in Chicago, IL)For DNS servers in IPv4-only subnets without IPv6 connectivity, DNS root hints should only contain IPv4 addresses, and they should all be up to date. For each of the 13 root servers, go to Actions>Edit>Resolve>Apply to update the address with the correct IPv4 address.
- Domains that have been around for a long time may have the _msdcs zone as a subdomain instead of a delegated DNS zone. This is only really a practical issue in AD forests where DNS record replication is causing performance issues, but the BPA scan will still warn you about it saying the delegated zone is missing, which is not a very helpful message. On a similar note, old domains might still be using FRS replication and you need to upgrade to DFSR before promoting Server 2016 machines to domain controllers.
- Add reverse DNS zones for all your subnets!
On client computers:
- Speaking of DNS settings, check the IPv4 settings on all of your AD-joined computers and check that no one has configured a DNS server that isn’t the local domain controller for their site. It’s not uncommon to find static IPv4 settings pointing to 8.8.8.8 and 8.8.4.4, and then people wonder why they can’t authenticate to AD.
- If you use a DNS filtering service either use it as a transparent (MitM) filter or as a forwarder for your domain controllers. Your AD-joined workstations should not know about any DNS server that isn’t a domain controller.
After you’ve checked all of that, run this command:
dcdiag /c /e /v /n:your.ad.domain.here
- /c – run a comprehensive list of tests (all of them)
- /e – run on every server in the enterprise
- /v – verbose output
- /n – naming context (the thing to check), your domain obviously
Before looking at any of the other errors, scroll all the way down to the enterprise DNS summary table and work on anything that isn’t PASS first. Look at SystemLog errors last. There are PowerShell scripts available to make the output of dcdiag easier to read and turn the pass/fail results into a color-coded table, but it runs only one dcdiag test at a time.