Get-messagetrackinglog (exchangepowershell)

Требования к системе

Требования к программному обеспечению

Для исследования облачной среды необходимы следующие модули PowerShell:

Azure AD
Предварительная версия Azure AD в некоторых случаях
MS Online для Office 365
Exchange подключение к Exchange для использования единой системы поиска по журналу аудита (правил для почтовых ящиков, трассировок сообщений, правил пересылки, делегирования почтовых ящиков и др.)
Реагирование на инцидент Azure AD

При использовании команд Azure AD, которые не являются частью встроенных модулей Azure, вам необходим модуль MSOnline — тот же модуль, который используется для Office 365. Для работы с Azure AD (который содержит набор функций) из PowerShell установите модуль Azure AD.

Description

This cmdlet requires the ID for the message tracking report that you want to view. Therefore, first you need to use the Search-MessageTrackingReport cmdlet to find the message tracking report ID for a specific message, and then pass the results to this cmdlet. For more information, see Search-MessageTrackingReport.

You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they’re not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.

Possible delivery statuses

There is a total of 7 values of the delivery status for a message:

Delivered – the message reached the recipient. If a user cannot find a message with this status, it might have been deleted, or moved by an Outlook rule.
Expanded – the email was sent to a distribution group. Then, Exchange Server creates separate copies to send them to each distribution group member.
Failed – delivery failed. Message trace for such a message should include reasons for delivery failure.
Pending – Exchange Online attempts to send the email.
Quarantined – email never reached the mailbox, as it is held in quarantine.
Filtered as spam – server filtered the message, which means it went to the Junk Email folder.
Getting status – the delivery status is not known at a time. It’s best to retry the message trace in a few minutes.

There are two ways to track messages in Office 365 – PowerShell and EAC. Let’s have a look at them.

Контрольный список

Этот контрольный список поможет вам оценить процесс исследования и убедиться в том, что вы выполнили все необходимые действия.

Проверка исходного фишинга
Получить список пользователей, которые получили это сообщение электронной почты
Получите последние даты, когда у пользователя был доступ к почтовому ящику
Настроен ли для почтового ящика делегирован доступ?
Настроено ли для почтового ящика правило пересылки?
Просмотр правил транспорта почты
Поиск сообщений электронной почты
Прочитал ли пользователь или открыл сообщение электронной почты?
Кто другой адрес электронной почты?
Сообщение электронной почты содержало вложение?
Были ли во вложении что-то полезное?
Проверка заглавного адреса электронной почты на истинном источнике отправитель
Проверка IP-адресов злоумышленников и кампаний
Пользователь щелкнул ссылку в сообщении электронной почты?
На какой конечной точке было открыто сообщение?
Выполнена ли загрузка вложения?
Url-адрес или IP-адрес назначения были затронуты или открыты?
Был ли выполнен вредоносный код?
Какие учетные записи для федератов произошли при входе?
Что произошло с учетной записью для управляемого сценария?
Изучение IP-адреса источника
Исследование найденного ИД устройства
Изучение каждого ИД приложения

Вы также можете скачать контрольные списки фишинга и других инцидентов в Excel файла.

Необходимые роли и разрешения

Роли в Azure AD

Мы рекомендуем включить следующие роли для учетной записи, используемой для исследования:

В последнем случае вы всегда можете вернуться к роли глобального администратора

Роли в центре Microsoft 365 безопасности и соответствия требованиям

В целом роль «Глобальный читатель» или «Читатель безопасности» должна предоставить вам достаточно разрешений для поиска в соответствующих журналах.

Примечание

Если у пользователя есть роль «Только просмотр журналов аудита» или «Журналы аудита» на странице Разрешения в Центре соответствия требованиям безопасности, он не сможет Office 365 журнал аудита. В этом сценарии необходимо назначить разрешения в Exchange Online, так как Exchange Online используется для поиска в журнале.

Если вы реализовали управление доступом на основе ролей (RBAC) в Exchange или не знаете, какая роль вам нужна в Exchange, вы можете использовать PowerShell для получения ролей, необходимых для отдельного Exchange PowerShell:

