lamontc
asked on
Corrupted domain controller replication
Hey experts;
I'm running a Win2k3 server as a global catalog DC for our company that also runs Exchange. We had an issue with Exchange/AD corruption a few weeks ago and I had to restore the system state using NTBackup. Somehow, AD didn't fully cooperate with me, and so I then demoted the DC using dcpromo and reinstalled it from another global catalog DC in a remote office.
The problem is that now, the restored DC is giving me continual replication warnings that it cannot replicate with the corrupted, previous version of itself that it thinks is still active. In AD Sites and Services, my DC has two "NTDS Settings"....one for my secondary DC, and one named "NTDS Settings
CNF:1569a4a2-45b2-47cb-803
I've attempted to delete this setting, but it will not go away. I've used ntdsutil.exe to try to clean up my DC's metadata, and when I try to delete the bad version, I get an error: The connected server will not remove its own metadata.
Any thoughts on how to fix this?
I'm running a Win2k3 server as a global catalog DC for our company that also runs Exchange. We had an issue with Exchange/AD corruption a few weeks ago and I had to restore the system state using NTBackup. Somehow, AD didn't fully cooperate with me, and so I then demoted the DC using dcpromo and reinstalled it from another global catalog DC in a remote office.
The problem is that now, the restored DC is giving me continual replication warnings that it cannot replicate with the corrupted, previous version of itself that it thinks is still active. In AD Sites and Services, my DC has two "NTDS Settings"....one for my secondary DC, and one named "NTDS Settings
CNF:1569a4a2-45b2-47cb-803
I've attempted to delete this setting, but it will not go away. I've used ntdsutil.exe to try to clean up my DC's metadata, and when I try to delete the bad version, I get an error: The connected server will not remove its own metadata.
Any thoughts on how to fix this?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
dcpromo /forceremoval
ASKER
I appreciate the advice, but I've already tried that stuff. When I get to the step 14 on http://www.petri.co.il/delete_failed_dcs_from_ad.htm, that's when I get the error: The connected server will not remove its own metadata. I can't proceed any further once that comes up.
The server was corrupted when it was demoted and then promoted again. Some kind of way it held onto it's own data, and I can't get rid of it now.
The server was corrupted when it was demoted and then promoted again. Some kind of way it held onto it's own data, and I can't get rid of it now.
How many DC's do you have on the domain?
ASKER
I've got two. Both are listed as global catalogs.
who holds the FSMO roles?
ASKER
The domain controller that is currently having problems replicating with it's prior self.
LOL:
Have you tried to seize the roles on the other DC, then demote it?
Have you tried to seize the roles on the other DC, then demote it?
ASKER
Yes. I've tried seizing the roles with ntdsutil...the problem is that the corrupted DC still shows up in AD. It's really, really weird. Doesn't seem to be causing any issues at present, but I'm concerned about the growth of the domain. If our personnel keeps growing and we've got a crappy AD foundation (with the corrupted DC), it might cause a real headache down the line.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
rehanahmeds offered some information that I also provided. Sorry about the redundancy. Please credit him for his input if this resolves your problem.
ASKER
You guys are awesome. I installed a virtual server on the same LAN as the corrupt DC and transferred over all roles. I then demoted the former DC to a member server and cleaned up the AD metadata on the new primary DC. After that, I just reversed the procedure (re-promoted the old DC back to primary) and voila, no more corrupt replication. It took me longer than I wanted to because I was running Exchange 03 on the primary DC and every time I rebooted it would take FOREVER to load, since Exchange couldn't see AD the way it wanted to.
But it's all resolved now. Thanks a million, guys!
But it's all resolved now. Thanks a million, guys!
I am curious, Why not just demote the server, and re build the demoted server? Why take a risk on anything being unclean on the server?