Recover Active Directory from unbootable Domain Controller

[Pluto]

I have a Windows 2003 Server Active Directory Domain Controller that can no longer boot. It is the only Domain Controller (very small network).

I've tried doing a repair install to get the server booting with no luck. I think my only option now is to reload Windows server from scratch.

I will however have the contents of the C drive from the old installation, is there any way to recover the Active Directory stuff (user and computer accounts etc.) from it?

 

[Brazen]

There are some database files that you could probably copy from the old C: drive to the new one. I can't remember the default location now, but it asks you where to put them during the domain controller promotion. I believe there are 3 folders you'll need. Personally I always put them under a folder off the root drive called "ActDir" to make it easy in just such a case of recovery, but I can not remember the default locations.

I'm not a 100% certain this will recovery the Active Directory info, but it's probably worth a try.

 

[RebateMonger]

All the Active Directory stuff is in the System State section of any backups you have made. You must have at least ONE backup, right?

 

[Pluto]

we have a backup, im just not sure if it backed up the system state, gotta get a hold of it and check.

So there isn't a way to get that from the files on C? I found a utility called Umove that says it can do it, there must be a way to do it manually though.

 

[RebateMonger]

The Microsoft supported method of restoring AD is with a System State backup. That is, by far, the best way to do it.

If you find you have no System State backups, and a $130 program like UMove allows you to recover your AD directly from a hard drive, you should consider yourself very lucky. I'd jump on it.

 

[Pluto]

turns out the older version of NovaNet Web backup which is what we were using did not support System State backups, and when the latest client was installed no one ever bothered to go in and check system state

think I'm gonna try UMove, will report back with my success.

 

[TG2]

NovaNet Web backup ? never heard of it, good luck !

 

[Brazen]

A quick Google search shows that the database file I talked about earlier is called ntds.dit and is located in %systemroot%/ntds/ folder. You should just have to copy this over from the old drive. You'll probably have to boot into Directory Services Restore Mode (akin to Safe Mode, but on a Domain Controller) to overwrite the existing ntds.dit, or you may be able to use ntdsutil to copy the file over.

A simple google search of "active directory files" would have answered your question.

 

[Pluto]

Brazen, I have done that search, and found that information. However the noticeable lack of documentation on how to perform this procedure makes me think it's not quite as easy as you explained.

 

[RebateMonger]

PLEASE let us know how you solve your problem. Never know when some of us might need a reliable solution, too. Thanks.

 

[stash]

Originally posted by: Brazen
Crazy Stuff.

Good god, no. No no no no.

The ONLY way to restore a DC is to restore the system state. Copying files is a recipe for disaster.

There is MUCH more to AD than the dit file, most critically, the log files (its a transactional database!!).

There is also sysvol, which contains the GPT half of all your group policies.

Also, to make a server a DC you have to run dcpromo, which creates an entirely new database. You can't just copy ntds.dit to a server and turn it into a DC. And if you run dcpromo first and then try to copy ntds.dit over the new ntds.dit you'll have a complete mess on your hands.

It won't work.

You need to make backups. I can't tell you how many times I've had grown men crying on the phone with me when I was in EPS directory services in PSS when I told them there was nothing I could do to restore their AD that had NO backups and NO redundant DCs.

 

[stash]

You might be able to use the set path command in ntdsutil to set the new path for the dit and log files, but this is definitely a last resort kind of thing, and you really want to be on the phone with PSS if you're going to go down that route.

And don't forget sysvol.

 

[RebateMonger]

Originally posted by: stash
I can't tell you how many times I've had grown men crying on the phone with me when I was in EPS directory services in PSS when I told them there was nothing I could do to restore their AD that had NO backups and NO redundant DCs.

stash,
Too bad you don't have any recordings of this. It'd be great material for "America's Saddest Home Videos".

 

[RebateMonger]

Pluto,