Дополнительные сведения см. в этой Exchange разрешений.

Microsoft Defender для конечной точки

Если у вас уже включен и развернут Microsoft Defender для конечной точки (MDE), следует использовать его для этого потока. См. раздел Фишинг с обменом сигналами и машинным обучением.

Разрешения

Get-RoleGroupMember «Organization Management»	Эта команда возвращает список членов группы ролей управления Organization Management.
Get-ManagementRoleAssignment -Role «Mail Recipient Creation» -GetEffectiveUsers	Эта команда извлекает список пользователей, которым предоставлены разрешения роли управления Mail Recipient Creation. Сюда относятся пользователи, входящие в группы ролей или универсальные группы безопасности, которым назначена эта роль. Сюда не входят пользователи, входящие в связанные группы ролей из другого леса.
Get-ManagementRoleAssignment -RoleAssignee Administrator \| Get-ManagementRole \| Get-ManagementRoleEntry	Эта команда извлекает список командлетов, которые может запускать пользователь Administrator.

Get-ManagementRoleAssignment -WritableRecipient kima -GetEffectiveUsers \| FT RoleAssigneeName, EffectiveUserName, Role, AssignmentChain	Эта команда извлекает список пользователей, которые могут изменять почтовый ящик kima.
New-ManagementScope «Seattle Users» -RecipientRestrictionFilter { City -Eq «Seattle» } New-RoleGroup «Seattle Admins» -Roles «Mail Recipients», «Mail Recipient Creation», «Mailbox Import Export», -CustomRecipientWriteScope «Seattle Users»	Эта команда создает новую область управления и группу ролей управления, чтобы позволить членам группы ролей управлять получателями в Сиэтле. Сначала создается область управления Seattle Users, в которую входят только те получатели, у которых в атрибуте City объекта-пользователя имеется значение Seattle. Затем создается новая группа ролей Seattle Admins, которой назначаются роли Mail Recipients, Mail Recipient Creation и Mailbox Import Export. Группа ролей привязывается к области, поэтому ее члены смогут управлять только пользователями, попадающими в область фильтрации получателей Seattle Users.
New-ManagementScope «Vancouver Servers» -ServerRestrictionFilter { ServerSite -Eq «Vancouver» } $RoleGroup = Get-RoleGroup «Server Management» New-RoleGroup «Vancouver Server Management» -Roles $RoleGroup.Roles -CustomConfigWriteScope «Vancouver Servers»	Эта команда создает новую область управления и копирует существующую группу ролей, чтобы позволить членам новой группы ролей управлять только серверами из сайта Active Directory в Ванкувере. Сначала создается область управления Vancouver Servers, в которую входят только серверы, расположенные в сайте Active Directory Vancouver. Сайт Active Directory указывается в атрибуте ServerSite объектов-серверов. Затем создается новая группа ролей Vancouver Server Management, представляющая собой копию группы ролей Server Management. Новая группа ролей привязывается к области, поэтому ее члены смогут управлять только серверами, попадающими в область фильтрации конфигурации Vancouver Servers.
Add-RoleGroupMember «Organization Management» -Member davids	Эта команда добавляет пользователя davids в группу ролей Organization Management.
Get-ManagementRoleAssignment -Role «Mail Recipient Creation» -RoleAssignee «Seattle Admins» \| Remove-ManagementRoleAssignment	Эта команда удаляет роль Mail Recipient Creation из группы ролей Seattle Admins. Эта команда полезна, поскольку в ней не требуется знать имя назначения роли управления, связывающего роль с группой ролей.

Parameters

-DomainController

This parameter is available only in on-premises Exchange.

The DomainController parameter specifies the domain controller that’s used by this cmdlet to read data from or write data to Active Directory. You identify the domain controller by its fully qualified domain name (FQDN). For example, dc01.contoso.com.

Type:	Fqdn
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019

-GetMailboxLog

Type:	SwitchParameter
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

-Identity

