MSExchangeIS 9518 0xfffffb40: Missing Database File
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2007-09-21
The Microsoft Exchange Database Troubleshooter Tool detected one or more MSExchangeIS 9518 events with error code 0xfffffb40 in the Application log. This indicates that one or more database files for the Storage Group are missing.
Explanation
This error can occur when the Extensible Storage Engine (ESE) attempts to bring all databases in a storage group to a consistent state during recovery, but finds that database files are missing or have been replaced with different versions.
If any database file from the Storage Group is missing, or has been replaced with different versions, ESE returns the error -1216, aborts the recovery, and does not start the storage group.
User Action
To resolve this issue, do one or more of the following:
If the missing database file has been moved or renamed, locate any ESE 494 events in the application log that occurred after the attempt was made to mount the database. For each event, note the specific database file that is reported missing, find the file's current location and move it to the proper location.
Note
If file-level antivirus software is installed on this server, and exclusions have not been configured correctly, it is possible that the database could have been deleted or quarantined by the antivirus software. Make sure to check the antivirus quarantine and deletion log to see if this has occurred.
If the missing database file has been deleted or lost, restore the file from a backup to the production storage group. You can use the Exchange Database Recovery Management tool's Verify database and transaction log files task to verify the restored database file is available to perform a restore.
While you are restoring this database file, you can also mount and access the other unaffected databases in the storage group by completing the following steps:
To allow user mailbox access to unaffected databases
Run eseutil /R /L <Path to Log Files> /S <Path to System Files>Log Base Name /I (where Log Base Name is the first three characters of the log files for this storage group, i.e. E00, E01, etc.). This allows ESE to take the database files present to a consistent state while ignoring the missing database files. After running this command, any missing database files will need to be restored from backup.
Note
The /L and /S switches are optional, and do not need to be used if eseutil is being run from the same location as the log files and system files.
Mount the database files in the storage group that are now present and consistent.
Users with mailboxes hosted by the currently mounted database may now access their mail.
Restore the database file from backup to a Recovery Storage Group. You can provide send/receive functionality immediately by starting up with a new database as soon as possible (known as dial tone recovery). Clients see an empty mailbox, but they have send and receive capability more quickly than if they had to wait for restoration or repair to complete.
Note
The dial tone option will require the eventual merging of any new (post dial tone) data with the restored data.
If a hard repair was run either manually or from the Repair Database task of the Exchange Troubleshooting Assistant against one or more databases in the Storage Group, and the database(s) are in a consistent state, it may be that the log files for the Storage Group were not removed. If all databases for the Storage Group are in their correct location, verify that all databases are in a consistent state by running the following command.
To manually verify database file consistency state
Run eseutil /mh <path to database .edb file>
In the output of this command, look for the State: field and verify that its value is Clean Shutdown.
If all databases for the Storage Group are in a Clean Shutdown state, move all the transaction logs and system logs for the Storage Group to a backup location, and then attempt to mount the store. If you are able to mount all databases correctly, we recommend making a backup of the Storage Group immediately.
For More Information
For more information about MSExchangeIS 9518 event with error code 0xfffffb40, see the "Events and Errors Message Center" (https://go.microsoft.com/fwlink/?LinkId=91705).
For more information about recovering from this error, see Microsoft Knowledge Base article 296843, "How to recover an Exchange 2000 Server database after error -1216" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=296843).
For more information about Exchange Disaster Recovery Planning, see "A Guide to Exchange Disaster Recovery Planning" (https://go.microsoft.com/fwlink/?LinkId=91706).
For more information about database recovery management and database troubleshooter wizards, see "Database Recovery Management and Database Troubleshooter Tool" (https://go.microsoft.com/fwlink/?LinkId=91707).
For more information about the dial tone recovery, see "Dial Tone Portability" (https://go.microsoft.com/fwlink/?LinkId=91703) in the Disaster Recovery topic of the Exchange 2007 product documentation.
For more information about the Recovery Storage Groups, see "Understanding Recovery Storage Groups" (https://go.microsoft.com/fwlink/?LinkID=80784) in the Disaster Recovery topic of the Exchange 2007 product documentation.