After you get this out of the way, consider occasionally running "plain ol' NTBackup" on your Server occasionally (in addition to any other backup program you've chosen). It can be slow, and is missing features of current 3rd-party backup programs, but it WILL make a restorable backup and you can easily get support for it from Microsoft and local consultants if you need to do a bare metal restore.

 

[Brazen]

Originally posted by: stash

Originally posted by: Brazen
Crazy Stuff.

A lot of knowledge, very little understanding.

First of all, you don't need to be on the phone with anybody. Your original is already hosed, apparently, and you will not be making any changes to the original files anyway. If it doesn't work, no harm no foul.

Also, as I had said before, when you run dcpromo, it will ask you for 3 paths to store files (don't know the default off the top of my head). After you run dcpromo on the new server, take note of the default locations of those paths and try copying over the files from the old drive to the new one in those 3 locations. It might work in Directory Services Restore Mode; if not, trying putting the new drive as a secondary in a different computer and overwrite the files that way. Boot the new drive and see if it works. I would never count on this working, but at this point you have nothing to lose.

And by the way, some people don't seem to understand what the System State information is. Everything that is backed up from System State is information located in files. The only reason the files have to be backed up through System State is because the files are system files that are opened and locked by windows. Everything you get from System State ultimately comes from a file located somewhere on the harddrive.

 

[stash]

If it doesn't work, no harm no foul.

True.

If you are going to try overwriting the dit and the logs, you need to be in DS restore mode.

I don't think it will work because even if bring up a new DC and make a new domain with the same name as the old domain, the domain SID will still be different, not to mention the GUID of the domain controller itself. When you overwrite the DB with the old DB, the server will probably refuse to load AD completely.

 

[Pluto]

Originally posted by: RebateMonger
PLEASE let us know how you solve your problem. Never know when some of us might need a reliable solution, too. Thanks.

I rebuilt the domain and recreated all the user and computer accounts. It was a very small network so it really didn't take that long, so I couldn't justify spending more time or money trying to find a better solution.

My first order of business Monday will be making sure every other network I am responsible for has their system state backed up. You just can't trust RAID.

I suspect that stash is right about overwriting the DB with the old one, but hopefully I'll never know!

 

[RebateMonger]

Originally posted by: Pluto
I rebuilt the domain and recreated all the user and computer accounts. It was a very small network so it really didn't take that long, so I couldn't justify spending more time or money trying to find a better solution.

Probably the best choice in your situation. An emergency situation is NOT the best time to learn a new recovery technique.

My first order of business Monday will be making sure every other network I am responsible for has their system state backed up.

Great!

 

[stash]

You might want to think about adding a second DC, if you have a spare machine.

 

[Brazen]

Originally posted by: stash

If it doesn't work, no harm no foul.

True.

If you are going to try overwriting the dit and the logs, you need to be in DS restore mode.

I don't think it will work because even if bring up a new DC and make a new domain with the same name as the old domain, the domain SID will still be different, not to mention the GUID of the domain controller itself. When you overwrite the DB with the old DB, the server will probably refuse to load AD completely.

Well, I never meant to give the impression I was certain it would work. One of the links in the google search I posted did have information on using the ntdsutil to recover the database and logs and such, which MAY have taken care of some of the issues if running it after copying the files over. I will agree, though, that I doubt it would work.

Originally posted by: stash
You might want to think about adding a second DC, if you have a spare machine.

This is a VERY^100 good idea. And it's stupidly simple. We have redundant domain controllers, and have tested it's failover capabilities many times. NOTE: you do have to be mindful of FSMO roles if a domain controller is down permanently (ie. not down temporarily for maintenance), but the FSMO roles can be forceably transferred in an emergency (you'll want to read up on the issues surrounding this if you ever need to do it).

 

[DavMe]

Apologies for the necro thread revival. A friend of mine had this problem and needed to restore AD from the old physical boot drive and my google searches dropped me here.

I tracked down the umove utility discussed early in the thread here (https://u-tools.com/u-move) and lo and behold it does indeed save your bacon. Install it on the new server, select clone, dead disk, and if the finish button lights up then you are golden. If not, then you are rebuilding AD from scratch after all, but at least you are not wasting all day before deciding.

Thanks!
Dave