Type:	ActiveSyncDeviceIdParameter
Position:	1
Default value:	None
Accept pipeline input:	True
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

-Mailbox

Name
Alias
Distinguished name (DN)
Canonical DN
Domain\Username
Email address
GUID
LegacyExchangeDN
SamAccountName
User ID or user principal name (UPN)

Type:	MailboxIdParameter
Position:	Named
Default value:	None
Accept pipeline input:	True
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

Type:	MultiValuedProperty
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

-ShowRecoveryPassword

The ShowRecoveryPassword parameter specifies whether to return the recovery password for the mobile phone as one of the displayed statistics. If this parameter is set to $true, the command returns the recovery password for the mobile phone as one of the displayed statistics.

Type:	SwitchParameter
Position:	Named
Default value:	None
Accept pipeline input:	False
Accept wildcard characters:	False
Applies to:	Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

Use the Exchange Management Shell to search the message tracking logs for message entries on multiple servers

Typically, the value in the MessageID: header field remains constant as the message travels throughout the Exchange organization. This property is named InternetMessageId in queue viewing utilities, and MessageId in the message tracking log viewing utilities. After you have determined the MessageID: value of a specific message, you can search for information about that message in the message tracking logs on every Mailbox server in your Exchange organization.

To search all message tracking log entries for a specific message across all Mailbox servers and Exchange 2010 Hub Transport servers, use the following syntax.

This example searches the message tracking logs on all Mailbox servers and Exchange 2010 Hub Transport server by using the following search criteria:

Find any entries related to a message that has a MessageID: value of . Note that you can omit the angle bracket characters ( ). If you don’t, you need to enclose the entire MessageID: value in quotation marks.
For each entry, display the fields date-time, server-hostname, client-hostname, source, event-id, and recipient-address.
Sort the results by the date-time field.

Дополнительная информация

Типы очередей

Существуют следую очереди:

Очереди доставки. Обычная очередь, содержащая письма для пересылки внешним и внутренним пользователям.
Очередь передачи. Не обработанные службой транспорта сообщения, но полученные ею.
Теневые очереди. Содержат копии отправляемых писем до момента подтверждения получения от mx-партнеров.
Очередь подозрительных сообщений. Изолированные сообщения, которые Exchange посчитал, потенциально, опасными. Это могут быть письма, содержащие зловредный код, а может быть и ложное срабатывание из-за ошибки программного обеспечения.
Сообщения с недостижимым местом назначения. Сообщения, которые не удалось доставить.

Где хранятся очереди Exchange

Очереди хранятся в базе данных ESE, которая находится в папке «%ExchangeInstallPath%TransportRoles\data\Queue»:

* mail.que — основной файл с базой очередей; tmp.edb — временный файл для проверки схемы самой базы; trn.chk — контрольные точки для отслеживания записи в логах.

Со временем, файл mail.que может разрастись и занимать много места. Для полной чистки базы ее можно просто создать заново. Для этого открываем службы Windows — останавливаем Microsoft Exchange Transport (перестанет работать почта) — переименовываем папку Queue, в которой находятся файлы базы и снова запускаем службу транспорта. Папка и база очереди создастся снова.

Смена пути хранения очереди

Открываем на редактирование файл %ExchangeInstallPath%\Bin\EdgeTransport.exe.config (C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config) и меняем значения ключей QueueDatabasePath и QueueDatabaseLoggingPath, например:

* где QueueDatabasePath — папка хранения файлов очереди; QueueDatabaseLoggingPath — папка хранения файлов журналов очереди.

Структура файлов журналов отслеживания сообщений

По умолчанию файлы журнала отслеживания сообщений существуют в %ExchangeInstallPath%TransportRoles \ Logs \ MessageTracking.

Конвенция именования файлов журналов в каталоге журнала отслеживания сообщений — это ymmdd-nnnn, yymmdd-nnnn, yyyymmdd-nnnn и yymmdd-nnnn . Различные журналы используются следующими службами.

