server 2003 system state backup/restore

[n00bius]

Had a question, if a server crashes, completely, i.e. complete failure, and the data isn't recoverable, and the server can't be reused, can you do a system state restore after a clean install on a different hardware platform? (same processor architecture)

[Gillis57]

Noobius, I will consult my server admin book shortly- But I dont BELIEVE that it would be possible to retrieve the info... I'll repost shortly with a correct answer, or to let you know if I can't find it- Is it Urgent?

[SirDice]

Only if you've made proper backups...

Why do people think about backups when it's really too late?

[n00bius]

lol, actually, i'm doing this preemptively, haven't had a server failure...yet. But I just wanted to verify that if one had sufficienct system state backups (i.e. not outside of tombstone lifetime), how much time, and what would be the process/limitations of restoring the domain controller into AD as well as bringing it back to full functionality.

oh and Gillis57, I don't want to recover the data, but I want to recreate the server from a previous system state backup before the server crashed.

[dinowuff]

You want to restore a completely failed AD Controller? Real world That ain't going to happen.

Here's why.

Someone, somewhere has made some type of change - of course only documented on a sticky pad - that you are not aware of. Further, you don't have a backup since the last AD Replication.

So what you have to do is restore registry settings from backup, but first you MUST ensure that your patch level is exactly the same as when you did the backup. Also, if you try to add the server back to the domain with any domain role, AD is going to bitch and moan. So the only way to restore a domain role to an exact previous state is to do the restore off line. (That's going to take some registry edits that, in the long run, will drive you nuts.

Now remember that (If your domain is even half assed set up correctly) AD figures that this server is turned off. After time, AD will assume it's off line for good. More registry edits to what ever the primary DC is and then let replication take place.

Cross your fingers, turn on the server and plug in the nic. First thing you'll notice is that the database is out of sync and a replication request has been issued. Next, WINS starts whining that its database is incorrect and starts to tombstone all records related to your new install (Until the next rep cycle)

Remember that undocumented change you knew nothing about? Yea that's either going to blue screen you or cause some AD Corruption that will take you 6 weeks to find and fix.

AD is pretty good at handling things when one or more of the server roles fail. The only way you can reasonably restore from the dead is to replicate all FSMO roles off to another backup server (real time)

Then as long as the server is not only server master here's what you do.

Install a new server. Let it settle and wait 15 minutes to an hour. Then delete the downed server from AD Users and Computers. Everywhere. And in DNS. Everywhere.

Then change the server name to the downed server and transfer rolls from your backup. Quick and easy. (No Regit entries)

[n00bius]

hmmm, so lets say a server went down and we have a recent system state backup (meaning < tombstone lifetime) and we're not really worried about the changes that occured between the day of the update and the date of the restore, only that AD doesn't accidentally overwrite the new data with the old. Would the method in the following link be practical, because all else equal, it would be as if you recreated the same server since it has the same SSID and you don't have to worry about any broken AD connections between the DC's?

http://technet2.microsoft.com/window....mspx?mfr=true

[spirovski.b]

I seem to be missing the point...
What are you trying to achieve here?
If you have a surviving DC other then the failed one, the entire effort is moot (and a waste of time). Just install a fresh system and promote it to DC role to the domain.

If it's the last or only DC, then you're up s**t creek . In such a case, i would expect that the referenced procedure is your last resort.

I will try to recreate the instructed process on my virtual environment, and will post results .

[n00bius]

The biggest advantage to this type of restore would be that it wouldn't invalidate any trust relationships the server/domain controller had with other DC controller since it'd retain the same SSID. While just creating a new server, and promoting it to a DC would create a new SSID, even if it was the same machine, which would warrant recreating each of the trust relationships again. I could see this being a big issue, in a mesh type AD configuration, or a custom configuration if a DC wasn't demoted gracefully.

[dinowuff]

I could see this being a big issue, in a mesh type AD configuration, or a custom configuration if a DC wasn't demoted gracefully.

You're confusing me. Are you talking about a wireless ad-hoc type network?

[n00bius]

I was referring to the topology in Active Directory, AD has a layout of how it updates all the domain controllers, i.e. if you were to go into Active Directory Sites and Services and look at the NTDS settings for each domain controller, by default a mesh network is made between each DC, so if there were three domain controllers there'd be two connections each.

tell me if that makes any sense.