. Конечно, вопрос о том, что произошло с сообщением, отправленным 88 дней назад, может показаться бессмысленным. В любом случае, мы сможете дать на него ответ – но только в системе Exchange Online. Локальные версии Exchange 2013 по-прежнему не охвачены данной функцией. И это тоже кажется бессмысленным.

Услышав о недавнем решении компании Microsoft расширить трассировку сообщений в системе Office 365 до 90 дней, я совсем запутался. Предлагаю вместе разобраться в том, что собой представляет механизм трассировки сообщений и зачем она нам в итоге нужна.

Механизм трассировки (или отслеживание) сообщений был частью системы Exchange очень долгое время. В названии этого механизма зашифрована фраза «так давно, что и не вспомнить». Поэтому я заглянул в копию своей книги «Microsoft Exchange Server: Planning, Design, and Implementation», раскрывающей секреты системы Exchange 4.0, опубликованной в августе 1996 года (для любителей телевикторин замечу, что книга имеет номер ISBN 1-55558-162-5 – и меня поразило, что эти копии еще можно приобрести (http://www.isbns.net/isbn/9781555581626)), и обнаружил следующий текст:

«Пользователи посылают сообщения по малейшему поводу, но иногда они не достигают цели, и когда это случается, на системного администратора ложится задача провести расследование и выяснить, что же случилось с письмом. Сообщение было отправлено не по нужному адресу? Шлюз запретил отправку сообщения? Может, сообщение застряло где-то в ожидании, пока будет установлено подключение к удаленной системе?»

Времена не сильно изменились, и я подозреваю, что этими же словами сегодня можно описать потребность в надежном механизме трассировки сообщений в системах Exchange 2013 и Exchange Online. Пользователи до сих пор иногда пребывают в недоумении, действительно ли сообщение доставлено адресату. Теперь, когда протокол SMTP стал общепринятым почтовым языком Интернета, роль шлюзов стала более скромной, но сообщения иногда «застревают». И пользователи все еще задают системным администраторам одни и те же вопросы, когда хотят выяснить, что случилось с их почтой.

В системах Exchange 2010 и Exchange 2013 приложение Outlook Web App содержит механизм Delivery Reports (http://blogs.technet.com/b/exchange/archive/2010/01/13/3409181.aspx), разработанный для того, чтобы пользователи могли получить ответы самостоятельно (см. экран 1). Механизм Delivery Reports использует те же журналы трассировки сообщений, что и запросы, создаваемые администраторами, и справляется в большинстве ситуаций. Механизм Delivery Reports также имеет возможность поиска по теме сообщения, что весьма полезно, ведь большинство пользователей сообщают тему того письма, судьба которого их интересует.

 

Поиск пропавшего сообщения в Outlook Web App
Экран 1. Поиск пропавшего сообщения в Outlook Web App

Механизм Delivery Reports не предназначен для получения полного описания пути сообщения. На самом деле, чтобы точно узнать, что случилось с сообщением, возможно, наряду с журналами трассировки сообщений, придется обратиться к дополнительным источникам данных, таким как журналы протокола SMTP на сервере.

В любом случае суть в том, что трассировка сообщений всегда была частью системы Exchange, а самые последние версии позволяют пользователям выполнять часть исследовательской работы самостоятельно. Администраторам остается задача анализа журналов трассировки сообщений, создаваемых на серверах, когда необходимо точно выяснить, что произошло с сообщением. Причина может быть в неисправности механизмов пересылки почты, однако иногда необходимо проверить, что правило транспорта оказывает на сообщение желаемый эффект. Механизм Delivery Reports не предоставляет информацию такого рода, и приходится «рыть землю», чтобы отследить путь сообщения с нужной детализацией.

Возвращаясь к новой возможности, поддерживаемой системой Office 365, в изменении периода трассировки с 7 дней до 90 есть один интересный момент. Он заключается в объеме данных, который придется анализировать для отслеживания сообщения за такой период времени. Если вы работаете с крупным клиентским доменом Office 365, поддерживающим тысячи активных пользователей, то количество записей может быть огромным (в статье TechNet (http://technet.microsoft.com/en-us/library/bb124375(v=exchg.150).aspx) объясняется, какие записи могут быть созданы для сообщения).

Журналы трассировки сообщений — это неструктурированные индексируемые файлы, доступ к которым осуществляется через службу Transport Log Search. Тем не менее, объем данных, который может потребоваться проанализировать при поиске, наводит на мысль, что нужен другой подход. Разработчики Microsoft не сообщили, какое хранилище они используют в своих центрах обработки данных для хранения хронологических данных журналов трассировки. Я думаю, что применяется технология SQL Server, и любые данные старше 7 дней автоматически загружаются в базу данных SQL Server и хранятся в ней до истечения периода хранения (90 дней). Впрочем, принимая во внимание, что речь идет о системе Exchange, для хранения может использоваться и база данных ESE. В любом случае, «магическую» связь между системой Exchange и данными обеспечивает новая команда под названием Start-HistoricalSearch (technet.microsoft.com/en-us/library/dn621132(v=exchg.150).aspx).

Для сравнения, на сервере Exchange 2013 журналы трассировки сообщений по умолчанию хранятся в течение 30 дней. Вы можете задать другой период, запустив команду Set-TransportService (technet.microsoft.com/en-us/library/jj215682(v=exchg.150).aspx). Например, для увеличения периода хранения до 90 дней введите:

Set-TransportService –MessageTrackingLogMaxAge 90:00.00.00

На TechNet я нашел информацию о том, что максимальный период хранения составляет 24855.03:14:07 или чуть более 68 лет. Мне это значение кажется несколько избыточным, но кто знает…

Примечательно, что команда Start-HistoricalSearch поддерживает использование параметров, предназначенных специально для поиска в журналах трассировки сообщений записей, связанных с действиями, выполняемыми транспортными правилами и политиками Data Loss Prevention (DLP) (специализированная форма транспортных правил). Я предполагаю, что эти возможности используются для поддержки аналитических отчетов DLP, к которым клиенты системы Office 365 могут обратиться через оснастку Exchange Administration Center (EAC).

Замечание для компании Microsoft: было бы здорово также предоставить возможность обращения к аналитическим отчетам DLP через оснастку EAC для клиентов, использующих локальные системы.

Компания Microsoft исправила механизм message trace раздела mail flow оснастки EAC, и теперь для поиска в периоде до 7 дней и для поиска в рамках более длительных периодов применяются различные пользовательские интерфейсы. Задачи поиска с временным окном до недели выполняются моментально, и результаты выводятся на экран. При выполнении настраиваемых задач поиска, покрывающих периоды более 7 дней, оснастка EAC отображает дополнительные поля для получения информации о том, необходимо ли включать в отчет данные о маршрутизации, а также о том, какие события необходимо отображать в отчете: входящие, исходящие или «все» (см. экран 2). Убедитесь в том, что выбран параметр, отвечающий за включение в отчет событий, связанных с сообщениями, и данных маршрутизации, иначе вы получите сильно упрощенный и менее полезный отчет. И наконец, вам придется указать адрес электронной почты для получения отчета (необходимо ввести адрес, принадлежащий одному из доменов, зарегистрированных в системе Office 365).

 

Оснастка EAC имеет дополнительные поля для?получения информации
Экран 2. Оснастка EAC имеет дополнительные поля для ?получения информации

Еще одно замечание для компании Microsoft: было бы хорошо, если бы клиенты локальных систем также могли выполнять задачи поиска по трассировке сообщений (http://technet.microsoft.com/en-us/library/bb124375%28v=exchg.150%29.aspx) через оснастку EAC. Необходимость использования команды Search-MessageTrackingLog (http://technet.microsoft.com/en-us/library/bb124926(v=exchg.150).aspx) в консоли EMS, конечно, является прекрасным стимулом для изучения оболочки PowerShell, однако такой подход быстро становится утомительным. Я знаю, что существует множество задач, которые необходимо решать в рамках проектирования пакета Exchange 2013 SP1 (http://windowsitpro.com/blog/exchange-server-2013-sp1-mixture-new-and-completed-features), но отсутствие данной возможности является одной из тех недоработок, которые раздражают пользователей.

После получения параметров оснастка EAC отправляет задачу поиска на выполнение в фоновом режиме. Я думаю, это разумно, принимая во внимание, какой объем данных может потребоваться проанализировать. Спустя определенное количество времени (зависящее от текущей загрузки центра обработки данных системы Office 365, в котором размещен ваш клиентский домен), трассировка будет завершена и результаты станут доступны. Вы можете просмотреть прогресс выполнения трассировки и взглянуть на результаты предыдущих трассировок, щелкнув по ссылке View pending or completed trace (см. экран 3).

 

Просмотр результатов трассировок
Экран 3. Просмотр результатов трассировок

Вы можете выбрать другой подход и использовать возможность отправления результатов трассировки на электронный адрес. Как только трассировка будет завершена, назначенному адресату придет сообщение, содержащее ссылку на полученные данные. Информация предоставляется в формате CSV и соответственно может быть обработана с помощью такого инструмента как Excel. Чтобы разобраться в содержимом данных, полученных на выходе трассировки сообщений, потребуется некоторое время, поэтому стоит попрактиковаться на данных, полученных из трассировки сообщений с простыми для понимания параметрами. Например, сообщений, полученных или отправленных вашим почтовым ящиком в течение небольшого периода времени – в таком примере у вас будут доступные сообщения, которые вы сможете сопоставить с полученными данными. Если вы еще не набили руку в интерпретации трассировок сообщений, информация, содержащаяся в загруженном файле, будет сложной для понимания. Попробуйте рассмотреть небольшой пример:

«1/16/2014 7:05:23 PM»,«10.242.109.11»,«AM3PR04MB433.eurprd04.prod.outlook.com»,«10.242.109.11»,«AM3PR04MB433»,«08D0D9963A8B8050»,«",»STOREDRIVER«,"RECEIVE»,«0",»«,"0248780b-3ec7-4a68-738f-08d0e1050b32»,«jethro.black@contoso.be;michael@vanhybrid@contoso.be;darrell.webster@contoso.nz;michael.smith@contoso.com;office365List@contoso.com»,«To;To;To;To;To»,«177559»,«5",»«,"»,«RE: Death to the List... Long Live Yammer Office365MVP group»,«Tony.Redmond@contoso.com», «Tony.Redmond@contoso.com»,«03I:»,«Originating»,«b662313f-14fc-43a2-9a7a-d2e27f4f3478»,«86.43.175.31»,«10.242.109.11»,«S:MailboxDatabaseGuid=4bf42761-7b04-4f22-9caa-46fe904b4fee;S:ItemEntryId=00-00-00-00-7E-EC-82-E9-14-DC-7C-4E-B9-2D-68-AF-15-61-67-AB-07-00-5E-F4-2B-B0-2D-CD-9F-4C-AE-D6-E3-A2-F5-48-0A-7D-00-00-00-DA-51-C8-00-00-23-93-68-96-5F-66-C8-40-85-4E-76-6C-EE-82-4F-09-00-00-AA-C9-30-83-00-00;S:DeliveryPriority=Normal»

Работа с данными через приложение Excel позволит вам более эффективно фильтровать записи и сортировать их по временной метке, что небесполезно, когда вы пытаетесь отследить путь сообщения (см. экран 4). К сожалению, некоторые записи, возвращаемые трассировкой сообщений, используют метки времени в разных форматах. Ну что ж, ничто не совершенно. И при работе с приложением Excel не ожидайте получить элегантное представление пути сообщения, аналогичное представлению в оснастке EAC при выполнении трассировки сообщений для данных в Интернете. Хотелось бы, чтобы программа могла анализировать загруженные файлы трассировки сообщений, но на данный момент анализ записей ложится на вас.

 

Информация трассировки в Excel
Экран 4. Информация трассировки в Excel

Задача поиска возвращает до 5000 записей, при превышении этого числа отчет усекается – хороший повод быть максимально точным при построении запросов трассировки сообщений. Отчеты остаются доступными в течение 10 дней.

Для тех, кто предпочитает использовать консоль EMS, не составит труда выполнить хронологическую трассировку. Например:

Start-HistoricalSearch -ReportTitle «Message Trace Search» -StartDate 1/1/2014 -EndDate 2/1/2014 -ReportType MessageTraceDetail -SenderAddress Kim.Akers@contoso.com -NotifyAddress Tony.Redmond@contoso.com –DeliveryStatus Delivered

Восемнадцать лет назад мы не имели представления о том, какой объем информации при трассировке сообщений будет генерироваться в результате пользовательской активности и работы агентов (вроде тех, которые выполняют модерирование писем или отвечают за выполнение правил транспорта), действующих в конвейере обработки сообщений. Мы также не знали, что возможно существование многоклиентных окружений, базирующихся на нескольких центрах обработки данных и обеспечивающих функционирование таких «облачных» служб как Office 365. Но даже тогда необходимо было отвечать пользователям на вопрос, что же случилось с их почтой. Приятно сознавать, что кое-что остается неизменным, правда?