Messages sent from Outlook, not in transport logs

Question

We had an interesting problem with our Exchange environment that has left a mystery behind.
A couple days ago, we had a catastrophic failure that took both of our mailbox and transport servers offline for approximately 1 hour. After we got the servers back online, we had reports of email not making it to recipients, both internal and external.
We looked everywhere for a problem, but we couldn't find any definite source, so we restarted the Exchange services on both servers. This fixed the mail flow problems, but now we cannot find any trace of the emails sent during this problem period.
Any ideas what would have happened, why emails were not left in users' outboxes, and why anything that didn't get delivered didn't throw an NDA at least? The emails DO appear in the users' sent items folder, just no record of them after that.

Answer 1

Hi,
You can check with your system/application logs, there are related logs generated.
When a fatal/permanent JET exception (logical corruption) has appeared in the database, the feature will be triggered so that the queue, log and system folders are moved (add .OLD to path), a
warning event will be fired to inform administrator that the transport database folders have been moved. After that, worker process will be restarted, and then try to attach a new database
If the transport component can’t move the old folder, the possible cause is that the target folder has already existed as the “Move”  action
will only perform once, the subsequent recovery action will fail along with event 17104 until the previous queue database backup has been renamed or deleted
You can see the entire recovery procedure in event 17102
If you want to stop this feature, please set the value of the “QueueDatabaseRecoveryAction” key to “None” in transport application config file:
C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config
<add key="QueueDatabaseRecoveryAction" value="None" />
Notes: The default setting is “Move”
Notes: After you stop the feature, transport service won’t try to recover the queue
if the corruption happens again. It’ll just log the error event in the application log and stop the transport service. Then, you need to follow the link from Anil to delete the old database, or repair it before the service can be started again
Hope this helps!
Thanks.
Niko Cheng
TechNet Community Support