replication issues at remote site

Question

Hello,

I am having some replication issues at a remote site that I can't quite pin down after upgrading domain controllers.

I started with two virtual DCs at headquarters, DC2012A and DC2012B. The remote site has a physical DC that I'll call DC2019Rem. Those were all in place for the better part of a year with no issues.

I began an upgrade at headquarters. I spun up two new virtual servers, DC2019A and DC2019B. I promoted them, installing AD, DNS, etc.

I started transferring FSMO roles. DC2012A held two roles and DC2012B held three. I transferred all three roles from DC2012B to DC2019B. I did it slowly over the course of a couple of days to monitor for issues (unfortunately, it didn't occur to me to check the remote site at that time). The process seemed orderly and everything seemed to go well. I demoted DC2012B and uninstalled the AD tools.

I then transferred both FSMO roles from DC2012A to DC2019A, and that's as far as I've gotten because I became aware of the replication issues remotely at about that time.

If I run "netdom /query fsmo" on any of the remaining three DCs at headquarters, the results are what you would expect: DC2019A now holds two roles and DC2019B holds three. However, if I run the same command from DC2019Rem at the remote site, it shows DC2019B holding its three roles, but the old DC2012A still holding the two roles.

I have also located some objects that don't seem to have propagated to the remote site: a user in AD, a couple entries made in DNS, and a Group Policy (none of which are related to the DCs).

The event viewer doesn't show any errors in the past week for DNS, and if I run "repadmin /replsummary" on any DC, it shows all the DCs I would expect to see, no errors, and deltas are all under an hour.

Sites and Services still showed DC2012B, so I deleted it at both ends. The other three DCs are there, though. Weirdly, I changed the timing on DEFAULTIPSITELINK from 180 minutes to 60 minutes at headquarters, and that seemed to propagate to the remote site after awhile.

I read an article which suggested that moving DCs can cause similar issues and that if I wait, it will sort itself out, but it's been several days now. I am not certain what the root issue is or how to proceed.

Any assistance would be appreciated.

Thanks,

Zachary Hamilton

Answer 1

but the domain functional level is 2012 R2

That's fine, just be sure that DFSR is used and not FRS for replication.

None of the three DCs at headquarters are reporting any errors.

Sounds like the simplest solution may be to demote the remote one, reboot, promo it again.

--please don't forget to Accept as answer if the reply is helpful--

Answer 2

The two prerequisites to introducing the first 2019 domain controller are that domain functional level needs to be 2008 or higher and older sysvol FRS replication needs to have been migrated to DFSR
https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Streamlined-Migration-of-FRS-to-DFSR-SYSVOL/ba-p/425405

I'd use dcdiag / repadmin tools to verify health correcting all errors found before starting any operations. Then stand up the new 2019, patch it fully, license it, join existing domain, add active directory domain services, promote it also making it a GC (recommended), transfer FSMO roles over (optional), transfer pdc emulator role (optional), use dcdiag / repadmin tools to again verify health, when all is good you can decommission / demote old one.

You can also try a non-authoritative synchronization
https://learn.microsoft.com/en-US/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

--please don't forget to Accept as answer if the reply is helpful--