NTDS.DIT - Can I copy from one DC to Another DC

I would say this is dangerous at best but I would be interested in the results if you try it :).  Microsoft specifically states that you cannot use the backup of one domain controller to complete a non-authoritative active directory restore to another domain controller.  This may be a result of ntds.dit being included as part of the system state for backup purposes.

You can move NTDS.DIT on the same domain controller without problem.  You can back it up and restore to alternate location.  You can do an offline defrag and copy the new file over the old file but I never thought of copying from one domain controller to another.  Might have to test that sometime if you don't try it.

The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.

So,do DC1 and DC2 have the exact same role in your domain, ie if one is global catalog server and the other is domain controller then the answer is NO.  You should not copy from 1 to 2 because the content is different and may present major issues into your replication.

If they do have the same role, you might get away with it.

With that said, I would probably just roll up my sleeves and rebuild the server rather than create unknown potential problems within my replication scheme.

I didn't see Chipm0nk's answer before posting.  I ditto his dcpromo recommendation.

Just an after thought, you have backed up your data on this disk now, right?  Highly recommended before proceeding :)

Good Luck.

T.

I will take the following actions when I get into work:

1) Backup my data
2) seize the fsmo from this domain
3) demote this DC
4) try copying the database from other controller
5) re-promote DC

I will post the results...if this does not work, then I will rebuild.  

If you are demoting the problem DC and then re-promoting it, why would you want to copy the database over?

If problem domain controller still contains path pointers in registry for database then copying NTDS.dit from working domain controller or backup should resolve your problem.

By copying the NTDS.dit file and the log files from working controller to the one not working...did not work.  

Should I not have copied over the log files too?

It should work. Did you run NTDSUTIL.exe from DSRM?

No I did not...what exactly must I run?  Also, so is it correct for me to overwrite basically the whole NTDS folder in Winnt with the working DC?  Thanks.

Okay...before I demote that DC, I was trying to seize the fsmo.  I was successful in seizing 4 of the 5...the last one was the Schema.  I found a similar issue in Expert Exchange but not quite.  I am getting an access or rights error.  When I look at it more closely from the Active Directory Schema Master Operations, it shows that the bad DC still has control.  BUT I cannot seize because it is offline.  I cannot bring it back online because of my initial problem.  Any suggestions?  Once I get throught this, I believe I can follow ChipmOnk's suggestion and demote the bad DC and then bring it back as a DC.

Any idea on what I can do next?  Thanks everyone so far...I'm inching toward a solution.

The account you are using to seize the Schema must be a member of the Schema Admins group.  The only account that is a member of this group by default is the Administrator account.  Just a thought.

Yes...the account I'm using does have Schema Admin.  When I click on the Change button, I get the following error msg:

The requested FSMO operation failed.  The current FSMO holder could not be contacted.  The transfer of...could not be performed.

Again, the original problem is that I can get the DC that is holding the last FSMO to transfer back up and running in regular Window2000 mode (I'm in restore mode now).

Tonyinwv, first, thank you for responding to this post.  I tried out based on your instructions, but this time instead of stating that the DC was offline, it simply states that it fails.  I checked and the bad DC still holds the schema master FSMO.

After further research, there is some good news.  No one will miss your Schema master in the short run because it is only needed to modify the schema, such as when you install Exchange.  So at least your network is not going to crash down around you :).

I have read several articles regarding the failure to seize schema role.  All of them point to the AD being too busy when the attempt was made.  Everything I have read said they simply tried again later.

My only other gut feeling is this; Is your DNS configuration correct?  As you know, AD doesn't exit without DNS.  Since schema is stored in AD, could DNS cause an issue?  Just a thought.

T.

Tonyinwv....again, thank you for all of your research.  The one thing is that the DNS server was on the bad DC and I manually re-created one on the good DC.  Could I have missed an entry?  I do have a DNS entry for the bad DC and one for the good DC.  Let me check that possibility out.  

Resolved the issue by taking the old server out of the network and seized the Schema master (forced).

Once I did that, I use dcpromo and demoted the server from the forest.

Then, re-join the server as a member.