Recovery Domain Controller

[nicolas_zafirio]

W2003 St edition server. We have had a catastrophic hardware failure on our server which is our domain controller and exchange server

I am trying to execute a complete restore to a new server with dissimilar hardware configuration. using BESR version 8.5.1. However I am having major problems as when I either choose the environmental file sv2i or the actual v2i drive file - i get memory reference errors. Also when I tested the recovery about 2 weeks ago, I had to run windows repair to get the server up on our lab server BUT  the exchange stores would not mount. I only managed to get exchange running by recovering exchage data from backup exec backup (thankfully that worked ok). I have the feeling that I am executing something incorrectly in the process of either imaging the data or restoring. By the way the image is outputed on a networked Western Digital storage device.

I would extremely appreciate a knowleable response as i am getting desperate to have our server back up

nicolas

[marcogsp]

I've added some additional comments below, regarding  recovering a FSMO role holder.

Given the problems with your lab test restore and the failure to restore to the replacement hardware, I think this may have been a progressive failure that
went catastrophic.  Depending on how close the restore image was made to the failure time increases the chance of the resore image being corrupted.  If you
have an older image that is younger than the tombstone period of your domain controllers, then you may have better luck.  If the older images open from the same storage device, then you can rule out a SRD incompatability with your image storage device.  If the older image restores, you may still have to do a repair installation of the OS and recover the Exchange installation from BE.  It is still better than rebuilding it all from scratch.  Depending on recent changes to your Active Directory and how important they are, you may want to have another domain controller sieze the FSMO and global catalog roles, if they were held by the server being restored. 

*********************************************************************************************************

I need to add that introducing a recovered FSMO role holder back into an AD domain where the FSMO roles where seized by another DC is dangerous and is bound to cause AD corruption.  The recovered DC should be moved to a lab network and demoted to an ordinary server.  Then on a production environment DC ( in the same forrest)  run "ntdsutil /metadata cleanup"  After this, it should be safe to have the recovered server join the domain again and promote it to a domain controller again.

********************************************************************************************************


I have some other suggestions, but you should copy your BESR images to another location and work with the copies.  If something goes wrong, then the originals are still intact.  Are you working with a base and incremental set of images?  Have you tried opening the images in the Recovery Point Browser to see if you can examine the contents?  You can also use "Verify Recovery Point" from the file menu to check for corruption.  The image name has to be highlighted in the GUI in order for the verify menu item to not be greyed out.  Also, have you tried consolidating any  incremental images into a single image?  If the most recent incremental image verifies, use "Copy Recovery Point" to consolidate the incrementals into one image.  If the most recent image is corrupt, keep going back through the images until a good one is found. 

You can also use the "Copy Recovery Point" option to try rebuilding a base image as well, if that is all you have.

Regarding your test restore, the most common cause of an Exchange info store not mounting (after recovery to a different server) is the lack of an active network connection.  The Information Store service will not start, and thus not mount the stores unless an active connection is present on the NIC.  A simple switch or hub is all that is needed to provide this in a lab situation.  No need to connect to your production network.  Another common cause is the Exchange databases need their indexes rebuilt after a restore.  Defragmenting the databases with ESEUTIL also rebuilds the indexes.  It is also a good idea to run ISINTEG on recovered Exchange databases.  More info on these utilities linked below.


ESEUTIL

http://support.microsoft.com/kb/192185

ISINTEG

http://support.microsoft.com/kb/301460

When restoring to different hardware and using the Restore Anyware option, you really should select the individual drive files and restore them separately.  You only want to select the sv2i file when doing a bare metal restore to the same computer, but with replacement hard drive(s) installed.  I'm a including a link for troubleshooting the SRD recovery process:

http://seer.entsupport.symantec.com/docs/295044.htm

BTW, there is a new version of the SRD available if your support contract is up to date.

[marcogsp]

I posted a comment in the post below about setting up a lab for testing domain controller recovery.  The practices would also be applicable to your situation.

https://www-secure.symantec.com/connect/forums/restoring-domain-controller-backup-archive

Sorry for all the circular posting as of late.  Perhaps I'll gather up all this info and post it as an article or two to make it more centrally accessible.

[Symanticus]

Hi All,

The following is my Servers:

Server A - 1st DNS + DC (Schema Master role)
Server B - 2nd DNS+ Exc.Srv07 + DC (4 other FSMO role)

