Domain controllers are database servers with extensive directory, application, and replication features. You establish a server as a domain controller by installing the necessary binaries for the Active Directory Domain Services (AD DS) and then configuring the services using the Active Directory Domain Services. Kindly refer to the following related guides: How to setup a cache-only DNS server, how to locate and edit the hosts file on Windows, how to install RSAT tools: DNS manager console missing from RSAT tools on Windows 10, how to setup SPF and TXT Records in AWS, how to add and verify a custom domain name to Azure Active Directory, Active Directory: How to Setup a Domain Controller, how to locate and edit the host file on macOS, and how to know when an IP or domain has been blacklisted.
You may also want to see the following related guides: How to fix nslookup unknown: cannot find non-existent domain, how to FlushDNS, Release, Registerdns, and Renew parameters: How to Fix Err Connection Timed Out DNS Error, Ping request could not find the host: Verify if the name is entered correctly, Error: An Active Directory could not be contacted or cannot find domain because it is nonexistent, and cannot find KDC for realm while getting initial credentials and kinit configuration file does not specify default realm.
The following error was prompted in my environment because the Domain Controller wasn’t reachable. Ensure these errors are eliminated for a single node, else Microsoft Technical Support would not provide you support.
As you can see below, the validation was completed successfully with few warnings. One of which is to apply updates and reboot the node.
– Other possible issues: Check if the IP Settings of your DC etc.
In a Multi-Cluster Node: This is expected in multisite clusters and can be ignored. When you run a cluster validation test for your multi-site failover cluster, the test may fail at validating the Active Directory configuration with one of the following error messages:
– Connectivity to a writable domain controller from node HyperV.techdirectarchive.local could not be determined because of this error: Could not get domain controller name from machine HyperV.techdirectarchive.local.
– The site name of node HyperV.techdirectarchive.local could not be determined because of this error: Could not get domain controller name from machine HyperV.techdirectarchive.local.
Regardless of the errors, the cluster nodes can successfully communicate with some domain controller and form a failover cluster.
More Info: When you start a cluster validation test on a node, the node selects a domain controller to be used for the test. During the Active Directory configuration validation, all computers that are selected as part of the validation are pointed to use this domain controller. In a multi-site cluster scenario, the network communications may be designed in a way where computers are only allowed to communicate with domain controllers that are on their local site. Therefore, these computers are prevented from communications with remote domain controllers.
- In this scenario, computers in other sites are not able to communicate with the selected domain controller, which leads to the failure of the cluster validation test.
- If the computers can communicate to a domain controller in the domain, and the domain controllers are successfully replicating, then the functionality of your failover cluster is not impacted.
In a multi-site cluster scenario, you can safely ignore the failed validation. Meanwhile, your failover cluster is still supported by Microsoft Technical Support.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.