Frequently Asked Questions (FAQs)
This section provides answers to frequently asked questions regarding disaster recovery and Microsoft Exchange Server.
-
Q: If I have a good backup of the directory and information store and I am restoring a server to an existing site by reinstalling Microsoft Exchange Server, should I create a new site or join an existing site during the Microsoft Exchange Server installation?
-
A: Create a new site. Do not select Join Existing Site. If you attempt to join the existing site, an error occurs because other servers in the site already have knowledge of the server you are restoring. When the server is restarted after the restoration of the databases, the restored server automatically synchronizes with existing servers in the site, even though you selected Create a New Site during server installation.
-
Q: If I want to keep a spare server online for performing single mailbox recovery, should I select Join Existing Site or Create a New Site during the installation of Microsoft Exchange Server?
-
A: Select Create a New Site. Also, use a unique computer name when installing Windows NT. Do not select Join Existing Site. When maintaining a single mailbox recovery server, you must configure the server with the same organization and site name as the site from which you plan to recover single mailbox data. It is important that you do not select Join Existing Site during the installation. If you inadvertently join a site and then complete the single mailbox recovery procedures, undesired replication behavior will result after you run the DS/IS consistency adjuster because you have two sets of mailbox data for the same users within the site after restoring a Priv.edb.
-
Q: I have some users that use .pst files and remain logged on at night. How can I back up their .pst files?
-
A: The client automatically disconnects from the .pst file after 30 minutes of inactivity. When activity resumes, the client automatically reconnects to the .pst. Because of this feature, you can back up .pst files during periods of inactivity (usually at night) while the client is logged on to Microsoft Exchange Server.
-
Q: I know that I need to run isinteg -patch after restoring an offline information store backup to patch the globally unique identifiers (GUIDs), but what is a GUID?
-
A: A GUID is a hexadecimal string that uniquely tags an object in time and space. Within the information store, the private and public information stores have base GUIDs that they use to generate GUIDs for all other objects in the information stores, including folders, messages, attachments, and so on. The patch that the ISINTEG tool performs changes the base GUIDs in the information store. The patch must be run because when you restore an information store, you are essentially rolling back time on that server. If you roll back the server and do not change the base GUID, new objects created in that information store could have GUIDs that are identical to other existing objects in the organization. This would cause problems in referencing objects because they could no longer be uniquely identified. If you only have one server in your organization, this is not a problem because when you restore, there are no other objects in the organization that have IDs that might be generated again for new objects.
-
Q: What is the tradeoff regarding location of log files? I have computers with a total of five disk drives. The first two drives are mirrored and the other three are set up in a RAID 5 stripe set. Should I not mirror the operating system and use one of those drives to dedicate for transaction log files to gain performance?
-
A: In Microsoft Exchange Server, the best performance is gained through dedicating a physical drive for transaction log files. This is because transaction log files are written sequentially on a dedicated drive and the disk read/write head does not have to respond to calls from other processes. However, it might not be worth sacrificing operating system mirroring in favor of performance. In this case, it is best to maintain the Windows NT swap file and the Microsoft Exchange Server database files on the three-disk stripe set (RAID 5) and to maintain the transaction log files on the mirror set. With enough RAM in the system, there should be little disk head contention on the operating system drives and transaction log performance should be high.
-
Q: How important is transaction log file redundancy?
-
A: In general, transactions are committed to the databases quickly. However, on a very busy system, transactions written to log files can accumulate before being committed to the database files. If the transaction log drive crashes before transactions are written, this data is lost.
-
Q: How can I shut down Microsoft Exchange Server services without using Control Panel? Sometimes these services take a long time to shut down.
-
A: You can issue commands from the command line to shut down services, or you can use the batch file example shown below. If you want to shut down the entire system from a batch file, use the shutdown command, which is available on the Microsoft Windows NT Resource Kit compact disc. The purpose of this command is to shut down services in reverse dependency order. To shut down a Microsoft Mail (PC) message transfer agent (PCMTA) service that includes spaces in the name, use quotation marks.
REM // stop all services
echo Stopping Services...
net stop MSExchangeMSMI
net stop MSExchangePCMTA*
net stop MSExchangeFB
net stop MSExchangeDX
net stop MSExchangeIMC
net stop MSExchangeMTA
net stop MSExchangeIS
net stop MSExchangeDS
net stop MSExchangeSA
REM - call the shutdown command here. (This command requires that
you have the Windows NT Resource Kit compact disc.)
*service name is user defined
Q: My tape drive is not working, but I need to back up the databases. How can I do this?
A: If you have enough disk space, shut down services and copy the Priv.edb and Pub.edb files from the Exchsrvr\Mdbdata directory (the default installation point). Also copy the Dir.edb file from Exchsrvr\Dsadata (the default installation point). You do not have to copy the transaction log files because when services are shut down normally, outstanding transactions are committed to the database. If you need to restore from this backup method, remove the log files and Edb.chk from their respective directories, copy the previously copied files back in, and follow the procedure for running isinteg -patch. When the services start up, a new Edb.chk file is created, along with new transaction log files. Make sure to back up files before you purge them. If you need additional assistance with these procedures, contact Microsoft Technical Support.
Q: How long does it take to defragment a database?
A: Approximately 10 gigabytes per hour using the ESEUTIL utility.
The databases are defragmented automatically as a background process, so unless the file size of the databases must be reduced, you should not have to run offline compaction (defragmentation with file size reduction).
Q: Do I need a backup of the directory database to recover a server?
A: You need at least one backup of the directory service for each computer. Regardless of how old the backup is, the directory service rebuilds itself on that computer and becomes current from the other directory services in the site after the restore. After you have installed a new server in a site and it is replicated and current, the best thing to do is to make a backup of the directory service.
After a restore, run DS/IS (Directory Services/Information Store) consistency adjuster after the directory service has been synchronized. This ensures that all objects in the information store on that computer are restored back into the directory service.
Note Make sure all directory replication connectors are working properly before running DS/IS consistency adjuster. It is possible to rehome public folders to this server as a result. For more information, see these Knowledge Base articles: Q156705 and Q141342.
If you don't have a backup of the directory service for a server to restore from, your only option is to delete the server from the site and then reinstall it. This option is not advisable because you lose all of your information store data. Instead, make a backup of the directory service as soon as possible after you install a new server, and then lock the backup in a safe place. Replace the backup with more up-to-date backups on a regular basis. This way, you do not have to wait long for the directory service to resynchronize after a restore.
Q: Why do I need to back up the system following the migration of users to the server? Also, why do I need to back up the system after running an offline ESEUTIL operation?
A: If a server crashes after a migration and you have not backed up the system data, you must perform the migration again. This can be time-consuming. After you run an offline ESEUTIL operation, the database is in a new state. If your system experiences a crash, you must perform the operation again. This can also be time-consuming.
Q: When I shut down services, they keep trying to restart. Why does this happen, and what can I do?
A: This problem is most likely caused by a server monitor session that is configured for the server on which you are trying to shut down services. By running the Administrator program admin/t (maintenance mode) command at least one polling interval before stopping services, you ensure that the server monitor is notified that subsequent polls of the server in maintenance mode will not result in alerts or alarms. After running this command, you can stop services and perform maintenance. When maintenance is complete, rerun admin /t to re-enable monitoring. For command-line Help on Administrator program command-line switches, change to the Exchsrvr\Bin directory and type admin /?.
Q: Is it a good idea to periodically perform a directory export?
A: Yes. It is a quick operation and saves you time if you are unable to restore your directory database in the future. You should never have to rely on this procedure, but it is an extra safety measure that enables you to add users quickly if necessary.
Q: Where can I find more information on information store startup problems?
A: Articles in the Microsoft Knowledge Base can be provide additional information on information store startup problems and other issues. For access to the Knowledge Base, visit http://support.microsoft.com/support/. Perform a search on "Microsoft Exchange," and then enter relevant keywords.
Q: What are lazy and non-lazy commits, and how does Microsoft Exchange Server use them?
A: After transaction logs are flushed to disk, the transaction is durable. If your system crashes, these logs can be restored and nothing is lost. Non-lazy commits retain data on the hard drive; lazy commits indicate that the transaction logs have not been saved.
Q: Should I disable the SCSI controller write cache?
A: Yes, unless you have RAID or a disk controller with a battery backup, in which case loss of data is not an issue. Disabling write cache enables you to avoid the potential for data loss where you do not have either RAID or battery backup. At a programming level, if the write through flag is set, Windows NT does not use buffers. Therefore, when a program receives a write complete signal from Windows NT, it is guaranteed that the write was completed to disk. This is critical to the Microsoft Exchange Server transaction logging process. If write cache is enabled, Windows NT responds as if a write has made it to disk and informs the calling application of this "false" information. This could result in data corruption if the system crashes before this lazy write operation makes it to disk.
Q: When is a transaction committed to the database and how does this work? Is it first cached in memory so that it is virtually available, or is it necessary to read back from log files before writing to the database files?
A: Transactions are on both log files and fast memory pages. Log disk heads are never moved back to read old data, so only sequential writes occur on log files. After transactions are written to a log file, an operation is considered complete. The transaction is immediately available in server memory before it is actually committed to the database files. Remember that an operation is not complete (that is, the client does not receive an acknowledgment) until all transactions are written to the transaction log (on disk).
Q: How can I measure how the transaction logging process is doing?
A: Use Performance Monitor and select the MSExchangeDB object. Configure the following counters:
-
Log Bytes Write/sec ¾ The rate at which bytes are written to the log.
-
Log Checkpoint Depth ¾ A number proportional to the time that recovery will take after a system crash, depending on the performance of the individual system. A data page might be cached and not flushed to the .edb file for a long time. The earliest logged operations on the page can date back a significant time. To ensure that your system recovers from a crash, do not restore too many logs, and set the checkpoint depth to determine how many logs you can expect to replay during recovery.
-
Log Sessions Waiting ¾ The number of sessions waiting on a log commit to complete a transaction.
Q: What is the advantage of disabling circular logging?
A: Disabling circular logging provides for additional recoverability. This is because a history of transaction logs are maintained for all transactions. These log files are purged only when a full or incremental online backup is performed and they are no longer needed. For example, suppose your last good backup occurred on Monday, and on Thursday your database drive crashes. If you disabled circular logging and your transaction log files are configured on a separate physical drive from the drive that crashed, you can restore the Monday backup. In this case, you should not erase existing data, and you should verify that the log files created since the Monday backup have been restored back into the database. This process restores your data to the point immediately before the crash.
Q: When I try to run the isinteg -patch command, it does not run and I receive the following error message: DS_E_COMMUNICATIONS_PROBLEM. How do I solve this problem?
A: Make sure the directory service is started before running the command.
Q: How can I back up a Microsoft Exchange Server computer if the Windows NT Server computer I am using does not have the Administrator program installed?
A: If you are copying files from an existing Microsoft Exchange Server computer, find and copy to the backup machine the Edbbcli.dll file found in the Winnt Root\System 32 directory on the existing server. This file is necessary in order for Ntbackup.exe to back up a Microsoft Exchange Server. The Edbbcli.dll file is also available on the Microsoft Exchange Server installation compact disc.
Q: Do I need to run the DS/IS consistency adjuster after restoring the directory and information store?
A: No. You only have to run the DS/IS consistency adjuster if you restore only the information store. The consistency adjuster scans the information store and ensures that a directory service object exists for each information store object. If the directory service object does not exist, one is created. The consistency adjuster also scans the directory service and ensures that a corresponding information store object exists. If it does not exist, the directory service object is deleted. Finally, the consistency adjuster also verifies the access control list (ACL) for each object and strips any invalid entries from the list. You can also set the DS/MDB Sync diagnostic logging level to maximum and then check the application log.
Q: Should I avoid running the DS/IS consistency adjuster?
A: If you restore only the information store and must run the DS/IS consistency adjuster to re-create the directory service object for the mailboxes in the store, this sets the HOME-MDB attribute on all public folders in the hierarchy (replicas or not) to this server . In addition, it strips the public folder ACLs of any invalid entries (that is, users who do not exist in the current directory).
If you do this and then re-create a replication connector into the organization, there will be a conflict. The new server will probably win because it has newer changes to the public folder property. Accordingly, the public folder will be homed on the new server, and the new server's ACL will most likely be the ACL that is kept. This will result in lost permissions for some users.
Q: I cannot find the backup set on my tape. What might cause this?
A: Make sure that you catalog the tape before restoring any data. This process enables you to gather information on the files available on the tape, and it enables the restore process to take place. After the catalog is complete, you can start the restore process. To load a catalog of the backup sets on a tape, follow this procedure:
-
In the Tapes window, select the tape whose catalog you want loaded.
-
Choose Catalog in one of three ways: double-click the icon for the appropriate tape, choose Catalog, or choose Catalog from the Operations menu.
After you search the tape, a complete list of backup sets appears in the Tapes window. Question marks are displayed in each icon to indicate that their individual catalogs have not been loaded.
Q: If you delete a computer name from the domain, re-add it to the domain, and then restore the Windows NT Registry from tape, is it true that the local SID from the restored Windows NT Registry will not match the new SID created in the domain?
A: Yes. You should delete and re-add the name of a Microsoft Exchange Server computer in the domain only if a new server is required for recovery. The Windows NT Registry should be restored only to the same physical computer because the Windows NT Registry contains computer-specific data. This situation can occur if only the operating system hard disk was replaced and a Windows NT restore is performed.
Another issue to consider is that the Microsoft Exchange Server directory database maintains information about Windows NT IDs in the domain, such as ACL information. If you cannot access the security accounts manager from the original domain and you create a new security accounts manager by installing a new domain, and then restore the directory service, you have a disconnect between the object security in the directory service (such as the Microsoft Exchange service account, user mailboxes, and administrator's account) and the new domain security accounts manager. As a result, you do not have access to any object in the Microsoft Exchange Server directory.
Q: What is the impact of configuring Microsoft Exchange Server computers as backup domain controllers?
A: Configuring Microsoft Exchange Server computers as backup domain controllers can provide increased recoverability and reduced costs. However, the memory requirements for these computers are also increased. For example, suppose that a Microsoft Exchange Server computer configured as a primary domain controller has to be replaced. Although the Windows NT domain controller can be rebuilt and the information store restored, the directory service cannot be restored successfully to a domain that does not have the original security accounts manager.
Q: Does a full server restore to a different physical computer require the recovery server to be configured as a backup domain controller or primary domain controller?
A: No. The important thing is that the computer account is deleted and then re-added to the production domain so that the recovery computer can obtain a new SID that uses the same name as the original production server.
Q: How do you defragment the information store databases?
A: Microsoft Exchange Server automatically defragments the information store and directory databases without interruption to messaging. Online defragmentation takes place in the background, marking items for deletion and defragmenting the database files. The resulting empty pages are returned back to the file system.
You can also use the ESEUTIL utility to compact the information store databases. Running the eseutil /D command reduces the size of the information store database files and defragments the database. In contrast, online defragmentation defragments the database files but does not decrease their size. If you use the /D (defragment) command-line option when running ESEUTIL, you must first stop the information store service.
Q: What is the difference between compaction, defragmentation, and information store maintenance?
A: By default, information store maintenance occurs between 1:00 A.M. and 6:00 A.M. The following tasks are typically completed during information store maintenance: tombstone compression, column aging, index aging, clean per user read, and message expiration. To view these settings from within the Administrator program, select the appropriate server under Org, Site, and Configuration. From the File menu, choose Properties and then select the information store Maintenance tab.
Defragmentation is the online process that optimizes the structure of the database.
Compaction is the offline process of reclaiming disk space and defragmenting the database files. The process is accomplished using the eseutil /D command and reclaims space, having reduced the size of the database files.
Q: At what point do log files wrap around when database circular logging is used?
A: This is usually limited to four files, but if there is a heavy load on the server, such as during a large import/migration operation or a public folder backfill, the checkpoint and window grow to more than four log files.
Q: What is the Temp.edb file and why does it get created?
A: If long-term transactions are taking place, the Temp.edb file is used to store transactions that are in progress. This file is also used for transient storage during online compaction.
Q: When should the eseutil /P command be used?
A: You should use ESEUTIL only in consultation with Microsoft Technical Support. This command can delete data. Before running eseutil /P, you should always attempt a restore.
Q: What are the Res1.log and Res2.log files used for?
A: These are reserve log files that are not used unless the transaction log hard disk fills up. They are reserved for transactions that might be required to shut down the information store if the disk fills up. This way, even if the hard disk fills up, there is reserved space to record transactions from memory to disk. These files are 5 MB each, regardless of the number of transactions in the log files.
Q: If an information store is in recovery after a system crash, will Microsoft Exchange Server be smart enough not to duplicate pre-existing transactions in the database and only play back uncommitted transactions?
A: Yes. Log files are read and this is a fast operation. If the transaction version number is already in the database, the transaction is not recommitted.
Q: Will Microsoft Exchange Server automatically play back uncommitted transactions from logs when the services come up the first time following a crash?
A: Yes. If the database shut down was not clean, Microsoft Exchange Server records that and replays all transactions from the checkpoint forward at startup.
Q: If circular logging is enabled, is it true that you cannot play back logs (those that are present in the circular window)?
A: Yes. With circular logging enabled, you cannot restore from a backup and play forward. You can only restore from backup at the point the backup was taken. By default, Microsoft Exchange Server is configured with circular logging enabled.
Q: If circular logging is disabled, how can you play back transaction log files if required?
A: With circular logging disabled, you can play back logs from the last full backup. It depends on how you are performing backups. For example, suppose that you perform a full weekly backup on Sunday and incremental backups Monday through Saturday. If you lose a hard drive or other data on Thursday, you need to restore tapes in the following order:
-
Sunday: Full restore. Don't start services.
-
Monday: Incremental restore. Don't start services.
-
Tuesday: Incremental restore. Don't start services.
-
Wednesday: Incremental restore. Don't start services.
After these restore operations are completed, start the information store service. You can restore all of these backup sets in one job and then select Start Services after the restore. When you do so, Ntbackup.exe does not start services until the files from all sets are restored. Ntbackup.exe restores the data and log files from Sunday and adds the log files for Monday through Wednesday when the services restart. Finally, Ntbackup.exe replays all log files from after the point of the full backup on Sunday until the present time (that is, Monday through Wednesday, plus any log files created after the Wednesday backup).
Incremental backups delete log files after a backup is completed. Differential backups do not delete log files; instead these files are written to tape. If you were performing differential backups, you would not have to restore the Monday through Wednesday backup because you would still have those log files on the system.
Incremental and differential backups back up all log files since the last backup, as well as the Edb.chk file. The difference between these two backup types is that differential backups do not delete log files from the system.
Q: What is the difference between running the isinteg - fix command and the eseutil /P command?
A: The eseutil /P command should only be run as a last resort in order to repair a database file. You should use the ESEUTIL tool only in consultation with Microsoft Technical Support. The isinteg - fix command repairs high-level objects, while eseutil /P repairs low-level database corruption. The isinteg - fix command repairs any "scheme" and other high level data or structure problems. If you have to run both commands, run eseutil /P first; then run isinteg - fix. Only run both commands if you do not have a backup from which to restore and log files to play forward.
Restoring data from a backup and then playing logs forward is the recommended way to restore a corrupted database due to hardware failure. These procedures are recommended because they enable you to recover all your data. If you do not have a backup to restore and run the eseutil /P and isinteg - fix commands instead, you will lose all your data.
Q: Can Microsoft Exchange Server perform information store compression on the fly? Should administrators perform manual compression on a periodic basis?
A: Microsoft Exchange Server can perform online defragmentation, which is different than compression.
Microsoft Exchange Server reuses the space before growing the file, so database defragmentation takes place in the background on a running server. The only time you should have to shut down a server for offline compaction is when you want to physically recover the free space on the disk. To reduce .edb file size, stop Microsoft Exchange Server services and then run the eseutil /D command.
Q: What is the purpose of log files?
A: On a Microsoft Exchange Server computer, the public information store, private information store, and directory service each have log files. These files are the transaction logs for all transactions that occur on the database. In the event of a system crash, hard drive failure, power failure, or another disaster, these files can be used for soft and hard recovery and for restore after backup. The Priv.edb file on a running server is always inconsistent because of the database cache that is in RAM on the server. The consistent state of a server is made up of the data in the .edb file and the data in the memory cache on the server. If a server computer crashes and you don't replay the logs, this results in a corrupt database.
The log files permit automatic playback of transactions that have occurred on the database but are not yet committed to the .edb file. There is a check-point file, Edb.chk, that contains the current transaction point in the log files that have been committed to disk.
Log files continue to consume disk space until you do one of the following:
-
Back up the server (by performing a full backup or an incremental backup). This writes all logs to the tape up to the check point and then deletes the logs written to tape from the hard drive. If you have to restore the database, the backup copies the database file from the tape, replays the logs on the tape, and then replays all the logs on the disk.
-
Run with circular logging enabled.
If you browse the .edb file directories, you also see *.pat files. These files are created when a backup is performed and contain all the changes (patches) since the backup started. You can write the patch file when performing a backup and be completely current. The following table lists files that you see in the Exchsrvr\Mdbdata directory.
File |
Description |
Priv.edb |
Private database file |
Pub.edb |
Public database file |
Edb.log |
Current log file being written to |
Edbxxxxx.log |
Previous log files no longer opened or being used; new .log file every 5 MB |
Res1.log |
Log file reserved in case the database or log file drive fills up the server |
Res2.log |
Log file reserved in case the database or log file drive fills up the server |
Priv.pat |
Backup patch file for Priv.edb |
Pub.pat |
Backup patch file for Pub.edb |
Edb.chk |
Checkpoint file |
Q: When I am restoring a server in a site, if I do not have a backup of the directory (Dir.edb ) for the server, can I backfill the directory from a replica on another server in the site?
A: No. It is critical that you have a backup of the directory for each Microsoft Exchange Server computer because the directory is unique for each computer. Even if you have only the original directory backup, you can restore this backup and then backfill changes from another server in the site.
Q: What is the Microsoft Exchange Server setup /r command used for?
A: The setup /r command enables recovery of an existing Microsoft Exchange Server computer to new hardware. Restoration of a valid database backup is also required. Run the setup /r command when you want to move a server installation to a different computer or if you are restoring data to a new computer.
Q: Is a differential backup required only when both the transaction drive and the .edb drive must be recovered?
A: Yes. If circular logging is disabled and the transaction logs are intact, you can restore the last full backup. When the service is started, logs from the point of the full backup are played through the current Edb.log file to bring the database up-to-date. In this case, do not select Erase all existing data during the restore, or the transaction logs will be erased and you will have to restore the differential tape.
Q: Why can't I start services between restoring a full tape and a differential or incremental tape, or between sequential tapes being restored?
A: This is because at the end of a restore, Microsoft Exchange Server plays back all logs in sequential order. After it does this, the database is set to a new state. For example, if the services are started between a Monday incremental tape restore and a Tuesday incremental tape restore, a new state is set. When you attempt to perform the Tuesday incremental restore, the restore is not possible because the state of the database is expected to be exactly what it was at the point of the Tuesday backup. This behavior prevents overwriting new operations that have occurred on the database after services have been started.