Exchange 2013 — message trace shows ExplicitlyDiscarded HAdiscard on inbound missing email
I have an inbound email that a Get-MessageTrackingLog shows as arriving past the CAS server and into the mailbox server, but then shows as ExplicitlyDiscarded and HAdiscard.
RunspaceId : f73e23f6-64e7-43b4-98bd-9871aabc5396 Timestamp : 9/28/2015 8:53:10 AM ClientIp : ClientHostname : ServerIp : ServerHostname : MAIL5 SourceContext : ExplicitlyDiscarded ConnectorId : Source : SMTP EventId : HADISCARD InternalMessageId : 47266115095789 MessageId : Recipients : [email protected]> RecipientStatus : <> TotalBytes : 15273 RecipientCount : 3 RelatedRecipientAddress : Reference : MessageSubject : Your mailbox is almost full. Sender : [email protected] ReturnPath : [email protected] Directionality : Incoming TenantId : OriginalClientIp : MessageInfo : MessageLatency : MessageLatencyType : None EventData :
I can’t seem to find anything online other than that this is normal in deleting a shadowcopy from the primary mail server after delivering the email to the mailbox. However, in this instance there is no final actual DELIVER into the mailbox itself. The above is the final portion of the tracking log, which normally would state as «DELIVER» to the mailbox, but never got that far. Any ideas on how to determine what happened here on why the mail was discarded before the email was delivered to the mailbox itself?
EventId: События обработки почтового сообщения
При проведении анализа прохождения писем между почтовыми серверами организации Exchange или смежными почтовыми релеями, приходится наблюдать то или иное событие при обработке письма. Эти события можно увидеть в Exchange 2007/2010 в консоли Message Tracker, либо используя командлет PowerShell Get-MessageTrackingLog. Каждое событие EventId, соответствует этапу обработки письма. Ниже приведен список событий, которые могут возникнуть при обработке письма и их краткое описание. Часть из этих событий появилась только в новых версиях Microsoft Exchange и отсутствовала в ранних версиях.
| Имя события | Описание |
| AGENTINFO | Это событие используется транспортными агентами для журналирования данных. |
| BADMAIL | Сообщение отправлено Pickup каталогом или Replay каталогом и не может быть доставлено и возвращено. |
| CLIENTSUBMISSION | Сообщение было отправлено из папки «Исходящие» почтового ящика. |
| DEFER | Доставка сообщения отложена. |
| DELIVER | Сообщение было доставлено в локальный почтовый ящик. |
| DELIVERFAIL | Агент попытался доставить сообщение в папку, которой нет в почтовом ящике. |
| DROP | Сообщение было отклонено без уведомления о доставке (DSN или NDR). Например: ·сообщения о выполненных запросах модерации; ·спам сообщения. |
| DSN | Создано уведомление о доставке. |
| DUPLICATEDELIVER | Сообщение было доставлено получателю повторно. Повторная доставка сообщений может происходить в том случае, если получатель входит в несколько вложенных групп рассылки. Information store обнаруживает и удаляет дубликаты сообщений. |
| DUPLICATEEXPAND | При раскрытии группы рассылки обнаружен повторяющийся получатель. |
| DUPLICATEREDIRECT | Альтернативный получатель сообщения уже являлся получателем. |
| EXPAND | Группа рассылки была раскрыта. |
| FAIL | Не удается доставить сообщение. Источники: SMTP, DNS, QUEUE и ROUTING. |
| HADISCARD | Теневое сообщение было отвергнуто, после того как основная копия была доставлена на следующий узел. (Письмо доставлено следующему получателю и исключено из локальной очереди/хранилища) |
| HARECEIVE | Теневое сообщение было получено сервером в локальной группе обеспечения доступности баз данных или на сайте Active Directory. |
| HAREDIRECT | Создано теневое сообщение. |
| HAREDIRECTFAIL | Не удалось создать теневое сообщение. |
| INITMESSAGECREATED | Сообщение отправлено контролируемому получателю, поэтому оно отправлено в почтовый ящик вынесения решения для утверждения. |
| LOAD | Сообщение успешно загружено при загрузке. |
| MODERATIONEXPIRE | Модератор контролируемого получателя не утвердил и не отклонил сообщение, поэтому для него истек срок ожидания. |
| MODERATORAPPROVE | Модератор контролируемого получателя утвердил сообщение, поэтому оно было доставлено контролируемому получателю. |
| MODERATORREJECT | Модератор контролируемого получателя отклонил сообщение, поэтому оно не было доставлено контролируемому получателю. |
| MODERATORSALLNDR | Все запросы для утверждения, отправленные всем модераторам контролируемого получателя, не могли быть доставлены и привели к отправке отчетов о недоставке (NDR). |
| NOTIFYMAPI | Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере. |
| NOTIFYSHADOW | Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере, и необходимо создать теневую копию сообщения. |
| POISONMESSAGE | Сообщение помещено в очередь сообщений о сбое или удалено из нее. |
| PROCESS | Сообщение успешно обработано. |
| PROCESSMEETINGMESSAGE | Сообщение о собрании обработано службой транспортной доставки почтовых ящиков. |
| RECEIVE | Сообщение было получено от службы транспорта или из Pickup/Replay каталогов (источник: SMTP), или сообщение было отправлено из почтового ящика в службу отправки почтовых ящиков (источник: STOREDRIVER). |
| REDIRECT | Сообщение было перенаправлено другому получателю в результате поиска в Active Directory. |
| RESOLVE | В результате поиска в Active Directory для получателей сообщения был найден другой адрес электронной почты. |
| RESUBMIT | Сообщение было автоматически повторно отправлено из сети безопасности. |
| RESUBMITDEFER | Сообщение, повторно отправленное из сети безопасности, было отложено. |
| RESUBMITFAIL | Сообщение, повторно отправленное из сети безопасности, не удалось отправить. |
| SEND | Сообщение было отправлено протоколом SMTP. |
| SUBMIT | Служба отправки почтовых ящиков успешно передала сообщение службе транспорта. Для событий SUBMIT свойство source-context содержит следующие данные: ·MDB GUID базы данных почтовых ящиков. ·Mailbox GUID почтового ящика. ·Event Порядковый номер события. ·MessageClass Тип сообщения. Например, IPM.Note. ·CreationTime Дата и время отправки сообщения. ·ClientType. Примеры: User, OWA и ActiveSync. |
| SUBMITDEFER | Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта была отложена. |
| SUBMITFAIL | Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта не была выполнена. |
| SUPPRESSED | Передача сообщения была отменена. |
| THROTTLE | Сообщение попало под регулирование доставки (Throttling). |
| TRANSFER | Письмо было разделено из-за множества получателей или ограничения получателей или агентов транспорта. Источники: ROUTING или QUEUE. |
Рубрика: Документация | Метки: EventId, Get-MessageTrackingLog | Комментарии | Permalink
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Message Tracking Log : HARECIEVE but no RECIEVE or Other event
I currently running 32 exchange server. I tried to track a message as a user complained for didn’t recieve some email and i found something strange. There is HARECIEVE/HADISCARD event which means its a shadow copy of the original one, if im not mistaken. But i can’t find the RECIEVE or any other log event for that email, how is this possible? any idea where is that original email log at? I’ve try to search at each server and can’t find one.
New contributor
Popular Topics in Microsoft Exchange
check Best Answer
Microsoft Exchange Expert
- check 52 Best Answers
- thumb_up 132 Helpful Votes
2022-03-22T07:04:34Z check Best Answer
So. I would like to confirm that the did user actually receive this email?
And did you send emails in bulk?
Here’s a similar case for you reference.
In this case, OP increased the receive connector’s limit to 200.
set-receiveconnector -identity nameofconnector -MaxInboundConnectionPerSource 200
1 found this helpful thumb_up thumb_down
2 Replies
Microsoft Exchange Expert
- check 52 Best Answers
- thumb_up 132 Helpful Votes
2022-03-22T07:04:34Z check Best Answer
So. I would like to confirm that the did user actually receive this email?
And did you send emails in bulk?
Here’s a similar case for you reference.
In this case, OP increased the receive connector’s limit to 200.
set-receiveconnector -identity nameofconnector -MaxInboundConnectionPerSource 200
1 found this helpful thumb_up thumb_down
No, user reported that email did not received. The email was send as normal conversation email, no bulk email. And that strange behavior just happen in that day, no further complain until now, log seems normal there is HARECEIVE log and RECEIVE log. So to prevent such case happen again, i want to find the culprit. Refer to the case that you send, i’ve checked my configuration and it has 20 max inbound conn/source in all server. But seems like its not the culprit, email working fine until now with that value as all server is connected to the load balancer. Or do you think it not sufficient enough for certain peak busy hour? we run about 25500 mailbox.
Was this post helpful? thumb_up thumb_down
This topic has been locked by an administrator and is no longer open for commenting.
To continue this discussion, please ask a new question.
Exchange 2013 — не дошло письмо, причины?
Коллеги, помогите распутать дело и понять, что в каких логах я могу найти.
Ситуация: 11.03.2021 с ящика1 было отправлено письмо от имени ящика2.
В копии стояли ящик3 и ящик4 + ящики5-25 в скрытой копии.
Никаких ошибок на ящик1 или на ящик2 не пришло.
В журнале транзакций упоминание о данном письме есть, тип событий STOREDRIVER,RECEIVE и STOREDRIVER,SUBMIT.
Поиском search-mailbox письмо не находится ни в одном из ящиков, кроме отправителя.
Если я через ECP запрашиваю отчёт mail flow -> delivery reports доставки этого письма одному из получателей, вижу такое:
Писем в очереди нет.
Есть ощущение, что письмо не дошло ни в один из ящиков, которые были получателями/скрытыми получателями.
Но я не понимаю, где мне искать причины недоставки и само письмо, если оно где-то ещё висит (смущает статус Pending).
UPD (06/04/2021) — оказалось, что получателей было 46, а лимит транспорта — 42. Теперь пытаюсь найти журнал с ошибкой по данному письму и понять почему не получил NDR.
- Вопрос задан более двух лет назад
- 1420 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 2
Попробуйте поискать сообщение через get-messagetrackinglog с указанием ID письма.
Это даст развернутый лог по статусу со всеми timestamps.
Ответ написан более двух лет назад
Нравится 1 6 комментариев
Виктор @necroic Автор вопроса
Спасибо за наводку, попробовал, но ничего нового не вижу (сокращённый вариант):
Timestamp : 3/11/2021 1:33:37 PM
Source : STOREDRIVER
EventId : RECEIVE
Timestamp : 3/11/2021 1:33:37 PM
Source : STOREDRIVER
EventId : SUBMIT
Но что меня заинтересовало:
RecipientCount : 46
У меня же по команде Get-TransportConfig | fl MaxRecipientEnvelopeLimit выводится:
MaxRecipientEnvelopeLimit : 42
Это зацепка, но NDR не было ни на ящик1 (отправитель) ни на ящик2 (от чьего имени отправляли, группа), где мне поискать журнал всех NDR, которые были отправлены внутренним получателям?
Виктор @necroic Автор вопроса
И ещё, насколько я помню принцип этого ограничения, первым 42-м доставляется письмо, всем остальным нет и приходит NDR отправителю.
Тут не получил никто.
Виктор, у Вас только один сервер или есть ещё, есть ли DAG? Конфигурация не гибридная?
Виктор @necroic Автор вопроса
Евгений, Только один сервер, без DAG.
Что Вам выдает get-message ?
Виктор @necroic Автор вопроса
При первом запуске было 3 сообщения в статусе Ready, одно в статусе Active.
Ни одно из них не было связано с рассылкой 11.03.
При повторно запуске командлета результата не было. не было писем.
если есть STOREDRIVER — значит таки дошло по идее. надо смотреть, куда.
в очереди не болтается ?
а для спорных ситуаций на будущее включайте аудит на ящиках 🙂
Ответ написан более двух лет назад
Виктор @necroic Автор вопроса
Все сотрудники утверждают в один голос, что его не получали.
Снова же, репорта об успешной доставке у меня нет.
search-mailbox не находит его ни в ящике, ни в дампстере, вообще нигде ни у кого.
Что касается аудита на ящиках — мы с вами о чём говорим, что это за функционал и стоит ли его превентивно включать на все ящики сразу?
Ящиков ~1300.
Виктор, что конкретно написано в событиях про STOREDRIVER ?
там написано, кому именно оно доставлено. А говорить могут все что угодно
аудит — это свойства почтового ящика, AuditEnabled и другие Audit* — логи манипуляций с письмами в ящике, места занимает немного, но позволяет узнать кто какие письма удалял, перемещал.
Виктор @necroic Автор вопроса
Я прикладываю два найденных события, но там не увидел ничего интересного.
Обращу внимание, что события только два, нет аналогичных для каждого из получателей.
У меня возникло ощущение, что эти события связаны только с отправкой.
spoiler
2021-03-11T10:33:37.551Z. 1,Srv-Exchange.firma.local. 1,Srv-Exchange,08D8AE6D2856C69E,,STOREDRIVER,RECEIVE,0,,95cdf077-ef56-4a0c-4c11-08d8e4792167, список_получателей,To;To;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc;Bcc,16247,46. Установка программы \ Электронный документооборот, отправитель , help@firma.com,04I: ,Originating,,dyenh. 1,S:MailboxDatabaseGuid=44f38109-d210-41c9-908b-8ed60e0a43d0;S:ItemEntryId=00-00-00-00-9D-A2-AD-3F-FF-D5-38-41-95-2B-35-32-CE-59-85-9F-07-00-31-6C-38-F9-4F-65-C4-4C-95-AC-0F-08-F9-A3-3A-8A-00-00-00-00-01-0B-00-00-31-6C-38-F9-4F-65-C4-4C-95-AC-0F-08-F9-A3-3A-8A-00-04-74-D4-48-F7-00-00;S:DeliveryPriority=Normal;S:AccountForest=firma.local;S:PurportedSender=help@firma.com
spoiler
2021-03-11T10:33:37.755Z. 1,SRV-EXCHANGE,,Srv-Exchange.firma.local,»MDB:44f38109-d210-41c9-908b-8ed60e0a43d0, Mailbox:1e3414c9-b431-4f54-af08-4d4d84395389, Event:250204663, MessageClass:IPM.Note, CreationTime:2021-03-11T10:33:36.942Z, ClientType:MOMT»,,STOREDRIVER,SUBMIT. 95cdf077-ef56-4a0c-4c11-08d8e4792167,список_получателей . 46. Установка программы \ Электронный документооборот,отправитель,,2021-03-11T10:33:36.942Z;LSRV=Srv-Exchange.firma.local:TOTAL-SUB=0.812|SA=0.500|MTSSDA=0.003|MTSSDC=0.085|SMSC=0.007|SMS=0.144|MTSSDMO=0.152|MTSSDPL=0.065|MTSSDSS=0.011|MTSSD=0.268|MTSS=0.268,Originating,,192.168.165.187,,S:ItemEntryId=00-00-00-00-9D-A2-AD-3F-FF-D5-38-41-95-2B-35-32-CE-59-85-9F-07-00-31-6C-38-F9-4F-65-C4-4C-95-AC-0F-08-F9-A3-3A-8A-00-00-00-00-01-0B-00-00-31-6C-38-F9-4F-65-C4-4C-95-AC-0F-08-F9-A3-3A-8A-00-04-74-D4-48-F7-00-00;S:PurportedSender=help@firma.com