AD Connect Start-ConnectivityValidation - GetDomain failing error while running adding directories

Ajay_Joshi 

Hi, Ajay.

A few random thoughts come to mind.

Firstly, if you want an authoritative answer on this, you're going to need to run a network capture on the AAD Connect host you're seeing the error on. But I'll put my first impressions here as well.

Domain controller selection

Next, AAD Connect and MIM have different starting points for the management agent configuration:

• AAD Connect limits you to completing everything it thinks it needs in the setup wizard;
• The Active Directory connector in MIM gives you complete control as-you-go.

Where this may be important is that the AAD Connect wizard does not let you specify a specific domain controller to connect to where the MIM management agents does. This wouldn't matter if AAD Connect could talk to any remote domain controller, however, given you're running a DMZ configuration, it very much matters. More on how this relates to your DNS request routing below.

As a side note, you do get full control over the management agent within AAD Connect (noting the "preferred domain controllers" option in the picture below) but only after you've finished the setup, leading to a chicken-and-egg scenario:

Figure 1: Preferred domain controller option - same for MIM and AAD Connect.

There's a number of ways you can detect a domain controller programmatically, including letting the underlying Windows system do it for you. I haven't had the need to crack open the MIM management agent and AAD Connect setup wizard to compare them, so I'll simply point out that you could easily get different results for both even if they were to be running on the exact same host.

I'd recommend running the more granular commandlets - almost all of them are useful - listed here as I can't help but think that while your DNS is indeed being directed to the remote DMZ domain controllers, the AAD Connect wizard is receiving an unordered list of domain controllers as the DNS response meaning it's then trying to establish subsequent connections to any random domain controller in that remote forest:

• Azure AD Connect: ADConnectivityTools PowerShell Reference - Microsoft Entra | Microsoft Learn

While you've run Confirm-DnsConnectivity, that's not nearly enough. A better indicator using this PowerShell module would be from Confirm-ForestExists and Confirm-TargetsAreReachable.

Figure 2: Using the AAD Connect diagnostic commandlets to see which domain controllers are returned and if they're reachable.

In contrast, perhaps a preferred domain controller has been entered into the MIM management agent (as above) though that isn't the only option, which brings us to your point on DNS.

DNS request routing != domain controller selection

As noted above, having DNS queries go to a specific domain controller doesn't guarantee that the same domain controller will be returned first in the DNS response.

Other factors such as your Active Directory topology (i.e. the defined sites and subnets) and whatever entries reside in your hosts file (in the case of your MIM host) will play a significant role in selection.

My educated guess is that the wizard does rely on the underlying Windows system to perform the check though, as the relevant .NET class throws that same error word-for-word:

Figure 3: Reproducing the error outside of the AAD Connect wizard.

Chances are that because AAD Connect is using a conditional forwarder and likely has no subnet assignment to the DMZ site (if one even exists) within each remote forest, it's sending a DNS query to the DMZ domain controller and coming back with a different domain controller to talk to. Again, this would show up very quickly in a network capture but you may also have some luck with the diagnostic commandlets referenced above.

Of course, it pays to remember that the error message covers two separate causes:

• Can't find the forest, which implies a name resolution issue;
• Can't contact the forest, which implies a firewall issue, which itself may be because the "wrong" domain controller was returned in the DNS response.

If it's the first cause, the above .NET-based check will fail very quickly. If it's the second cause, it will take longer (~ 9 seconds in my testing). That's a very unscientific test but a good indicator and quick to run.

Here's the command in text form for ease of reference:

[System.DirectoryServices.ActiveDirectory.Forest]::GetForest([System.DirectoryServices.ActiveDirectory.DirectoryContext]::new([System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Forest, "forestFqdn.somedomain.com"))

As I mentioned in the first section, I anticipate you're running into the second issue of not being able to reach the returned domain controller.

ICMP

This section is speculation on my part, as - again - I haven't done a network capture of my own to confirm any of this.

You've already listed the ports from the AAD Connect troubleshooting guide:

• Azure AD Connect: What is the ADConnectivityTool PowerShell Module - Microsoft Entra | Microsoft Learn

However, from the diagnostic commandlets documentation, we can see there's an ICMP test in the Confirm-TargetsAreReachable commandlet, implying that the wizard may also check for the ICMP protocol where the MIM Active Directory agent does not.

It might be worth allowing ICMP through from the AAD Connect hosts to the remote DMZs.

Other protocols

Other protocols I've seen used by other facets of the AAD Connect tool are:

• RPC: TCP 135
• WinRM: TCP 5985 (or TCP 5986 for WinRM/TLS)

I'd also strongly recommend enabling the following for better-secured AAD Connect-to-domain controller communications, although there is a bit of post configuration work to be done to enable this:

• LDAP/TLS: TCP 636, TCP 3269

Reference:

• Service overview and network port requirements - Windows Server | Microsoft Learn

These won't assist with resolving your error, but I figured since I've written this much, I'd include it anyway.

Summary

The AAD Connect wizard and the MIM (and AAD Connect) Active Directory management agent are different beasts.

What has worked for MIM in the past may not be enough for the AAD Connect wizard, and a network capture will provide the most authoritative answer to your question.

It's common for hosts files to provide a very small subset of responses that a conditional forwarder will provide. Be sure to compare the differences and not simply assume they provide the same results to the DNS client.

Cheers,

Lain