MSGTRK. Эти журналы связаны со службой транспорта.
MSGTRKMA. Эти журналы связаны с утверждениями и отклонениями, используемыми модераторным транспортом. Дополнительные сведения см. в тексте Управление утверждением сообщений.
MSGTRKMD. Эти журналы связаны с сообщениями, доставленными в почтовые ящики службой доставки транспорта почтовых ящиков.
MSGTRKMS. Эти журналы связаны с сообщениями, отправленными из почтовых ящиков службой отправки транспорта почтовых ящиков.

Прототипы в именах файлов журналов означают следующее:

Местообладатель yyyymmdd — это дата согласованного универсального времени (UTC), на которой был создан файл журнала. yyyy = год, мм = месяц и dd = день.
nnnn- это номер экземпляра, который начинается со значения 1 ежедневно для каждого префикса имени файла журнала отслеживания сообщений.

Данные будут записываться в каждый файл журнала до тех пор, пока размер файла не достигнет максимально допустимого значения. После этого будет открыт новый файл журнала со следующим порядковым номером. Эта процедура повторяется в течение дня. Функциональная возможность циклического ведения журналов удаляет наиболее старые файлы журнала при выполнении одного из следующих условий:

файл журнала достиг максимального установленного срока хранения;

каталог журналов отслеживания сообщений достиг максимального размера.

Важно!
Максимальный размер каталога журналов отслеживания сообщений равен общему размеру всех файлов журнала, которые имеют одинаковый префикс имен. При расчете общего размера каталога не учитываются другие файлы, которые не соответствуют соглашению о префиксе имен

Переименование старых файлов журнала или копирование других файлов в каталог журналов отслеживания сообщений может привести к превышению заданного максимального размера каталога.На Exchange 2013 г. максимальный размер каталога журналов отслеживания сообщений в три раза больше указанного значения. Несмотря на то что файлы журнала отслеживания сообщений, создаваемые четырьмя различными службами, имеют четыре различных префикса имен, количество и частота данных, записываемых в файлы журнала MSGTRKMA, являются незначительными по сравнению с тремя другими префиксами.

Файлы журналов отслеживания сообщений представляют собой текстовые файлы с данными в формате CSV. Каждый файл журнала отслеживания сообщений имеет заголовок, содержащий следующие сведения:

# Программное обеспечение. Имя программного обеспечения, создав файл журнала отслеживания сообщений. Как правило, значением является: Microsoft Exchange Server.
# Версия. Номер версии программного обеспечения, создав файл журнала отслеживания сообщений. Текущее значение 15.0.0.0.
# Тип журнала: значение типа журнала, которое является журналом отслеживания сообщений.
# Дата: дата UTC, когда был создан файл журнала. Дата UTC представлена в формате дата-времени ISO 8601: yyyy-mm-dd T hh:mm:ss.fff Z, где yyyy = год, мм = месяц, dd = день, T указывает начало компонента времени, hh = час, мм = минута, ss = second, fff = доли секунды, а Z означает Zulu, который является еще одним способом обозначить UTC.
# Поля:: имена полей с запятой, используемые в файлах журнала отслеживания сообщений.

Structure of the message tracking log files

By default, the message tracking log files exist in %ExchangeInstallPath%TransportRoles\Logs\MessageTracking.

The naming convention for log files in the message tracking log directory is yyyymmdd-nnnn, yyyymmdd-nnnn, yyyymmdd-nnnn, and yyyymmdd-nnnn . The different logs are used by the following services:

MSGTRK: These logs are associated with the Transport service.
MSGTRKMA: These logs are associated with the approvals and rejections used by moderated transport. For more information, see Manage message approval.

The placeholders in the log file names represent the following information:

The placeholder yyyymmdd is the coordinated universal time (UTC) date on which the log file was created. yyyy = year, mm = month, and dd = day.
The placeholder nnnn is an instance number that starts at the value of 1 daily for each message tracking log file name prefix.

Information is written to each log file until the file size reaches its maximum specified value for each log file. Then, a new log file that has an incremented instance number is opened. This process is repeated throughout the day. The log file rotation functionality deletes the oldest log files when either of the following conditions is true:

