Forum Discussion
AD Connect Start-ConnectivityValidation - GetDomain failing error while running adding directories
Here's another AAD Connect-specific article that outlines in greater detail the port requirements:
It's considerably more useful than the previous troubleshooting article and provides a per component breakdown (including the wizard.)
As I said above, I feel your issue is with domain controller selection but this is still a very useful reference.
Cheers,
Lain
There are 4 DCs in the forest and 1 of them is in the DMZ, conditional forwarder in the ADC forward points to it.
Although I'm yet to check the Netlogon logs in the target forest, I noticed something interesting with the network connectivity tests. While the Confirm-TargetsAreReachable & Confirm-DNSConnectivity results are all green & successful, Confirm-NetworkConnectivity provides something to think about.
If I run this and DC1 doesn't have port 53 open, its gives an error and doesn't even check the next DC.
Confirm-NetworkConnectivity -DCs DC1.forest.com,DC2.forest.com,DC3.forest.com
TCP connection to DC1.forest.com on port 53 failed.
But if we mention DC3 first which has the connectivity, then it succeeds for it and then does check the next and then if it fails, stops checking further.
Confirm-NetworkConnectivity -DCs DC3.forest.com,DC2.forest.com,DC1.forest.com
TCP connection to DC3.forest.com on port 53 succeeded.
TCP connection to DC3.forest.com on port 88 succeeded.
TCP connection to DC3.forest.com on port 389 succeeded.
TCP connection toDC2.forest.com on port 53 failed.
Could this be the issue? Probably the lookup list has the internal DC as the first entry which doesn't have connectivity. Although an assumption, I'm more suspicious after seeing this result:-
PS C:\Program Files\Microsoft Azure Active Directory Connect\Tools> Confirm-FunctionalLevel -Forest forest.com
Verifying that the AD forest functional level is >= Windows2003Forest
Obtaining ForestFQDN
Attempting to retrieve ForestFQDN...
Exception calling "GetForest" with "1" argument(s): "The specified forest does not exist or cannot be contacted."
CurrentForestLevel is
The binary operator GreaterThanOrEqual is not defined for the types 'System.DirectoryServices.ActiveDirectory.ForestMode' and
'System.DirectoryServices.ActiveDirectory.ForestMode'.
At C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ADConnectivityTool.psm1:1127 char:8
+ If($CurrentForestLevel -lt $MinAdForestVersion)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException
The Active Directory forest functional level is correct
True
It fails in the beginning probably with the internal DC and then succeeds with the DMZ DC. This output is actually similar to the forest which were successfully onboarded to ADC. Just that the initial error statement is "The user name or password is incorrect." instead of "The specified forest does not exist or cannot be contacted". Rest all output is same including the "The binary operator GreaterThanOrEqual is not defined for the types" error.
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
Run Netdom query FSMO and check the PDC on that forest.
If PDC is DC1.Forest.com then need to fix the DNS on that DC first.
Run
Nltest /DsgetDC: Domain Name and check.
If that one shows DC then force it to DC3
nltest /dsgetdc:DCname -force