I'm about to migrate Server B into new similar hardware using Cold backup of BESRO 8.5.3 Recovery Disc,may i know the correct way to do the Windows Domain Controller + Exchange Server backup or is there any best practice in doing it ?

thanks.

[marcogsp]

Albert --As long as your cold backup is no older than the tombstone setting (typically 60 days) , you should be okay as long as your domain objects don't change too often.  I assume you are doing a cold backup in order to have the Exchange services stopped and thus not processing any mail.  Then once the replacement server is operational, no mail is lost.  That would be the wisest approach.

You are working with a double edged sword here with a combination DC and Exchange server on the same box, but sometimes economics does not allow us to break out the DC and mail server roles.  If I were coming to your site to do the transfer to other hardware, I would approach it like this.

* If the DNS server on Server A is not the primary for the forward and reverse lookup zones in your domain, force the zone data to be replicated from the master and change the role to primary. Change the role on Server B to secondary. If this project goes sour, then this step will save you a lot of aggravation with Active Directory DNS issuse. This only needs to be done if Server A is not already the DNS primary for your zones

*   From any DC   Under Active Directory Sites and Services---Sites--Default-First-Site-Name---Servers--- For each server listed here goto NTDS settings and right click on each connection in the right hand pane, and click on Replicate Now.

  *   Temporarily transfer the four FSMO roles on Server B to Server A.  While the Schema Master and Domain Naming Master are forest specific, the remaining three roles are domain specific.  If this hardware update goes sour, this will alleviate the need to sieze the FSMO roles held by Server B.  Also make sure Server A is a Global Catalog server, at least temporarily until this project is concluded.

*   Shut down Server B and cold image the server with the SRD.  If you suspect that the drive(s) on Server B have bad sectors, you may want to use the advanced option to ignore bad sectors while copying.  After the imaging process is finished, remove Server B from the network.

*  Temporaily block port 25 traffic on your Internet router. 

*  Restore the image of Server B to the replacement hardware.  Make sure to have the network drivers on hand because the DNS and Exchange services will fail to load if there is no active network connection.  Generally, if booted to the SRD and you can map and browse to network shares, then the SRD should be able to inject the proper network drivers and reset any staic IP addresses held by the old hardware.

*  Boot the replacement server and verify that DNS and Exchange services are operational.  if so, re-enable Port 25 traffic from the Internet.  Transfer any DNS and FSMO roles previously held by Server B back to Server B.  Do another Replicate Now as outlined in the first step.

If you can possibly test this in a lab environment before going live, I would strongly advise it.  Good Luck!

Marco

[Symanticus]

Marco,

That's correct for the cold backup is to stop processing email. Yes, Server A - is the Primary DNS Server

as my domain is quite small, i wonder if i consolidate all FSMO role into Server B altogether, so in case of Server A reboot, Exchange Server still have in/out bound email flow going ?

thanks for you very2 good advice Marco.

[marcogsp]

Albert,

Server A being the Primary DNS  does make the project easier. 

Probably a matter of preference, but I think the following scenario might serve you well.  This assumes that you have no other domains in your forest

Server A  -- RID Master, PDC Emulator, Infrastructure master, (Global Catalog Server optional)

Server B -- Schema Master, Domain Naming Master, Global Catalog server

In the event that Server A is rebooted, the most that is delayed is RID pool assignments, pre Win2000 logons, and checking for replication consistency.
Server B would still have access to the AD schema for the Exchange objects stored there and clients would still be able to logon.  Of course, a properly functioning DNS infrastructure is also important.  In my domain, the DC's are separate from the mail server, and I also have mail passing through an email gateway.  Depending on which DC is being rebooted, the worst that happens is either a short delay in delivering mail to or from Exchange, or a user may be delayed in opening Outlook to retrieve mail.

Consolidating the FSMO roles to Server B would work too, although you might  want Server A to be a Global Catalog as well.  That way, if Server B needs to be rebooted, clients would still be able to logon to the network, assuming that the DNS services are functioning properly.  There is some confusion regarding having a GC on the same server as an Infrastructure master.  The link below outlines the requirements very well:

http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/03/08/37975.aspx

Marco

[Symanticus]

Thank you Marco,

For your thorough explanation it really helps me a lot, I wasn't expect that someone would support me this far.

Cheers to All !