More Exchange Disaster Recovery Tips
Here are some additional ideas for improving your Exchange disaster recovery plan.
March 6, 2006
Tip 1: Include AD in Your Recovery Plan
In many cases, recovering Exchange also means recovering Active Directory (AD). Small companies often have only one server for both Exchange and AD, and even in very large environments, a minor mistake in AD can have consequences for the complete Exchange and AD configuration. Since Exchange Server 2003 and Exchange 2000 Server rely heavily on AD, make sure you frequently back up your domain controller's (DC)'s system state, which includes AD, the registry, boot files, certificate services, Microsoft IIS, COM+, and Sysvol information. Perform system-state backups at least as often as you back up Exchange.
Thoroughly check and test your system-state backup and restore capabilities and make sure that the NTDS and Sysvol volumes have enough space to perform a complete system-state restore. I've seen restores of Global Catalogs (GCs) larger than 2GB fail on disks with more than 2GB of free space. Make sure that your recovery plan includes procedures to restore AD both authoritatively and non-authoritatively. For instance, deleting or changing important directory objects in AD in a multiple-DC environment will require you to perform an authoritative AD restore, whereas you'd want to use the non-authoritative restore to recover a DC that failed completely because of hardware errors. For more information about AD backup and restore procedures, see the Microsoft TechNet "Active Directory Operations Guide," http://technet2.microsoft.com/windowsserver/en/library/9c6e4dd4-3877-4100-a8e2-5c60c5e19bb01033.mspx.
Tip 2: "Back Up" Your Exchange Expert
Many organizations have a resident Exchange expert—the one person who fully knows the Exchange infrastructure. Your disaster recovery plan should specify who will back up and, if necessary, replace your Exchange guru should he or she be unavailable in a disaster. Select an employee who will back up the Exchange expert, and make sure that employee and the Exchange guru meet regularly—to bring the backup employee up to speed on your organization's Exchange procedures.
Tip 3: Use the Exchange Disaster Recovery Analyzer
The Exchange Server Disaster Recovery Analyzer Tool (ExDRA) can help administrators troubleshoot Exchange-database–related problems. ExDRA collects configuration data and header information from databases and transaction-log files and creates a detailed list of database problems and instructions for resolving them, as Web Figure 1 shows. Familiarize yourself with ExDRA before a disaster strikes, so that you'll be adept at using the tool and interpreting its information when you're under pressure during a recovery. You can download the free ExDRA tool at http://www.microsoft.com/downloads/details.aspx?familyid=c86fa454-416c-4751-bd0e-5d945b8c107b&displaylang=en.
When databases won't mount or you suspect Information Store (IS) problems, run ExDRA to find inconsistencies and errors. ExDRA can check dismounted ISs to see whether the IS shutdown was clean or dirty. Additionally, ExDRA will tell you which eseutil.exe and Isinteg.exe commands you need to run to check and repair the database(s) and transaction-log files. ExDRA will perform for you the checks you'd typically do by using these commands:
isinteg -s ServerName -test allfoldertests
which checks the higher-level IS database-table–structure integrity (replace ServerName with the name of your Exchange server), and
eseutil /g
which checks the physical database pages. ExDRA will run similar commands for you to check IS integrity and database consistency, then will then give suggestions and examples for fixing the problems.
At the outset of your database-mounting problems, if you don't suspect Windows system problems, full disks, or viruses as the cause, restart the Information Store service or the complete Exchange server. During the Information Store service startup, selecting the soft recovery option—which checks database consistency and replays uncommitted transaction logs into the database—could fix the problems automatically. The Microsoft article "How to identify logical corruption problems in Exchange Server," http://support.microsoft.com/?kbid=828068, provides more information about troubleshooting Exchange database-corruption problems and is a useful addition to your disaster recovery kit.
About the Author
You May Also Like