| Event Id | 467 |
| Source | ESE |
| Description | |
| Event Information | According to Microsoft : Explanation : The index of a table in the Exchange store database is corrupted. The secondary index is corrupted. There is a corrupted index in the Exchange store database. This is what is called logical corruption. Three levels of damage can occur in an Exchange store database: (1) Page (file system) level (2) Database (JET database engine) level and (3) Application (Exchange store database) level. The most typical logical corruptions occur at the database level. For example, database engine failure can cause index entries in the database to point to missing values. Logical corruptions can also occur at the application level, for example, in mailboxes, messages, folders, and attachments. An application-level corruption might cause incorrect reference counts, incorrect Access Control Lists (ACLs), a message header without a message body, and so on. ESE Event ID 467 is logical corruption at the JET database engine level. An online Exchange-aware backup of the Exchange store database will not reveal this corruption. This level of corruption exhibits only when this location in the database is touched by the Jet engine and it is reported in the application log as Event ID 447. Symptoms range from no symptoms at all (other than events in the application log) to access violations of the Microsoft Exchange Information Store service process, with the Microsoft Exchange Information Store service crashing daily due to logical corruption. In some cases, the cause is not obvious and cannot be determined. Review the application and system logs carefully for related events to get additional information on possible causes. This is also helpful to reveal possible additional types of corruption in the database. Resolution: NOTE: This level of corruption cannot be fixed solely by using the Isinteg utility. Logical corruptions can occur in the Exchange store database or the database engine. Because logical corruptions can seriously damage your data, you should not ignore errors in the Exchange store database or the database engine. You can use ISINTEG to check problems with the Exchange store database, or ESEUTIL to check problems with the database engine. ESE Event ID 447 indicates logical corruption at the database level; this is why Isinteg is insufficient to fix the problem. If the logical corruption in the database is isolated to an index page, the checksum on the page may be fine but the data may be corrupted. If the page corrupted is limited an index leaf page(s), you may be able to fix it with offline defragmentation (Eseutil /d). In some cases, you may be able to move all the mailboxes off the server by using the Move Mailbox utility or ExMerge. Then you can recreate a blank Exchange store dattabase and move the mailboxes back into the clean Exchange store database. However, if there are corruption errors either at the page or database level that are in addition to index page corruption, it may not be sufficient to use eseutil /d. There may be some cases in which, as a last resort, you will need to repair the database using eseutil /p, then Isinteg -fix. In this case, after running eseutil /p and Isinteg -fix, you will need to use ExMerge to rebuild the database before putting the database back into production. Once you have done that, immediately perform an online Exchange-aware backup of the database. |
| Reference Links | Event ID 467 From Source ESE |
Catch threats immediately
We work side-by-side with you to rapidly detect cyberthreats
and thwart attacks before they cause damage.