ME271987 suggest that this kind of error indicates a physical corruption in the information store.
See
ME151789 for a description of Jet -1018 error.
ME314917 provides information on understanding and analyzing -1018, -1019, and -1022 Exchange database errors.
In my case, this error occurred because .NET Framework 2.0 was corrupt. Reinstalling it solved the problem.
Microsoft is a bit too quick to blame this error on hardware failure. We've extensively checked out the Exchange servers that were throwing these errors after the Exchange 2003 SP2 update. A full bit level check of all systems found no problems but Exchange would consistently throw out database corruption errors on deleted messages especially just prior to a backup. It turned out the "zero deleted messages" process was to blame. It was causing erroneous CRC values to be recorded. When we turned off this feature, all problems ceased. If you are afflicted with this problem in Exchange 2003, one easy way to solve the problem is for you to create a new message store and move your mailboxes to it. You can do so even with the system on-line, saving much grief.
- Error: -1018 = JET_errReadVerifyFailure - See
ME810411.
- Error: -1018 - As per Microsoft: "In earlier versions of Exchange, event ID 475 is also used to report the occurrence of a -1018 error. Exchange 2003 SP1 does not use event ID 475. Exchange 2003 SP1 uses event ID 474 to report the occurrence of an unrecoverable -1018 error, and event ID 399 to report the occurrence of a recoverable -1018 error". See
ME867626 for more details.
See
MSEX2K3DB and the link to "
Error code 1018" for additional information.
Error -1018 is a JET database (ESE) error. There are a few possibilities associated with this error:
1. You have anti-virus software running on the server and it is corrupting the information store
2. A hard disk is beginning to fail.
There is no official support document availible from Microsoft which addresses this issue but you can infer a resolution. Because of the mismatched checksum the Exchange database cannot be treated as consistent. Sadly this means that no backups of the Exchange store which has this mismatch can be trusted. Reverting back to a backup of the store when there was no mismatch is the only safe option. Mail recieved since the mismatch may be lost. Backups of the content of individual mailbox can be trusted so after restoring the store to a consistent state is would be fine to restore the content of all the individual mailboxs to the latest backup.
One could also use Eseutil and Isinteg but "when you run repair there is always a chance of catastrophic data loss, and you should always have a backup of a database file before you attempt repair." See
ME262196.
In my case, this problem was fixed with eseutil /p. This may not be the best option in every situation. It is a good idea to run diagnostics on the hardware before trying to repair the Exchange database since this issue could indeed be hardware related, per
ME327337.