A log file reaches its maximum specified age.
The message tracking log directory reaches its maximum specified size.

Important

The maximum size of the message tracking log directory is calculated as the total size of all log files that have the same name prefix. Other files that do not follow the name prefix convention are not counted in the total directory size calculation. Renaming old log files or copying other files into the message tracking log directory could cause the directory to exceed its specified maximum size.On Exchange 2013 Mailbox servers, the maximum size of the message tracking log directory is three times the specified value. Although the message tracking log files that are generated by the four different services have four different name prefixes, the amount and frequency of data written to the MSGTRKMA log files is negligible compared to the three other log file prefixes.

The message tracking log files are text files that contain data in the comma-separated value (CSV) format. Each message tracking log file has a header that contains the following information:

#Software:: Name of the software that created the message tracking log file. Typically, the value is Microsoft Exchange Server.
#Version:: Version number of the software that created the message tracking log file. Currently, the value is 15.0.0.0.
#Log-Type:: Log type value, which is Message Tracking Log.
#Date:: The UTC date-time when the log file was created. The UTC date-time is represented in the ISO 8601 date-time format: yyyy-mm-ddThh:mm:ss.fffZ, where yyyy = year, mm = month, dd = day, T indicates the beginning of the time component, hh = hour, mm = minute, ss = second, fff = fractions of a second, and Z signifies Zulu, which is another way to denote UTC.
#Fields:: Comma-delimited field names used in the message tracking log files.

Description

Консоль управления Exchange (GUI)

Графическая консоль удобна для быстрого периодического осмотра очереди или поиска сообщения.

Просмотр

Запускаем Консоль управления Exchange — переходим в раздел Инструменты — кликаем по Средство просмотра очереди:

Откроется список почтовых доменов, на которые недавно были попытки отправить сообщения. В первую очередь, нас интересует колонки «Количество сообщений» и «Последняя ошибка» — для решения проблем смотрим их:

Описание колонок

Тип доставки — определяет способ отправки писем и следующее действие (или очередь), которое будет выполнено с пересылаемым письмом. Может быть:
- DNSConnectorDelivery. Доставка с помощью SMTP-соединителя, созданного на локальном сервере. Разрешение маршрутизации с помощью DNS.
- NonSmtpGatewayDelivery. Используется очередь для доставки с помощью локального коннектора. SMTP не используется.
- SmartHostConnectorDelivery. Доставка внешнему получателю с помощью SMTP-соединителя. Разрешение маршрутизации с использованием промежуточного узла.
- SmtpRelayWithinAdSitetoEdge. Отправка письма внешнему получателю с помощью соединителя SMTP, который находиться на пограничном транспортном сервере.
- MapiDelivery. Доставка локальным получателям.
- SmtpRelayWithinAdSite. Сообщения помещаются в очередь для доставки на транспортный сервер-концентратор, находящийся на том же узле Active Directory, что и локальный сервер.
- SmtpRelaytoRemoteAdSite. Сообщения помещаются в очередь для доставки на сервер, находящийся на удаленном узле Active Directory.
- SmtpRelaytoTiRg. Сообщения помещаются в очередь для доставки группе маршрутизации Exchange Server 2003.
- Undefined. Сообщения помещаются в очередь отправки, а следующий пункт назначения прыжка еще не определен.
- Unreachable. Эти сообщения помещаются в очередь «Недостижимо», и задать маршрут к получателю невозможно.
Состояние — состояние очереди для конкретного домена.
- Активно или Установка связи. Передача выполняется в данный момент.
- Приостановлено. Передача не выполняется, и не будет выполняться автоматически.
- Готово. Передача закончена, сообщений нет в очереди.
- Повторить. Передача не выполняется, повторные попытки будут предприняты в ближайшее время.
Количество сообщений — отображает количество писем в очереди на отправку. Если 0, писем в очереди нет и в ближайшее время список должен пропасть. При наличии писем в очереди со статусами «Повторить» или «Приостановлено» говорит о том, что в результате отправки всех или некоторых писем до данного адресата, возникли ошибки.
Время следующей попытки — дата и время, когда сервер отправит письмо. Как правило, можно увидеть со статусом «Повторить».
Последняя ошибка — отображает код и текст последнее ошибки, которая возникла во время отправки сообщения.

