Active Directory Replication has stopped Error 8606

You shoud have left the new server.
Does the old DC provide any other functionality that would limit the following suggestions?
Your option is to make sure the current remaining DC is functional and has requisite data by removing the old/tombstone DC from network.
Backup the AD. Seize the roles making the live DC master of all roles ntdsutil .....
Then make sure replication is established/clean the metadata .......

You must approach this carefully now that you (know) only have one DC.

I would be hesitant at any attempt to revive the old/tombstoned DC.

how many DCs you have total

Is DC holding FSMO working as expected and in different location from current?

If above is true. simply discard old DC, clean metadata and build new DC

Ensure that AD ports are opened bi-directional between FSMO DC and other DC

DC hasnt replicated in 6 months time and its got set as dead and active directory has now stopped replicating.

You mention old DC not replicated in 6 months, to what? Do you have other DCs?

Start by disabling strict replication

HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Strict Replication Consistency
REG_DWORD
0

Select all Open in new window

I would be cautios on trying to restart application with a DC that has tombstoned records.
You have to first determine which DC has the most current information and make it the master if not through role seizing.

Replication restart could have unwanted results if the wrong DC asserts as the reference possibly knocking out valid data.

If the issue of replication deals with d2 bug (ad replication jrnl error) make sure you pick the right DC as the authoritative reference..

MS has a reference on fixing replication issues.
https://technet.microsoft.com/en-us/library/cc949120(v=ws.10).aspx

It is unclear why your replication stopped or the scale. Since it has been almost six months it seems more of a failure to replicate files than credentials.. As those would have manifested on intermittent login failures.


Repladm can show the replication status...

Can you please provide more information

Server6 is if main DC with FSMO, where it is located, in same location or another location separated from firewall?
If it in another location, are AD ports are opened as appropriate between both DCs?
We are trying to figure out replication issue here

As far as I understand, you should not keep old DC online if it is not replicating more than 6 months, you will find trouble more than you can handle with that

Also can you restart main DC (FSMO DC) and check if you get directory service event ID 1394 and FRS event id 13516 if you are running FRS sysvol? - check if file replication is running or its disabled, if its disabled, you have DFSR sysvol
If you are running DFSR sysvol, you would get event ID 1206
Also check if "net share" from command prompt gives you sysvol and netlogon shares
Post reboot run dcdiag /v and share output here

Mahesh.

so server2 is the old DC which is not replicating to FSMO DC along with new DC, correct?

Then just remove server2 along with new DC as well, may be you cleanup metadata and then try to promote new DC at location A

It should work

So on the server that's causing the issue do a dcpromo /forceremoval this will then update the ad at other sites indicating it's no longer in the domain

A forced demotion doesn't update any other domain controllers like a regular demotion. That's why the metadata cleanup is necessary afterward.

I can then add a new server with GC . DNS and dhcp to run the site?

After you perform a metadata cleanup, you can add the new DC. (Technically, there's nothing preventing you from adding a new DC right now, but it'll start generating errors as it tries to replicate from the DC with the problem. Best to get that taken care of before adding the new one.)

And a forced demotion is not required if you are going to trash/rebuild the server  and do a metadata cleanup

That's a good point: if you're going to reload the OS on that server, skip the forced demotion and just shut it down, then do the metadata cleanup. Just don't bring that server back up without wiping the OS.

Not sure whether the error ...
https://support.microsoft.com/en-us/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-service

WHICH replication do you have errors with FRS or DFS-R?
https://support.microsoft.com/en-us/help/2028495/troubleshooting-ad-replication-error-8606-insufficient-attributes-were-given-to-create-an-object
rejoining the domain might reinitialize.

running the repladm /showrep may point to the issue.  Does the system have two NIC or appears with two IPs in DNS.......

To resolve the issue, identifying what the issue is besides the no replication and the possible causes for that. some errors dealing with failed replication include a remedy similar to the registry fix that tells AD on boot to ignore and reset the .......


Thus far other than the error number and the general statement it is hard to determine what the underlying cause is to provide any additional suggestions ....

It's a nighttime job rather than a weekend job, unless you uncover other problems that prevent it from going as smoothly as it should. If all goes well, the whole job can take less than an hour.

