Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There's plenty of administration literature out there how to properly manage Windows servers. But in dealing with real life, things don't always occur like you want them to. In Microsoft's Windows Server 2003 Administrator's Companion, out of 1400+ pages, theres only one page that I could find when it comes up setting up additional domain controlers. They make it sound seemless and don't reveal a whole lot on what happens if "peer" DC's are unable to replicate.

Down to the specific issue at hand, we had a DC go down about a month ago due to a bad RAID controller. There was nothing critical that waranted imediate attention, so bringing it back up got put on the back burner. A month later, we get the DC back up and running and everyting seemed ok. The next day, nobody is able to logon complaining that the "user does not exist" or "unable to establish a trust relationship". Knowing that I had just put the downed DC back on the network, I immediately took it back off the network and had everybody restart the workstations. After that, exchange was fine, shares became available, and everybody was able to log in. After doing some event log swimming, it would appear that everything started due to replication issues on the SYSVOL. I've read where you can force replication, but that would mean putting it back on the network. I am afraid to put the DC back on the network in fear that something else could go wrong. So, what other issues could one expect to run into where two DC's are unreplicated for over a month?

share|improve this question
Is the new DC that is working a GC? – TylerShads Nov 22 '11 at 16:05
I would think it would have to be (or there's another GC laying around) or logins would have started failing immediately after the second DC failed. – Driftpeasant Nov 22 '11 at 16:16
up vote 4 down vote accepted

Depending on the length of time they're unsynced, you can run into a situation where one reaches its Tombstone Lifetime after which you start getting issues with deleted objects coming back to life. That being said, the minimum default is 60 days, so you should be okay if it's been less time than that.

The way AD (and DNS and a host of other services) deals with sync issues is by incrementing a serial number each time changes are made. So if you've been using PRIMARYDC and making changes, SECONDARYDC will have a lower number and will defer to the higher one.

If you're REALLY concerned, you can always wipe SECONDARYDC, manually rip it out of Active Directory, reimage it, then gracefully promote it to be another DC. I think you're safe with bringing it online and resolving your SYSVOL issues though. If you want to be extra paranoid, do it after hours so that you don't get inconsistencies while you're resolving SYSVOL.

EDIT Adaptr below makes a good point - make sure there are no FSMO roles assigned to SECONDARYDC before you wipe it, if you choose to go that route.

share|improve this answer
It's certainly worth running netdiag and dcdiag and replmon, just off the top of my head. Do some diagnostics first to make sure the diagnosis of the issue is correct, you don't want to just bull ahead when you're playing with your AD. – mfinni Nov 22 '11 at 16:09
If you are unsure whether a new DC was added successfully, run dcdiag and make SURE that the output is correct BEFORE moving FSMO roles to a new DC ! – adaptr Nov 22 '11 at 16:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.