asked on

Domain Controller that contained the FSMO roles has gone down

I have a domain among a handful of schools that run the student labs. The Domain Controller that was first used in building this domain, and that houses the FSMO roles, has gone down as a result of a bad RAID card. A new RAID card was installed about 36 hour later and the DC was fired back up. However, their are now issues with this domain. No DNS communication, Group Policy issues, etc. since this DC that is the holder of the FSMO roles went down.

What is the approach I must take now.

I am thinking about seizing the FSMO roles and transfering them to another DC within the domain. Then, I would have to clean up the metadata for the DC that originally housed the FSMO roles and then re-add that DC back to the domain again using a different server name.

Would this be the correct approach or am I missing something here?

Thanks for your assistance.

Sean

Jonathan Raper

sounds good to me.

I would:

Seize the roles
demote the bad DC
Make sure AD is clean of the bad DC (ADSIEdit, etc)
I would format and resinstall the OS on the bad DC if you can....not just change the name. There are few things worse than a questionable DC that you're not sure you can trust.
then promote it back after the install (use a different name to be sure there are no discrepancies)

Hope this helps!

Jonathan

arnold

Was the RAID controller replaced and the system brought up as it was or was the RAID data unrecoverable such that the system was restored from backup?
If restored from backup, you are getting rid related errors?
The restore/bringing the DC from backup might have been a mistake.
One should never restore a DC from image when there are other DCs in the environment.
Where was/is the DHCP server?
Best approach is shutdown this server (failed DC with FSMO roles) if everything was functional when it was down before it was brought back.

You probably need to go through sites and services.ntds and make sure every remaining DC has a check mark in the GLobal catalog option.

In a multi DC environment, using ntdsutil one can seize the roles. And the repaired system can then be readded after OS reinstall.

.....

Usually the master DC restoration of AD has to go through non-authoritative restore, but that is not an option when the system is restored from an IMage/backup.

Mike

Seize the roles, demote the bad DC, unjoin the bad DC from the domain, do a metadata cleanup, reinstall the OS on the bad DC, join back to domain, promote back to Domain Controller, move FSMO roles back.

skenny10

ASKER

After the RAID controller was replaced, the system brought up as it was previous. There was no restore process taken. The DHCP server resides on another box at this same school. All other DCs were setup as GC servers as well.

Mike

What happens if you run repadmin /syncall and repadmin /showrepl from the "bad DC"?

Will Szymkowski

Would this be the correct approach or am I missing something here?

If the DC has been restored and you have the opportunity to transfer the roles gracefully I would try this method first. If you cannot transfer the roles gracefully then perform the role seize.

If this DC fsmo role holder is online (power it off) then perform the seize role operation. When you transfer the PDC role to another DC you will also need to ensure that you configure the external time source as well.

https://support.microsoft.com/en-us/kb/816042
http://blogs.technet.com/b/nepapfe/archive/2013/03/01/it-s-simple-time-configuration-in-active-directory.aspx

Make sure that you also transfer any other roles that this DC may hold DHCP etc before seizing the roles and powering it off.

When you seize the roles this DC that use to hold the roles can never come back online with that name/sid.

Will.

ASKER CERTIFIED SOLUTION

Lee W, MVP

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

SOLUTION