Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

AD replication

Status
Not open for further replies.

Stin0

IS-IT--Management
Nov 8, 2006
21
BE
Hello you all,

Scenario:
3 DC's on 3 different site's/subnets in 1 domain
They are Virtual Machines on a Ubuntu-box.
They all replicated until recently, nothing changed except
that we had to put back a snapshot due to a corrupt file in our VM. it is the same DC, but from a few days back...

Since then it refused to replicate.
Problem is that this DC is our Global catalog.
The other 2 are replicating. At least I don't see any errors in replmon for those DC's.

Does anybody know what the problem is?
If I demote the GC. Do I promote one of the others to GC. Demote the broken one, put it in a workgroup... promote it again and make it a GC again?

Is this the way to go?
I could use a step by step guide, but that's out of the question I guess... ;-)

Anyways, any idea's?

already a big thanx 4 the help
 
The proper methods of restoring a DC are: authoritative restore, non-authoritative restore, or re-installation. In your scenario, it sounds like re-installation (i.e. demote/promote) would be the way to go. Sieze the GC role on one of your other DCS, demote your problem server, and then dcpromo it back into the DC role.

 
You have three options:



1. Demote or reinstall the machine(s) that were disconnected.

2. Use the "repadmin /removelingeringobjects" tool to remove inconsistent
deleted objects and then resume replication.

3. Resume replication. Inconsistent deleted objects may be introduced. You
can continue replication by using the following registry key. Once the
systems replicate once, it is recommended that you remove the key to
reinstate the protection.

Registry Key:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication
With Divergent and Corrupt Partner
 
Yeah, never restore a DC from a snapshot or an image for that matter. USN rollbacks and lingering objects as techymcse2k mentioned are potential problems. Dis this DC hold any FSMO roles??
If it did then transfer/seize them to another DC and then demote server and promote again to a DC.

If it did not hold any fsmo roles then the best way to get AD consistent again is going to be to demote and promote that machine to a DC again.

Look for event ID 2095 which will indicate USN rollback (assuming you have SP1 installed on the DCs)

Paul
MCSE 2003
MCSA 2003
MCITP Enterprise Administrator

If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?
Scott Adams
 
You should have a GC in each site anyway, there is no need to seize the GC role, it's just a check box in "Sites and Services". If bandwidth between sites is an issue consider using a "caching only" GC.

John
 
So if I go in sites and services, and tick the GC-box... that will be ok?

Then I need to demote the broken DC, and promote it again after i have put it in a workgroup.
And tick the GC-box again.

I tick every GC-box in every site?
bandwidth isn't really an issue. but it would be nice to have a GC in every site. That way if our VPN drops out, authentication or AD additions don't need to be verified by our Main GC...
(is this way of thinking correct?)

Thanx for the answers already...

Stijn
 
So if I go in sites and services, and tick the GC-box... that will be ok?

Yes

Then I need to demote the broken DC, and promote it again after i have put it in a workgroup.
And tick the GC-box again.

Yes

I tick every GC-box in every site?
bandwidth isn't really an issue. but it would be nice to have a GC in every site. That way if our VPN drops out, authentication or AD additions don't need to be verified by our Main GC...
(is this way of thinking correct?)


Is this a single domain forest?? If so then MS recommends that all DCs are global catalogs, so yes make every domain controller a GC.

Bandwidth won't be an issue anyway as there is no extra replication traffic with every DC also being a GC in a single domain forest.

Also I'd still check your event logs for event ID 2095 to check for an USN rollbacks.

Paul
MCSE 2003
MCSA 2003
MCITP Enterprise Administrator

If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?
Scott Adams
 
Ok,

Just ticked every GC-checkbox of the DC's in every site...

Yes we have a single domain forest.
The thing is, that we still have to wait to demote the broken DC. As it still works and everybody needs it to be online.

Keep you posted of our progress..

Thanx for the help, and hopefully we'll get it back running soon.


Stijn
 
Another question...

I checked te FSMO roles. They are all dedicated to the broken DC...

Which of the roles do i need to transfer to another DC?

Thanx

 
We simply transferred all FSMO roles to another DC.

This wasn't as easy as we thought.
The RID-master role was the one who caused for some frustration.
Eventually we used ntdsutil to transfer the specific RID-role...
It said it failed, but when we checked all was ok...

After that we could easily demote the broken DC, and promote it again.
AD replicated fine and works like a charm for now =-)

Thanx for the excellent help!


Regards


Stijn
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top