If the Exchange server database service is denied write access to its own
database files (*.edb) or to the checkpoint file (*.chk), errors similar to the
following may be seen: MSExchangeIS (xxxx) Unable to write a shadowed header for
Common causes of this issue include:
- Another process has “stolen” the file. A virus checker may mistakenly
quarantine a file, or a backup process may temporarily deny access. In
this case, you may see Error -1032 in the Description section of Event ID 439.
Error -1032 is equivalent to JET_errFileAccessDenied, which is defined as
cannot access file — the file is locked or in use.
- A disk or controller failure has occurred, and access to the entire drive
has been lost, sometimes temporarily. Check the System Log
for I/O or drive errors near the time of the 439 Event. In this case, you
may see Error -1022 in the description of Event ID 439. Error -1022 = JET_errDiskIO = Disk
IO error. The -1022 error is a generic error that appears whenever a disk
input/output (I/O) problem prevents Exchange from gaining access to a
requested page in the database or to a transaction log.
- Permissions have been removed from the folder where the file resides.
- The file has been marked read-only. This is most likely to happen to a
- The folder containing the file has been renamed or deleted. This is also
mostly likely to happen to a checkpoint file.
- Check for alerts related to full disks and resolve as necessary.
- To troubleshoot such errors, you must determine what has suddenly blocked
the database service from access to its files. In many cases, restarting the
affected server “breaks” the lock if you cannot find another way to do
- Confirm that there is sufficient access to the disks.
- If the database is still running, you may have to use Move Mailbox or
ExMerge to move the mailboxes to another server.
- If the database will not mount, you may need to restore from online
backup. If there is no valid backup, as a last resort, you may need to
repair the database with Eseutil /P, run isinteg -fix until all fixes are
removed, and then mount the database and ExMerge to a new, blank database.