AD replication shafted!

[sparkeh]

ok I ll let you off

Hehe, but yes in principle I agree that usually I would build a new DC and transfer roles

[HallX]

Ok well that's not MS advice at all. MS actively promoted the benefits of virtualising, the advice is to retain one hardware DC.

 

OK. I'll not waste money on any more courses :-)

 

Are you sure they didn't mean perform a P2V conversion an existing DC?

 

No, I meant what I wrote.

 

Don't shoot the messenger.

[manick]

Hi all,

 

OK I can't do that as it won't let me demote DC2 because it can't see another DC to disconnect through.

 

Will Plan B work as follows?:

 

Create a DC3 and synch it with DC2 (this is the older AD, but it is only a couple of weeks out), then demote DC1 after moving it's roles over to DC3 (whilst DC1 is the latest version, I can live with 2 weeks worth of losses from AD).

 

Can anybody think of a reason this wouldn't work?

 

Thanks

 

Manick

[teejay]

The only reason to keep a physical DC is to avoid the single point of failure of a software bug in the virtualisation software. You could just as easily maintain a DC VM using different virtualisation software as an emergency, there is no benefit in it being a physical rather than virtual server. There used to be timing problems and all sorts in earlier versions of virtualisation software, which is why they recommended keeping a physical DC and definitely not do a P2V of a DC as the software wasn't designed for it. Nowdays that isn't the case.

[irsprint84]

Hi all,

 

OK I can't do that as it won't let me demote DC2 because it can't see another DC to disconnect through.

 

Will Plan B work as follows?:

 

Create a DC3 and synch it with DC2 (this is the older AD, but it is only a couple of weeks out), then demote DC1 after moving it's roles over to DC3 (whilst DC1 is the latest version, I can live with 2 weeks worth of losses from AD).

 

Can anybody think of a reason this wouldn't work?

 

Thanks

 

Manick

 

things I m thinking of but might nto be correct as never done before:

 

*DNS issues, computers etc.. you conneted in period

*Exchange Server/ Sharepoint issues?

*Where are you FMSO roles?

*You wont need to remove old DC with NTUTILS (I know spelt wrong) - Delete Failed DCs from Active Directory

[irsprint84]

The only reason to keep a physical DC is to avoid the single point of failure of a software bug in the virtualisation software. You could just as easily maintain a DC VM using different virtualisation software as an emergency, there is no benefit in it being a physical rather than virtual server. There used to be timing problems and all sorts in earlier versions of virtualisation software, which is why they recommended keeping a physical DC and definitely not do a P2V of a DC as the software wasn't designed for it. Nowdays that isn't the case.

 

I agree you can be completely virtual, HYPERV mostly needs a physical DC, though you can bring VMs back up after power failure, I just like have the knowledge I have a physical one incase of power failure

[alexsanger]

Hi all,

 

OK I can't do that as it won't let me demote DC2 because it can't see another DC to disconnect through.

 

Will Plan B work as follows?:

 

Create a DC3 and synch it with DC2 (this is the older AD, but it is only a couple of weeks out), then demote DC1 after moving it's roles over to DC3 (whilst DC1 is the latest version, I can live with 2 weeks worth of losses from AD).

 

Can anybody think of a reason this wouldn't work?

 

Thanks

 

Manick

 

Persoanlly I'd concentrate on getting DC2 reconnected rather than risk barfing DC1 as well. Have you tried the non authorative restore method on DC2 yet? If it cannot see DC1 have you checked the DNS on DC2 and manually added a record for DC1?

[prozario]

Bring up your DC1 and it will update the DC2 snapshots.

[januttall]

after a period of having one or both servers off replication will cease to happen

change the following REG Key on all servers

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Allow Replication With Divergent and Corrupt Partner click modify and change the 0 to a 1

force replication

change the registry key again

and it should continue to replicate

we had this on some of our 2008 servers after easter and the summer breaks as servers havent comunicated with each other in a cupple of days they need to be forced to accept the changes from one of the other DC'S. the servers tumbstone replication if turned off to prevent errors from relicating over all of the DC'S

 

there is a command to run to do this but i cant remeber what it was, or find it but the reg key does the same thing

Edited December 15, 2011 by januttall
Additinal Information

[mthomas08]

Dump it and re-build. Lesson - do not snapshot DCs! System State them, but with the nature of multiple DCs you should not need to have snapshots anyway.

 

Yeah, I did read about this and sometimes it doesnt work well to snapshot a DC only ever rely on the proper backup. I have just added virtual DC and it is the only virtual one. We currently have 3, when things settle I will remove GC from the email server (we are limited) and come next year I plan on having another DC so I can remove GC from our current DNS/DHCP (its the head of the forrest) and according to microsoft it shouldnt be a GC.....

 

As for the DC issue - do you not have a full backup?

[3s-gtech]

Yes, a bare metal backup to a USB drive on the main DC.

[manick]

Hi all,

 

Ok I've been away for a few days and left the network limping along (although not causing massive problems just yet). My plan was to recover DC 2 from a backup, however i noticed that, despite DC1 being a GC and owning all of the FSMO roles, when DC2 goes down, so does exchange!. So i need to figure out how to ensure that DC1 is being picked up as the GC on Exchange to ensure it stays working.

 

Also when I look at ADSI it shows the following USN No's

 

when connected to D1

DC1 current = 3296774

DC1 original = 13488

DC2 current=3373620

DC2 original=13407

 

When connected to DC2

DC1 current = 3556594

DC1 original= 215976

DC2 current= 3664622

DC2 original= 13418

 

Although DC2 is supposed to be the usn rollbacked DC, it is showing a higher USN. Should I be using this one to replicate from? and instead of demoting and promoting DC2, I should actually be carrying out this task on DC1?

 

The deeper i get the more confusing this seems.

 

Thanks for all of the info and help so far.

 

many thanks and merry Christmas!

 

manick

[sukh]

Which version of Exch?

[manick]

Hi,

 

It's Exchange 2007!

 

Cheers

[Firefox]

Sorry if I've missed something but I kinda just scanned the previous posts. From what I can tell, you're saying DC1 has an upto date copy of the database?

Can you not just do a dcpromo /forceremoval on DC2. Do a metadata cleanup from DC1, then manually delete DC 2 from DC ADUC.

You should then be able to add DC2 back to the domain and repromote it - forcing it to pull through a fresh copy of AD.

 

The only consideration you now need is your Exchange issue. Without knowing your setup I'm not sure why it's only reliant on this DC. Do you DC's current sit within different sites in sites and services? If so is the subnet for exchange added to the DC2 site? It should automatically look for another GC if DC2 fails, but I can't think of any other place you nominate 1 individual DC.