Link to home
Create AccountLog in
Avatar of Ralph Scharping
Ralph ScharpingFlag for Germany

asked on

AD sync between new and outdated DC


messed up, need help.

Network had two Domain Controllers each running 2012 R2.  Meaning to migrate, I added a third, running 2022.  Transferred the FSMO roles, demoted the first DC.  All looked well.

Now I noticed, that the new DC does not have a SYSVOL share.  *panic*

read this:

The command 

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

Open in new window

shows my new DC in state 2 (inital sync not yet finished) which explains the missing SYSVOL share.

The second (remaining old) DC is in state 5.

Looking at it, I notice a ton of 5008 and 4012-events.  Apparently it is still trying to reach the peacefully demoted DC that is no longer with us.  Also it sais, that it has not replicated right in 662 days (!) and would not continue to replicate.

Demoting it will not work - it says that it cannot reach a DC to take its computer account, and that I should make sure a DC is within reach before trying again to PROmote it.  Rats.

Now, DNS changes, deactivation of users, group memberships and such have been replicated just fine between the DCs.  I don't really have much in the way of GPOs or scripts - what I have I have exported and backed up.

My inkling is to just delete the old DC from the new one, but I would love to know how it is going to affect the new DC which is still waiting for it's initial sync.  Will it continue on it's own after it's only remaining replication partner is dead?

Any other ideas?



Avatar of CompProbSolv
Flag of United States of America image

So I understand: you had DC1 and DC2 on 2012 R2.  You added DC3 on 2022.  Transferred FSMO roles to DC3 and demoted DC1 (or 2).  DC3 doesn't have SYSVOL shared and is showing that syncing isn't complete.  Is that correct?

I'd try transferring FSMO roles back to DC2 (may not be necessary, but keeping this "clean"), disconnect DC3 (pull the net cable), and see if DC2 is doing its job properly.  I'd also run DCDiag on it.

If all is well, demote DC3, run DCDiag, and then promote DC3 again.  Don't transfer FSMO roles until DCDiag shows that DC3 is working as expected.

In addition to CompProbSolv's suggestion, did you migrate the SYSVOL to DFS before adding the 2022 server and moving the roles. This is a requirement. If not, the instructions from MS are here:

DC1 (demoted) and DC2 haven't properly replicated in almost 2 years?  Yikes.

I'd make backups of DC1 and DC2, then make additional copies of the SYSVOL folders on DC1 and DC2, and then try to promote DC1 again and see if it will take the FSMO roles from DC3.  If so, I'd demote DC3, fix replication between DC1 and DC2, re-promote DC3, make sure replication to DC3 was working, and then try moving the FSMO roles over there again.   

As a last-ditch effort I might restore DC1 from backup - from before DC3 joined the domain - kill DC2 and DC3 like they were lost in a fire, and then bring DC3 back in as a member server, promote it, and proceed from there.

I think you'll end up okay one way or another - you just need to figure out how much work you have ahead of you.  I hope you're able to take some positive lessons from this experience; I'd wager many of us have been in a similar situation:

Always have more than one DC.

Always do backups.

Periodically look for problems.

If you can't find any problems, you probably aren't looking hard enough.

Best of luck!

Avatar of Ralph Scharping


Hi everyone,  thanks for your suggestions.

@CompProbSolv:  yes, correct.

DC2 will not take any roles or anything - replication has been broken for nearly two years.  I don't think it will do any job.

@Rodney Barnhard: DFS has been migrated long before any of this started.  That is not an issue

@Paul MacDonald:  thanks,  I would rather not restore anything from anywhere.  DC1 was a physical machine, and it would be a hassle.  It would be possible, but not pleasant.

Can anyone tell me what would happen, if I was to just delete DC2 out of AD and from replication "like they were lost in a fire"?  Would DC3 give up replication efforts and just create a new SYSVOL share without taking any data from another machine?  It does everything else as far as I can see...

That would be my preferred path...

Sorry - not sure if I made myself quite clear:

the database of the DCs seem to be fine:  DNS and the content of AD Users and Computers, AD Domains and trusts and anything I touch seem to replicate just fine across both DCs even though one is in state seeding and one has broken replication.

The only thing that seems to NOT work is the filesystem replication of netlogoon and sysvol and their content.  But I have a backup of that, and it is not crucial to begin with.

Given I don't care much about the CONTENT of sysvol, if I burn DC2 and DC1 is already gone, can an orphaned DC3 get over it's grief and take up the job with a fresh sysvol share?  It already has the FSMO roles...

Avatar of Paul MacDonald
Paul MacDonald
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account

sooo... you were right.  Just shutting down the remaining DC2 leads to DC3 not finding any directory services at all anymore.  Which is hard to understand, because they each have their content, and if I change something they differ until replication evens out the differences.  Adding users to groups, for example, behaves just like it should.  But DC3 acts like it doesn't have a database at all, if DC2 is not reachable.

I am now looking through backups of DC1 and the possibility of restoring them to a different hardware, because I don't want to overwrite the old machine.  I'm not yet sure if that will actually work.

Does anyone think that I can somehow pursuade DC2, which is working fine but refuses to replicate because it was allegedly offline for 665 days, to resume normal operation?  How would I go about this?  Restoring an AD-backup from two years ago is not helpful...

"restoring them to a different hardware ": how tough/expensive would it be to throw some inexpensive hard drive in the old server and restore to that?

"it was allegedly offline for 665 days ": others here will give you a more authoritative answer, but my understanding is that the "tombstone" time for a DC is 60 days.  After that, I'm not sure if you can restore it successfully.  If you have a backup of DC1 that is less than 60 days old, I'd be looking at restoring that.

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account