Логи Exchange 2013 Mailbox Transport

MapiExceptionNetworkError: Unable to mount database
www.microsoft.com

Анализировать логи Exchange 2013 Mailbox Transport необходимо не обособленно, а совместно с логами других служб транспортного конвейера Exchange 2013, ведь Транспортная служба почтовых ящиков всего лишь его часть. Стоит сразу отметить, что эта служба в реальности состоит из двух отдельных служб Windows и в этом заключается её главная особенность по сравнению, например, с Транспортной службой роли MBX и Транспортной службой переднего плана роли CAS.

Это третья и последняя статья из серии, посвященной управлению логированием служб 1 транспортного конвейера Exchange 2013, а вот полный список:

А также статьи о принципе работы этих служб:

Они должны пролить свет на принцип работы транспортного конвейера Exchange 2013.


Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики – Exchange 2013 — Установка, настройка, администрирование.


Логи Exchange 2013 Mailbox Transport

Как я упоминал выше, Транспортная служба почтовых ящиков в реальности имеет две отдельные службы Windows:

  • Служба доставки почтовых ящиков (Отображаемое имя – Microsoft Exchange Mailbox Transport Delivery, сокращенное – MSExchangeDelivery);
  • Служба отправки почтовых ящиков (Отображаемое имя – Microsoft Exchange Mailbox Transport Submission, сокращенное – MSExchangeSubmission).

Первая служба отвечает за доставку почты в почтовые ящики от других отправителей, вторая – за отправку почты из почтовых ящиков (подключаясь к БД по RPC, служба извлекает сообщения, подготовленные для отправки другим получателям). Подробнее о принципе работы читайте в статье Служба Exchange 2013 Mailbox Transport.

Тем не менее, существует один набор командлетов PowerShell для единого управления Транспортной службой почтовых ящиков:

  • Get-MailboxTransportService 2;
  • Set-MailboxTransportService 3.

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

1. Для начала убедимся, что все пути лог-файлов определены и ведение журналов активировано. Сделать это можно с помощью описанного выше командлета Get-MailboxTransportService в Exchange Management Shell:

Логи Exchange 2013 Mailbox Transport 01

Для этой службы справедливо практически все, что было сказано в статьях о других службах транспортного конвейера, в том числе и касательно правил ведения журналов –  активировать ведение журналов можно двумя способами – определив путь (значение $null отключает логи компонента) и установив необходимое значение параметра включения/отключения логов. Но есть все то же ограничение: если параметр пути до файлов логов имеет значение $null, а атрибут ConnectivityLogEnabled (на примере активации ведения логов журнала подключений) имеет значение $true, то в журнале событий будут зарегистрированы ошибки.

Компоненты, для которых помимо пути до файлов логов нужно явно указывать параметр включения/отключения, по умолчанию все включены:

Логи Exchange 2013 Mailbox Transport 03

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

Логи Exchange 2013 Mailbox Transport 02

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

3. И последняя задача, которую нам необходимо сделать – активировать ведение журнала для Службы доставки почтовых ящиков, то есть для сообщений, которые были отправлены от Транспортной службы к Службе доставки почтовых ящиков на сервере с ролью MBX. Хочу напомнить, что Транспортная служба почтовых ящиков (Служба доставки почтовых ящиков является её частью) взаимодействует с Транспортной службой по протоколу SMTP. При этом речь идет как о локальной Транспортной службе, расположенной на том же самом сервере, так и о Транспортных службах на других серверах с ролью MBX.

Активируем ведение журналов:

По умолчанию параметр MailboxDeliveryConnectorProtocolLoggingLevel имеет значение None.

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

Путь до log-файлов Назначение
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\Connectivity журнал подключений
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\AgentLog\Delivery журнал агента для службы Mailbox Transport Delivery
%ExchangeInstallPath%TransportRoles\Logs\Throttling\Delivery журнал регулирования доставки в почтовый ящик
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\AgentLog\Submission журнал агента для службы Mailbox Transport Submission
%ExchangeInstallPath%TransportRoles\Mailbox\Hub\PipelineTracing журналы конвейерной трассировки
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive журнал протокола для всех получающих соединителей данного сервера
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend журналы протокола для соединителей отправки

В документации нужно обратить внимание на описание двух последних типов журнала. Описание первого:

Параметр ReceiveProtocolLogPath указывает путь к каталогу журнала протокола для всех получающих соединителей данного сервера. … Для отключения ведения журнала протокола рекомендуется использовать командлет Set-ReceiveConnector, чтобы задать параметру ProtocolLoggingLevel значение None на каждом получающем соединителе.

Описание второго:

Параметр SendProtocolLogPath указывает путь к журналам протокола для соединителей отправки. … Для отключения ведения журнала протокола рекомендуется использовать командлет Set-SendConnector, чтобы задать параметру ProtocolLoggingLevel значение None на каждом отправляющем соединителе или чтобы задать параметру IntraOrgConnectorProtocolLoggingLevel значение None.

Обратите внимание на этот момент.

Хочу напомнить, что Транспортная служба почтовых ящиков является конечным назначением для получаемых сообщений и стартовой точкой для отправляемых. Тем не менее, далеко не все сообщения будут проходить через эту службу. Многие из входящих сообщений будут отсеяны как спам на этапе проверок транспортных агентов, то есть эти сообщения не уйдут дальше Транспортной службы серверов MBX, а в некоторых случаях даже дальше Транспортной службы переднего плана роли CAS.

Понимание потока обработки почты является ключевым при анализе логов и в этом вам поможет статья Поток обработки почты при разной топологии Exchange 2013.

Яндекс.Метрика