|
An unexpected error was encountered while trying to delete a file.
You will receive the following phrase in the event Description:
Information Store (number) An attempt to delete the file path\filename failed
with system error [number] (hex code): [error]. The delete file operation
will fail with error [number](hex code).
The file name can refer to a check file, a tmp.log file, a temp.edb file, or
a temp.stm file.
The cause depends on the Error listed at the end of the Description section of
the event. All known causes are listed below.
- Error -1032 = 0xfffffbf8 = 4294966264 = JET_errFileAccessDenied = Cannot
access file – the file is locked or in use. Another process has “stolen” the
file. A virus checker may mistakenly quarantine a file, or a backup process
may temporarily deny access. A flat file backup system or anti-virus software
may be running against the database or check file directories or the M: drive.
This error can also occur if the permissions on the folder that contain the
files for the information stores are not sufficient for the stores to function
properly.
- Error -1022 = 0xfffffc02 = 4294966274 = 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 check file. A disk or controller failure may have occurred,
and access to the entire drive has been lost, sometimes temporarily. When this
happens, Exchange may not be able to write, read, delete, open, or create
Exchange log, check, or database files. Check the System Log for I/O or drive
errors near the time of the 485 Event. This issue may also occur because the
path for the check file (such as E00.chk) is not correct, which may be caused
by a drive failure.
- Error -1023 = 0xfffffc01= 4294966273 = JET_errInvalidPath = Invalid file
path. This error can be caused by changing the path for the working directory
or the check file in the Exchange System Manager. If the location in the
Registry shows the old location instead of the new location, error -1023 may
result.
|
- For Error -1032. change the permissions on the folders that contain the
information store files to the default permissions. Configure the flat file
backup and anti-virus software to not scan the Exchange server information
store subdirectories or the M: drive. Use Exchange-aware online backup and
anti-virus software.
- For Error -1022, run “chkdsk /f /r” (without the quotation marks). If
chkdsk does not resolve the issue, examine the permissions on the Exchsrvr
folder structure. Make sure that SYSTEM has full control of Exchsrvr and all
subfolders on each partition that contains Exchange data. If you still cannot
mount the databases, troubleshoot any Windows NT file-level antivirus software
running on the Exchange server. Check the System Log for I/O or drive errors
near the time of the 490 Event. Check and correct the path for the check file
(such as E00.chk).
- For Error -1023, place the information store files back in their original
locations or change the location in the registry.
- NOTE: fix the root cause first. If the databases are
inconsistent and you cannot run soft recovery, you may need to restore from
online backup. As a last resort, you may need to repair the database
with Eseutil /p, run Isinteg -fix, and then use ExMerge or Move Mailbox or .pst
files to move the mailboxes to a new store, delete the current database,
create a new one, and then use ExMerge or Move Mailbox or .pst files to move
the mailboxes back into the blank database.
|