In this article, we will be tackling an error known as “An Active Directory Domain Controller (AD DC) For The Domain Could Not Be Contacted”. This is a fault that occurs when a new computer is joining the current domain, so you must fix this to add new devices to your station!
What Does The Error “An Active Directory Domain Controller (AD DC) For The Domain Could Not Be Contacted” Look Like?
Normally, to add a newly created Windows workstation to an existing domain, one can head to System Properties to get started. Follow Change settings > Change, and you will be able to fill in the form that pops up. You will be required to provide the computer name, the role that this PCwill play in your existing domain, and the domain’s FQDN name.
But if your system has the aforementioned error, you will receive a notice that says: “An active directory domain controller for the domain could not be contacted. Ensure that the domain name is Spelled correctly. If the name is correct, click Details for troubleshooting information.”
The first step to reacting to this notification is to double-check the information carefully before you proceed. When you ask for elaborations from the “Details” tab, it’s likely that you will get “DNS name does not exist” or other wordings of the same message (error codes 0x0000232B RCODE_NAME_ERROR and 0x0000267C DNS_ERROR_NO_DNS_SERVER).
Image 1. Here is the notification that may alert you of the error.
If that is what you have received, scroll down to learn how to fix this error!
How To Fix This Error On Your Computer
- Examine The Adjustments You Make To Your IP:
You may direct your attention to your IP number or DNS settings background on your current device for faults. Failures in these parts can be caused by misconfigurations while DNS is being processed through the domain control panel or prevention from your firewall applications.
Before all else, please proofread if your IP address displayed on your device’s interface matches with how it actually looks like in real life. You may get the right information from a DHCP server, or you can head straight to the web adapter adjustment tabs for the same result.
You can also run this line in Windows Administration to have the output sent straight to you:
Image 2. All the information regarding IP has been gathered for you!
Next, you must access your host file (C:\Windows\System32\Drivers\etc\hosts) via any text editor applications you have on your device (the most popular one is notepad.exe). You may check if anyone has attempted to gain entry into your domain and remove any unauthorized access.
Once again, you can run this line to have the information sent straight to your interface for easy viewing:
Image 3. You should be getting a detailed list, similar to this one right here.
To fully prevent any deviations from barring connections, you can safely clear everything contained in the DNS cache and turn your computer off and on again so it can reorganize itself during the booting process. Use these commands to do all of those actions in one swoop:
net stop dnscache && net start dnscache”
After you have executed the lines, you can go on to examine your domain controller and see if it allows entry from the receiving end you’re working with. You will also need to run another couple of phrases:
Image 4. The commands will churn out a list of responses from domains.
Should the domain controller be up and working, let’s try adding the received IP address as a DNS server. This is a step that you can only do in the Advanced TCP/IP settings within the bounds of your network connectivity state. Here are the steps:
- Take the steps as follow: Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings.
- Choose the adapter that you’re already using with your corporate net system with your mouse’s right button. That will open an additional feature menu, from which you can select the “Properties” tab.
Image 5. In this example, we are using Ethernet, but your connection can be different.
- Choose the Advanced option, which will take you to the DNS section;
- On the DNS tab, press Add, and enter the IP address of your DNS server (domain controller)
- Internet Protocol Version 4 should be visible (it may also appear as TCP/IPv4), so please click on that and later “Properties”.
- You will find the “Advanced” settings. From the DNS tab contained in that option, you can add the address of your DNS server/domain controller.
Image 6. Here are all the buttons you need to find to enter the address.
- After you have moved your DC’s IP address towards the first spot of your list, you can safely confirm your changes and leave the pop-up window.
When everything is in their place, restart the DC and try joining in once more. The procedure should be standard from there on out.
If you’re extra careful, you may also attempt to validate if the service access on the DC application is not controlled and prevented by firewalls. It’s okay to manually check with your security features, but a more convenient approach is to run this line through PowerShell:
“test-netconnection 192.168.1.11 -port 53”
Image 7. This shall be the returns of your test through PowerShell!
If the test run by PowerShell gives an output of “True”, that means the client device is allowed to pass your firewalls.
In case the client’s IP address on the domain is still wrong, you can double-check with the Resolve-DNSName cmdlet with the FQDN of your domain. You must execute this line through the controller you are trying to add into:
“Resolve-DNSName [domain name]”
Image 8. The result window will give you a list of addresses!
Rather than giving you just one result, the command will lend you to the entire record of the DNS servers.
Make an active effort to ensure the client device can connect and make directives to the DNS server that hosts its zone. The correct DNS server should also be configured based on your client’s preferences. Finally, please get confirmation that such a domain exists on the controller by using this convenient line:
“nltest /dsgetdc: [domain name]”
Image 9. You can receive an output like this to confirm a domain’s existence.
The output should also confirm other information like Domain Name, Site Names, etc. This can be a useful function for you to fact-check every aspect of your workstation as well as your client’s, and potentially examine any faults in the display as well!
Occasionally, you will have to prepare yourself to disable the Windows Firewalls themselves to let your client into the domain. This will also call for you to turn off any similar third-party security application, but it should be necessary for this process.
- Examine What The Domain Controller Has On Their Replica & DNS SRV Records:
If you have scrolled all the way down here and your PC still sends you notifications for “an active directory domain cannot be contacted”, then you’re in deep trouble. This means that there are faults in your DC’s DNS zone and the controller’s records of its activities and locations.
You start with solving this error by initiating the Command window and execute this line:
From that execution, you can validate the server with the suspected recording in this form down here:
“_ldap._tcp.dc._msdcs.your_domain_name.com SRV service location:”
Image 10. This is the pop-up form that you will get as a result!
If you notice a blank where the SRV record is supposed to be, you can logically conclude that your device does not have either a server that owns the suitable SRV or the stored position of the domain controller. When that is the case, please verify if the DC is configured the same way the DNS server is or if the duplication of the server on the receiving end is executed correctly.
You can also examine if the client’s device lets dynamic settings through for you to make changes.
After that, as the administrator, you should switch the Netlogon service off and on again with the line “net stop netlogon && net start netlogon”. You can also just restart the entire domain controller for a quicker solution. Either way, upon booting, the controller will register your records onto the existing server, so don’t worry about losing data!
Just in case there are any failures, here is a command for you to manually register the records again:
You need to give the functions a few seconds to load, and then you can paste it on the domain and server!
We advise that you do a safety-net additional step that is verifying the NETLOGON and SYSVOL shared folder’s existence and shareability on the DC.
Image 11. You should be receiving this confirmation on the command’s execution!
If you only find a blank where the NETLOGON and SYSVOL directories should be on the shared list, these are the steps you need to go:
- Double-check the IP and DNS adjustments on your DC (the domain controller should not be able to take in an IP address from a server like DHCP, so please make adjustments wherever necessary).
- Proofread if the C:\Windows\SYSVOL domain directory has Policies and Scripts folders on it.
Image 12. This is where you need to look to be sure of the folders’ inclusion
- In case you didn’t move the SYSVOL replica folder from FRS to DFS, you need to halt the process of the File Replication Service (net stop NtFrs). After that, you can execute the regedit and head yourself to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/RestoreProcess at Startup.
In this particular tab, please change the number on BurFlags DWORD parameter to D4 (hex) on PDC and to D2 (hex) on any and every domain controller!
When you have gone through all those steps, you can safely start the connection service again. However, please don’t forget to see carefully if the directory name can be seen and shared from your device as a final quick side note!
That should conclude our guide on how to fix the error known as “an active directory domain controller (AD DC) for the domain could not be contacted”. You and your client can rest (or work) assured that everything is running smoothly from this point on. And should you run into any problems, please let us know!
Maybe you are interested in