After you force the demotion, that server will no longer be a domain controller, but other roles (as long as they're not dependent on the server being a DC) will still function exactly as before. After you complete the metadata cleanup, other DCs will no longer try to replicate with that server, so replication errors should stop appearing at that point. As long as there aren't any other issues, you should have no trouble promoting the new DC at that point.

A non-DC can still be a DNS server, but AD-integrated DNS zones won't replicate to it automatically. Zone transfers have to be configured in that case.

You shouldn't have to worry about that, though, if you're doing this after hours. You can complete the forced demotion, metadata cleanup, and promotion of the new DC in the evening, and everything will work smoothly by the time users arrive the next morning. (Make sure the local DHCP server gives out the new DC's address for DNS.)

You need to add on the new one services for Windows 2003 to maintain sysvol frs replication. After you only have 2003 R2 and newer can you transition sysvol from frs to dfs-r.

If your new DC is 2008 and newer, I would think you forgot to add the services for Windows 2003 and this is what hampers your replication.

You need to add on the new one services for Windows 2003 to maintain sysvol frs replication.

I'm not sure what you're referring to. Nothing except the AD DS role needs to be added, as FRS is built into all versions of Windows since Windows 2000. Even though it's no longer the preferred method of replicating SYSVOL, a new DC can (and will) still use it if that's the method being used in the domain when the new DC is promoted.

In any case, SYSVOL replication and AD replication are separate things. According to the information given by the asker, AD replication is what's been failing here, and that's what's caused the old DC to exceed its tombstone lifetime.

It is not since 2008 one has to add the feature to maintain frs replication with pre 2003 R2 where FRS is the only file replication service while past 2003 R2 dfs-replication was made available.
MS then has a writeup of transitioning the sysvol replication from FRS to DFS-R
https://technet.microsoft.com/en-us/library/dd640019(v=ws.10).aspx
I only have suggested the user perform the dcdiag and repadm to verify what the issue might be.

It is not since 2008 one has to add the feature to maintain frs replication...

What feature? I'm looking at a 2012 R2 server right now, and there's no feature called "Services for Windows 2003" or anything similar to that.

Dave,

Ref ms technet article
https://technet.microsoft.com/en-us/library/jj127250(v=ws.11).aspx

I noted the feature for FRS on 2008 is a feature under fileserver role if not mistaken named services for Windows 2003 which includes the FRS related services to deal with sysvol sync.

Additional ref on FRS
https://msdn.microsoft.com/library/ff384840.aspx

This is from the second article you linked above:

A Windows Server 2008 R2 domain controller can still use FRS to replicate the contents of the SYSVOL share in a domain that uses FRS for replicating the SYSVOL share between domain controllers. However, Windows Server 2008 R2 servers cannot use FRS to replicate the contents of any replica set apart from the SYSVOL share.

You're never forced to migrate SYSVOL from FRS to DFS-R, even though I agree that it's a good idea. There are probably domains nowadays running nothing but Windows Server 2016 DCs which are still replicating SYSVOL via FRS, simply because the admins have never felt the need to migrate it. (They'll get sick of those journal wraps one day, I'm sure.)

Drdave,
I never said one must migrate sysvol, I said one could.
Second, I never said one should use FRS as a means of replication of any other share.
Your last comment directly contradicted your prior statement that FRS has been included in all Windows server products since 2000 (though a variation was initially included in Windows NT which was I believe the first Windows is that dealt with centralized management if both users and systems) to enable FRS on newer one must make sure the feature is included which is not included by default. A situation similar to the asker's arose. I came in and identified that the fileserver role feature of service for Windows 2003 was not added on the Windows 2008 r2 DC that and the noted jrnl (D2 burflags) had to be applied to fix the combination of the issues.

Mentioning the option and availability of sysvol migration from FRS to dfs-r when there are no DCs pre 2003 R2(which shoukd be that case since 2003 ended a few years back) will remind those to consider/plan.......

to enable FRS on newer one must make sure the feature is included which is not included by default.

This is not true on a domain controller. FRS does not have to be manually added to a domain controller if it's only going to be used to replicate SYSVOL. (Incidentally, neither does DFS-R.)

I'm not even sure why we're talking about SYSVOL, to be honest. This is a tombstoned DC, and SYSVOL has nothing to do with that.

The complaint is that a new DC was added and replication failed. Upon the discovery by the asker of the failed replication and error 8606..... the asker discovered the tombstoned DC.
So the issue is multi situational.
1) How to achieve/fix what was preventing replication on the newly added DC (which the asker since removed)
2) Identify the reason a DC was tombstoned.

To addres 1, the likely lack of replication of a new DC in an old domain is the lack absence of the FRS related services on the New DC.

TO identify the cause of the tombstone'd DC is a separate track the asker seems to have possibly identified that related to DNS which I might not be the case since the DNS/AD replication relies on other matters as an AD zone wil presumably have two DCs (SOA records) and an update of a record on one will auto trigger a DNS notification of the change to the other.........

Having said that, sicne the asker merely referenced the error 8606 and not the full error content that can narrow the error to a specific item or deficiency, looking at error 8606 in the context of AD  pointed to the remedy some used with the registry adjustments.....

I too have at times locked in on a section of the question, at perhaps I did in this case placing too much emphasis on the resolution of the replication issue.

My perspective on this is that there's a tombstoned DC that needs to be removed from the domain, using the methods already described, before any other DCs can be added. The tombstoned DC is the showstopper here, and the 8606 errors should go away once it's been removed. I don't believe the asker has said anything about a SYSVOL replication issue, but if there is one, it can be addressed after the tombstoned DC is gone.