Forum Discussion
AD Connect Start-ConnectivityValidation - GetDomain failing error while running adding directories
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 Thanks you so much again for pointing us in the right direction. We have finally been able to resolve this issue. In the end, it was not a DNS or Network issue. Here are the steps that resolved it:-
1) By narrowing down the error in PowerShell by running just the Confirm-ValidDomains or Get-ForestFQDN commands and simultaneously running a live network capture on Netmon, we got a Netlogon error however, the service was always running in the Yellow DC and restarting it as well didn’t change anything.
2) Then finally the DS Engineers from MS team asks to collect the Netlogon & DC Diag logs. It becomes clearly visible that the Yellow DC isn’t advertising itself, hence we are asked to enable the SysvolReady flag is the Registry Editor by setting its value to 1. Upon rebooting, the AD Connect validation tests are successful.
LainRobertson Thank you so much for testing this out to the depth of the .Net class and ascertaining that DNS manipulation won't necessarily resolve our issue. These are indeed great details and finally I did manage to get hold of someone who knows Multi-forest identity sync very well.
Just 1 correction here and fortunately, we are dealing with this issue on just 1 forest right now and only 2 more are remaining which don't pose this same error. So, we need to allow the internal network access to the AD Connect's subnets for just 1 country/directory/forest. I believe all the previously onboarded 40-odd directories have this allowed probably, it increasingly feels like a pre-requisite now. I have actually, already asked the country guys to arrange for this configuration. Will post the update when it finally works.
The other 2 remaining forests pose the "Get-Forest not found" error and not the Get-Domain error. That one is a typical error due to lack of network connectivity or Yellow DC not being able to resolve all DCs to their FQDNs. They will get resolved as we have faced them earlier as well.
The short answer is I don't know, as I'm not privy to how the AAD Connect installation process works to that kind of depth.
You may not have a choice except to allow the AAD Connect host to have full internal access to all 40 forest/domains. The references on the AAD Connect requirements pages are vague and don't make it clear if what you're trying to do with a DMZ approach will or will not work.
I just finished some testing against the .NET "System.DirectoryServices.ActiveDirectory.Domain" class - which I expect is used in the installation wizard, in conjunction with some high-level Wireshark tracing and the takeaway is that the .NET class produces numerous domain controller references with no way to limit or order them.
The AAD Connect wizard could be utilising any of the properties - from the multi-valued "DomainControllers" to the single-valued xxxRoleOwner (and the Forest class is more of the same.)
If my assumption is correct then DNS is not going to help you solve this problem at all.
Again, the MIM Active Directory agent does not work this way which is why it can be directed to use a specific domain controller, and because the AAD Connect sync engine is indeed just MIM, it could work under this DMZ model. But if you can't get past the AAD Connect installation wizard for the above reasons then it counts for nothing.
You might be tempted to "hack" around the problem by temporarily granting the AAD Connect host access to all 40 remote locations' domain controllers but, of course, you'll only potentially run into the same issue when you have to re-run the wizard, making it not worth it.
DNS isn't going to solve your requirements on its own. Either give your central AAD connect host access to all remote domain controllers or stick with MIM. Or petition Microsoft via a design change request to alter the AAD Connect wizard to allow for the specification of a specific domain controller - if you're an influential-enough client to take that path.
Cheers,
Lain
- 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.