Для поиска писем по критериям, возможно создать фильтр:

Возможные действия

Кликнув правой кнопкой мыши по списку очереди, мы получаем список возможных действий:

Посмотреть сообщения — отобразит список писем, которые входят в очередь для данного адресата.
Приостановить — не выполнять попыток отправлять письма.
Удалить сообщения (с отправкой отчета о недоставке) — очередь чиститься, отправителю отправляется уведомление.
Удалить сообщения (без отправки отчетов о недоставке) — очередь чиститься, отправителю ничего не отправляется.

Source values in the message tracking log

The values in the source field in the message tracking log indicate the transport component that’s responsible for the message tracking event. The following table describes the values of the source field.

Source value	Description
ADMIN	The event source was human intervention. For example, an administrator used Queue Viewer to delete a message, or submitted message files using the Replay directory.
AGENT	The event source was a transport agent.
APPROVAL	The event source was the approval framework that’s used with moderated recipients. For more information, see Manage message approval.
BOOTLOADER	The event source was unprocessed messages that exist on the server at boot time. This is related to the LOAD event type.
DNS	The event source was DNS.
DSN	The event source was a delivery status notification (also known as a DSN, bounce message, non-delivery report, or NDR).
GATEWAY	The event source was a Foreign connector. For more information, see Foreign Connectors.
MAILBOXRULE	The event source was an Inbox rule. For more information, see Inbox rules.
MEETINGMESSAGEPROCESSOR	The event source was the meeting message processor, which updates calendars based on meeting updates.
ORAR	The event source was an Originator Requested Alternate Recipient (ORAR). You can enable or disable support for ORAR on Receive connectors using the OrarEnabled parameter on the New-ReceiveConnector or Set-ReceiveConnector cmdlets.
PICKUP	The event source was the Pickup directory. For more information, see Pickup Directory and Replay Directory.
POISONMESSAGE	The event source was the poison message identifier. For more information about poison messages and the poison message queue, see Queues and messages in queues
PUBLICFOLDER	The event source was a mail-enabled public folder.
QUEUE	The event source was a queue.
REDUNDANCY	The event source was Shadow Redundancy. For more information, see Shadow redundancy in Exchange Server.
RESOLVER	The event source was the recipient resolution component of the categorizer in the Transport service. For more information, see Recipient resolution in Exchange Server.
ROUTING	The event source was the routing resolution component of the categorizer in the Transport service.
SAFETYNET	The event source was Safety Net. For more information, see Safety Net in Exchange Server.
SMTP	The message was submitted by the SMTP send or SMTP receive component of the transport service.
STOREDRIVER	The event source was a MAPI submission from a mailbox on the local server.

Configure message tracking

You can configure message tracking logs using the Set-TransportService cmdlet. Using this cmdlet, you can:

Enable or disable message tracking,
Change the location for storing message tracking logs,
Modify the size and age limits for message tracking logs
And enable or disable subject logging. A word of explanation: by default, message tracking logs do not store any content of emails, except for the subject line. While having the subject line in the logs greatly improves the tracking experience, some organizations require disabling this feature for security or privacy reasons.

Here is an example which changes all parameters at once:

The cmdlet above turns on message tracking for Mailbox_Server and sets the log storage to M:\logs. Size limit for a single log file is changed to 30 MB. It is mostly a cosmetic change, which controls the number of log files – the greater the limit, the less csv are created every day. The max directory size (before the oldest files are overwritten) is set to 2.5GB, and the log files are kept for 365 days. Setting the –MessageTrackingLogMaxAge to 00:00:00 will let you keep message tracking logs for an indefinite period. Or at least before the directory size is reached. But who needs to save space in Exchange, right?