Forum Discussion
AD Connect Start-ConnectivityValidation - GetDomain failing error while running adding directories
I just want to re-iterate what I said in my first post:
Controlling where DNS goes (via your conditional forwarder) does not control where subsequent traffic for other protocols - such as LDAP - goes.
TCP/UDP port 53 is DNS and this is not your issue, meaning you can ignore this DNS-specific error.
As you said, you are using a conditional forwarder for the remote forest, and the server entered into the conditional forwarder is only pointing to the IP address of the DMZ host. This means that DNS can only go to that one specific domain controller, making DNS connectivity tests to the other domain controllers irrelevant.
What we are focusing on are the non-DNS conversations between your AAD Connect host and the remote forest, as these are not controlled by the conditional forwarder. These are the conversations that are likely trying to use the internally-located domain controllers, since all five are returned to the AAD Connect host.
As I said earlier, there's a number of different strategies for solving this issue, however, the most future proof is the one I mentioned in my earlier reply about using Active Directory sites and subnets to solve the domain controller selection issue.
Quoting from the following article, this is what I'm talking about:
After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client.
If the client is communicating with a domain controller that isn't in the closest (most optimal) site, the domain controller returns the name of the client's site. If the client has already tried to find domain controllers in that site, the client uses the domain controller that isn't optimal. For example, the client sends a DNS Lookup query to DNS to find domain controllers in the client's subnet.
Otherwise, the client does a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.
While this represents the best solution (in my opinion), there are other DNS-based solutions such as:
- Using DNS policy (if the remote domain controllers are Windows Server 2016 or later);
- Manipulating the DC locator DNS records (you need to know what you're doing with this one or it negatively impacts everyone);
- Using a split-brain DNS approach (more control but at the cost of extra and ongoing manual administration);
- hosts file (I'm really not a fan of this one but it is an option.)
Of these lesser-preferred options, I'd recommend option 1. Here's a link to DNS policies:
The problem you're now trying to solve is not "where is DNS going to?" but "where is everything after DNS going to?"
Here is another article that lists the various DNS queries your AAD Connect host (which in this context is the DNS client) can ask of the remote DMZ domain controller, though don't invest too much time reading this one as it's purely educational (for now):
Your focus for now is getting a random selection from a pool of five domain controllers down to consistently selecting the DMZ domain controller for non-DNS traffic. Using the aforementioned sites and subnets approach, or one of the lesser-preferred DNS-related configurations should be your priority.
Cheers,
Lain
LainRobertson Supernova Thanks for providing inputs, I've tested a lot of things.
Firstly, the Netlogon logs have this error:-
03/22 12:14:38 [7968] Forest.com: NO_CLIENT_SITE: ADConnectServerName ADConnectIP
Strangely, MIM server too has the same error entry, but as mentioned earlier, might not matter in its case.
Nltest /DsgetDC:forest.com indeed returned the primary DC to which AD Connect doesn't have connectivity. This is the issue I think.
Since, the primary DC is in Default Site, I changed the SRV records on it to point to the DMZ DC. Need to wait for replication.
Meanwhile also trying to understand the DNS Split brain approach and using DNS policy. I'm unable to find a method that cane be used to force the DMZ DC to return its own name to DNS queries rather than the PDC's.
This is what you want to focus on (at least, if you want to achieve the best outcome), and what I have come back to in the previous two posts now:
The following is not sound advice and the final paragraph is factually incorrect:
The error from the AAD Connect installation wizard doesn't strictly relate to speaking directly with a FSMO role holder, either.
As I outlined earlier, this error can be resolved by doing the following in the remote forest:
- Create a new site for the DMZ;
- Create a new subnet matching the IP range of the DMZ and attach it to the site;
- Create a new subnet matching the IP range of your central subnet hosting your AAD Connect hosts and attach that to the DMZ site.
You'll now find that the netlogon.log entries stop and the DMZ domain controller is reliably returned as the appropriate domain controller.
Separately, don't edit domain controller-owned DNS SRV records directly. This can break your environment if you're not completely aware of the effects of doing this. You'll likely also lose any changes you made within 24 hours when the NETLOGON service from the owning host refreshes the record (unless automatic registration has been disabled, which also should not be done unless there's a compelling reason.)
Cheers,
Lain
LainRobertson Thanks yet again Lain, for the detailed action plan. Since the site for DMZ already existed and the subnet with IP address was also attached to it, I completed the last important step by creating new subnets for the IP ranges of ADC staging & prod servers and attaching that to the DMZ site. However, this still hasn't resolved the issue and the errors persist at both ends.
I've captured fresh network traces at both sides, can't upload them here as .cab & .etl files are not allowed. I have serious trouble reading them using Netmon. Will ask MS to analyze them.
- LainRobertson MS is suggesting DNS Split brain policy for which our management is not agreeing as 40 other countries didn't need it. Is it ok to allow the network connectivity with the internal DC network in addition to the DMZ DC? Would that be a good approach considering that AD Connect does contacts all DCs once while setting up the directory. Does this happen in other companies too? Seems to me like defeating the purpose of the DMZ altogether.
Ajay_Joshi Try below steps first:
Run nltest /dsgetdc:DC3.domain.com /forceVerify whether it actually pointing to DC3 nltest /dsgetdc:domain.com
This will temproarily resolve the issue and further you can do the neccessary test, once test successful,
For permanent solution you can try below steps to force all the queries to DMZ DC3.
To force the DMZ DC to return its own name to DNS queries rather than the PDC's, you can try the following steps:
Log in to the DMZ DC using an account with administrative privileges.
Open the DNS Manager console.
Right-click on the server name and select Properties.
In the Server Properties window, click on the Forwarders tab.
If any forwarders are configured, clear the list by selecting each entry and clicking Remove.
Click the Root Hints tab and select the option "Do not use recursion for this domain".
Click OK to save the changes.
Restart the DNS Server service on the DMZ DC.
These steps will ensure that the DMZ DC returns its own name to DNS queries rather than forwarding them to the PDC.- To force the DMZ DC to return its own name to DNS queries rather than the PDC's, you can try the following steps:
Log in to the DMZ DC using an account with administrative privileges.
Open the DNS Manager console.
Right-click on the server name and select Properties.
In the Server Properties window, click on the Forwarders tab.
If any forwarders are configured, clear the list by selecting each entry and clicking Remove.
Click the Root Hints tab and select the option "Do not use recursion for this domain".
Click OK to save the changes.
Restart the DNS Server service on the DMZ DC.
These steps will ensure that the DMZ DC returns its own name to DNS queries rather than forwarding them to the PDC.
