Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 1025 Source: MSExchangeISMailboxStore

Level
Description
An error occurred on database "First Storage Group\Mailbox Store (Exchange_Servername)".
Function name or description of problem: <problem description>
Comments
 
Problem: Content Indexing received an unusual and unexpect error code from MSSearch
Error: 0xc0041800 - In my case I used the information listed in the "How to Rebuild the Full-Text Index Catalog" link to fix the problem.
Problem: EcGenerateNRN: Error code 0x80070005
As per ME899393, this issue is recorded on Exchange Server 2003 or Exchange 2000 if the following conditions are true:
- The computer account for the Exchange server has an explicit Deny permission for the Receive As permission assigned.
- A user deletes an unread e-mail message that has a read receipt requested.
We found the local delivery queue to be filling up and the server to be very slow. The time was also out of sync. Fix:

net stop w32time
net time /setsntp:<server>
net start w32time

Wait for the time to be resynced and for the local delivery queue to clear.
- SLINK::EcTestMessage Error: 0xfffffae2 - See ME312966.
- SLINK::EcUpdate Error: 0xfffffa7a - See ME329817 for more details.

- Description: Function name or description of problem: Restrict/SetSearchCriteria Error: -1102 Warning: fail to apply search optimization to folder (FID 4-182C0D8) Retrying without optimization - From a newsgroup post: "This message is logged when the Query Processor (QP) tries to use an index to perform a query optimization but, at the same time, that index was updated by a concurrent transaction. In this situation, the QP will just abandon the optimized path and revert to the default search algorithm.
The only exception to this is when a third party anti-virus program creates a locking situation that causes these errors. It still should not affect functionality, but checking with third party manufacturer for software updates would be a wise move as a precautionary measure".

TechNet might also be of some help to you. See the link to "Recovery and Repair for Microsoft Exchange Server".

Running the Isinteg.exe tool, might help you resolve this problem. See ME301460 for information on the Isinteg.exe tool.

As per MSEX2K3DB, this is a generic event ID that is generated when an error occurs in the Microsoft Exchange Information Store service. Check for other MSExchangeIS events in the event log.
See ME268831 and ME899393 for information on fixing this event.


I have this problem on a Windows Server 2003 with Exchange Server 2003 SP1. It ran fine for 8 months before this warning started appearing in the application event log. I found this KB article ME311233 which pertains to Exchange Server 2000. After several calls to Microsoft and uninstalling McAfee GroupShield 6, I finally found the cause with the help of contributor Mick Danns’ post. It is as Mr. Dann says with the "Reply to" field. With GroupShield installed certain messages would get hung in the "Messages Pending Submission" queue. With GroupShield stopped or uninstalled the messages get hung in the "Local Delivery" queue. With my call to them I know that Microsoft is aware of this problem. The only solution is to stop the SMTP service, find the message that is hung, open it with notepad and delete the "Reply to" field. The messages will be delivered once you start the SMTP service.
In my case, about the time the problem began I had begun creating numerous contacts, non-Exchange enabled, in our AD. The problem surfaced about this time. The emails that were getting stuck in the queue were from internet accounts that had a contact in our system. It was usually from one of about five or six different internet addresses. It appears to be limited, so far, to five or six of these accounts out of about 1500 total contacts. I deleted the existing contact, recreated it and the message from these senders were delivered and are being delivered so far without a problem. It appears that Exchange does some sort of look up on the contents of the "Reply to" field. When Exchange did this look up and found the (corrupted) contact in our AD the message would get hung up.
- SLINK::EcEntryIdFromAddr Error: 0x467 - ME311233 applies to Exchange 2000, but I have had the exact same errors with Exchange 2k3 SP1. The problem in my case was when sharing SMTP namespace as per ME321721. Mail sent from non-exchange users from mycompany.com with the “REPLY TO:” field in their mail client also set to their mycompany.com address would have their email held waiting in the "Messages pending submission" queue, until they timed-out with an NDR. These messages caused the 1025 errors. To clear the problem without losing the emails, stop the SMTP service, open the "%where you installed exchange%\Exchsrvr\Mailroot\Queue" folder, open each message with Notepad, find "REPLT TO:" lines and delete them, save the changed file. Now restart the SMTP service and off they go.
Error: Restrict/SetSearchCriteria Error: -1102 Warning: fail to apply search optimization to folder (FID 1-525335) - See ME327997 to find out how to fix this.
Error: SLINK::EcUpdate Error: 0x8004010f. As per ME309746, Microsoft is researching this problem and will post more information in this article when the information becomes available.

Error: EcEntryIdFromAddr. As per ME311233, to resolve this problem, obtain the latest service pack for Exchange 2000 Server. This problem was corrected in Exchange 2000 Server Service Pack 2.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net.

Read more...

 

Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.

Read more...