В состав Microsoft Exchange Server всегда входило средство Message Tracking Center, с помощью которого отслеживался маршрут прохождения сообщений между серверами и организациями. Message Tracking Center — это часть административной программы Microsoft Exchange 5.5, найти его можно в меню Tools консоли Exchange System Manager (ESM) сервера Exchange 2000 Server. В обеих версиях Microsoft Exchange Server эффективность функции зависит от уровня информативности журналов трассировки сообщений. В этой статье речь пойдет о том, как Exchange 2000 регистрирует ход обработки сообщения и как можно использовать Message Tracking Center для поиска пропавшего сообщения.

Журналы трассировки сообщений

По умолчанию в свойствах Exchange 2000 включена функция трассировки сообщений. Каждый день сервер создает новый журнал трассировки сообщений, Message Tracking Log, имя которого соответствует дате (например, 20030725.txt). Exchange 2000 хранит журналы в сетевом каталоге server_name.log, и размещается этот каталог обычно на том же диске, что и программы Exchange 2000. На Экране 1 приведен пример типичного набора журналов трассировки сообщений.
Экран 1. Набор журналов трассировки.

Когда клиент предлагает серверу свое сообщение, Exchange 2000 генерирует уникальный идентификатор сообщения и записывает его в журналы трассировки, позволяя, таким образом, проследить историю сообщения с момента его создания и до поступления к месту назначения. Вот пример идентификатора, созданного средствами API клиента: BE8B1DCC92D77E4C9CC70E141E3B583B02226F @EXCSERVER.acme.org. Важно отметить, что идентификатор не совпадает с MAPI-идентификатором, прописанным в свойствах сообщения. Единственная часть показанного выше идентификатора, которая «связана с человеком», — это имя сервера (EXCSERVER.acme.org) в самом конце строки. Все остальное позволяет выстроить цепочку событий, связанных с обслуживанием сообщения, и проследить ее с помощью Message Tracking Center.

Клиенты, использующие POP3 и IMAP4, генерируют собственные идентификаторы сообщений в форме 000001c19dbf$78c6bf90$7705d110@acme.org. Если не считать различий в форматировании, основное отличие идентификаторов MAPI от остальных идентификаторов, генерируемых другими клиентами (Microsoft Outlook Express, например), заключается в отсутствии имени сервера. Идентификаторы, созданные тем или иным клиентом, можно отыскать в поле Linked-MSGID журнала трассировки. Кроме того, идентификатор сообщения виден и при выводе трассы сообщения и просмотре его истории.

Чтобы включить трассировку сообщений, настраиваются три параметра почтового сервера. Для установки (или для проверки) состояния этих настроек следует открыть ESM, затем контекстное меню сервера, на котором необходимо запустить трассировку сообщений, выбрать Properties и щелкнуть вкладку General. На Экране 2 показаны описанные свойства и видно, что по умолчанию они не активизированы.

Экран 2. Установка свойств трассировки сообщения.
То же самое можно проделать при помощи системной политики (см. Экран 3), выполнив при этом необходимые настройки для нескольких серверов, составляющих некую административную группу.
Экран 3. Политика трассировки сообщений.

Если настройки недоступны, это означает, что либо данный сервер управляется системной политикой, либо у пользователя недостаточно полномочий для изменения соответствующих параметров. Вот эти параметры.
  • Enable subject logging and display ("активизация регистрации и вывода темы сообщения"). Это свойство определяет, будет ли Exchange 2000 записывать информацию о теме сообщения в журналы Message Tracking Log и отображать ее при составлении трассы. Тема сообщения может содержать конфиденциальную информацию, поэтому в ряде случаев такие данные по умолчанию не собираются. Однако пользователь может и не помещать конфиденциальные данные в тему (или же предварительно зашифровать их), а поле Subject позволяет отфильтровать нужные сообщения, что особенно полезно, если трафик пользователя велик. Вреда не будет, если данные поля Subject будут присутствовать в трассе.
  • Enable messaging tracking (активизация трассировки сообщения). Это свойство означает, что Exchange 2000 приступает к созданию и распространению сообщения в журналах трассировки. При активизации данного параметра Transport Engine регистрирует каждое обрабатываемое сообщение и каждый день создает новый журнал. Системные сообщения - например, пересылаемые между серверами сообщения с описанием иерархии Public Folder - не регистрируются.
  • Remove log files (after a specified number of days) ("Удаление журнальных файлов через указанное число дней"). Значение по умолчанию - 10 дней, и Exchange 2000 System Attendant всякий раз после полуночи удаляет устаревшие файлы. Учитывая объем дискового пространства современных серверов, скорее всего, пользователи могут хранить историю сообщений дольше, чем это действительно необходимо. Вряд ли журналы трассировки способны вызвать переполнение диска - даже с десятидневной историей общий объем данных на самом нагруженном сервере не превысит 750 Мбайт. Но если пользователь может ждать 10 дней, прежде чем попросить администратора проследить путь сообщения, которое он предполагал получить, но не получил, вряд ли это сообщение так уж важно для пользователя.

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

Трассировка сообщений

Message Tracking Center используется для прослеживания маршрута сообщения. Управление Message Tracking Center реализовано через оснастку Exchange 2000, которая может быть оформлена как прикладная консоль, но чаще всего доступ к центру трассировки осуществляется с помощью ESM Tools, как показано на Экране 4. После того как центр трассировки запущен, можно указать критерий для начала поиска.
Экран 4. Запрос на трассировку и результаты.

Очевидно, что чем более полной информацией о трассируемом сообщении располагает пользователь (время отправки сообщения, отправитель, тема), тем лучше. Поиск по весьма расплывчатому критерию — «сообщение было отправлено четыре дня тому назад группе пользователей» — выполнить значительно труднее, чем отыскать сообщение, которое «было отправлено вчера днем». На Экране 4 показан результат поиска, который отфильтровал одно сообщение, отосланное мною указанному пользователю. Отмечу, что на данном сервере параметр Enable subject logging and display не установлен, поэтому тема сообщения в состав журнала трассировки не включена, и Message Tracking Center не в состоянии отобразить эту информацию.

Кнопки Sender и Recipients позволяют выполнять поиск в Active Directory (AD) для пользователей, контактов или групп, которые посылают или получают данное сообщение. Message Tracking Center не начнет поиск до тех пор, пока не будут указаны точные данные отправителя и получателя. По умолчанию Message Tracking Center подразумевает, что поиск предполагается начать на том сервере, который был выбран пользователем при нажатии кнопки Server, но при желании можно подключиться к другому серверу и начать поиск на нем (например, если почтовый ящик отправителя расположен на соседнем сервере).

Даже для очень больших серверов с огромными томами, заполненными почтовыми данными, поиск выполняется достаточно быстро — в пределах нескольких минут. Когда Message Tracking Center необходимо связаться с другими серверами для получения данных (особенно когда адресат сообщения — большой список рассылки, Distribution List, DL), может показаться, что центр «зависает», но это не так — надо просто дождаться завершения обработки.

Помимо доработок пользовательского интерфейса Message Tracking Center, привнесенных пакетом изменений Exchange 2000 Service Pack 2 (SP2), — теперь графический интерфейс сочетает в себе прежние возможности Message Tracking Center и функциональность Outlook Find Message — изменения коснулись и архитектуры поисковой программы. В более ранних версиях, до появления SP2, сервер выполнял поиск, связываясь по мере необходимости с каждым сервером в трассе сообщения, извлекал все данные из удаленного журнала трассировки, после чего поиск в этих данных продолжался. Начиная с SP2, локальный сервер посылает запрос службе Exchange Management Service, запущенной на каждом сервере, на поиск данных, которые так или иначе связаны с сообщением. Поиск в журнале осуществляется силами удаленной службы, а серверу, инициировавшему запрос, возвращаются уже готовые результаты (но для этого необходимо установить SP2 или более позднюю версию пакета исправлений на удаленный сервер).

Чем точнее критерий поиска, тем меньше сообщений будет получено в результате. Поиск на Экране 4 дал только одно сообщение, и это, вероятно, именно то, что мне нужно. Однако если критерий задан не точно, Message Tracking Center может вернуть 10 и более сообщений. Тогда пользователю самому придется решать, что именно следует выбрать. Чтобы просмотреть подробные сведения об истории сообщения в Routing Engine, требуется выбрать сообщение и дважды щелкнуть по нему.

На Экране 5 показан пример истории сообщения. В данном случае эта история довольно проста, поскольку сообщение было отправлено всего лишь двум SMTP-адресатам. И снова, так как нужное свойство не задано, в трассе отсутствует тема сообщения. Из истории видно, что после того, как сообщение было отправлено (т. е. покинуло Store), компоненты Routing Engine — Advanced Queueing и Categorizer — продолжают его обработку и определяют, нужно ли доставлять сообщение удаленному SMTP-получателю. Затем Routing Engine пересылает его на сервер, который поддерживает SMTP-коннектор, с тем, чтобы сообщение дошло до конечного адресата.

Экран 5. История обработки сообщения.

Если взглянуть на сообщение, отправленное пользователям в другие группы маршрутизации (routing group), можно заметить, что Routing Engine пересылает сообщение агенту Message Transfer Agent (MTA) для дальнейшей его доставки получателю X.400 или серверу Exchange 5.5. Или же сообщение может использовать SMTP для перехода на сервер-мост (Bridgehead Server) в той же группе маршрутизации для продвижения сообщения в другие группы маршрутизации, или, если сервер содержит коннектор такой группы, напрямую серверам в других группах маршрутизации.

Если сообщение передается в другие маршрутные группы, Message Tracking Center перечисляет серверы-мосты в структуре дерева в зоне Location (слева). По мере обработки трассы сообщения это дерево разрастается, и в него попадают все новые серверы в рамках группы маршрутизации, получившие копию данного сообщения.

Помимо получателей, которые являются владельцами локальных почтовых ящиков, Message Tracking Center может также показать список получателей в Public Folders. Организации нередко используют Public Folders как архив сообщений, отосланных в группы рассылки, но в терминах рассылки Exchange 2000 обрабатывает эти сообщения точно так же, как при отправлении сообщений в локальный почтовый ящик. Понять, что сообщение предназначено для Public Folder, помогает имя получателя, по которому можно установить, что речь идет скорее о Public Folder, нежели о реальном пользователе.

Message Tracking Center отслеживает все стадии обработки сообщения, пока оно не достигнет конечного пункта назначения или же не встретит на своем пути сервер, для которого не активизирована функция трассировки. Как уже отмечалось, Message Tracking Center зависит от функционирования трассировки на каждом сервере организации, так что при отсутствии журналов трассировки на каком-то одном сервере история сообщений, полученная с помощью Message Tracking Center, может оказаться неполной.

Формат журнала трассировки

Записи журнала трассировки состоят из полей (список полей приводится ниже), разделенных табуляторами. Некоторые из них приведены на Экране 6 в формате Microsoft Excel.
  • Дата и время отправки сообщения. Exchange 2000 устанавливает эти значения в соответствии со временем, когда сообщение впервые попало для обработки на сервер, а не тогда, когда оно достигло сервера, на котором хранится журнал трассировки.
  • IP-адрес и сетевое имя клиента, сгенерировавшего сообщение.
  • Партнер или служба сообщений, которому или которой Routing Engine передает сообщение для дальнейшей обработки (т. е. Store или локальная рассылка).
  • IP-адрес и имя сервера, на котором было сгенерировано сообщение.
  • Адрес получателя. При отправлении сообщения он отображается в Exchange 2000 в виде внутреннего формата X.500. Этот же адрес отображается в формате SMTP после того, как сообщение будет обработано компонентом Categorizer (Event ID 1023).
  • Идентификатор события, указывающий на особенности выполненной обработки.
  • Уникальный идентификатор сообщения - он остается неизменным, сколько бы серверов ни участвовало в пересылке сообщения адресату.
  • Приоритет сообщения: низкий (-1), нормальный (0) или высокий (1).
  • Суммарный размер сообщения в байтах.
  • Флаг-статус шифрования сообщения: цифровая подпись (1), шифрованное сообщение (2), плоский текст (0).
  • Версия программы Routing Engine, запущенной на локальном сервере или версия сервера SMTP на удаленном сервере.
  • Тема сообщения, если указание темы допускается соответствующей установкой в свойствах сервера. Строка укорачивается до 256 байт, если это необходимо.
  • Число получателей сообщения.
  • Электронный почтовый адрес отправителя. Это значение совпадает с основным адресом почтового ящика, если, конечно, он известен. Он может быть прописан в формате X.400, SMTP или Distinguished Name (DN) - в зависимости от используемого почтового транспорта для данного сообщения.

Знакомство с данными журнала трассировки

Самый простой способ ознакомиться с данными журнала трассировки — скопировать содержимое журнала в Microsoft Excel в тестовой системе и проследить различные события, которые происходили в системе по мере того, как Routing Engine обрабатывал сообщение, начиная с момента его создания и до момента отправления (диспетчеризации).

Конечно, всегда есть возможность просмотреть данные журнала непосредственно на рабочей системе, но, как правило, такие журналы весьма велики (более 50 Мбайт), поэтому выбор отдельного сообщения и последующая трассировка его обработки — дело весьма трудоемкое. Большой размер журнала замедляет исследование истории сообщения, особенно если оно было отправлено большому числу адресатов списка рассылки или если предстоит проследить маршрут сообщения в нескольких системах.

Серверы, которые содержат активные Public Folders, могут генерировать очень большой трафик, что нетрудно установить, исследуя журналы трассировки. Идентифицировать сообщения репликации можно с помощью имени отправителя, которое присутствует в виде внутреннего адреса Exchange 2000 формата X.500 для агента репликации Public Folder Replication Agent (например, вот так: EX:/O=Acme/OU=Central/CN=Configuration/CN=Servers/ CN=Server1/CN=Microsoft Public MDB) или в виде адреса SMTP для того же агента (Server1-IS@acme.org). В журналах трассировки в поле Recipient-Address содержится имя сервера назначения (партнера по репликации). В журналах трассировки, помимо прочего, хранятся данные для входящих сообщений, в том числе уведомления о недоставленных отправлениях и квитанции о доставке и прочтении.

В Таблице Excel на Экране 6 показано содержимое данных журнала трассировки, соответствующее сведениям Message History Экрана 5. Сообщения сгенерированы MAPI-клиентом и предназначены для двух внешних адресатов SMTP. Следовательно, логика обработки Routing Engine должна быть очевидна: ядро программы маршрутизатора принимает сообщение, проверяет адреса SMTP и затем пересылает сообщение на SMTP-коннектор на том же сервере (если коннектор имеется) или на SMTP-коннектор сервера с наименьшей стоимостью маршрута. Проследить, какие события происходят в процессе работы Routing Engine, можно на примере приведенного ниже пояснения (аналогичные записи существуют для каждого получателя).

  • Event ID 1027: клиент передает сообщение на обработку процессору хранилища Store Driver.
  • Event ID 1019: Store Driver передает сообщение обработчику очереди Advanced Queuing.
  • Event ID 1025: Advanced Queuing обрабатывает сообщение.
  • Event ID 1024: Categorizer получает сообщение и приступает к его обработке.
  • Event ID 1020: Routing Engine помещает сообщение в целевую очередь (destination queue) и подготавливает его для дальнейшей пересылки с данного сервера.
  • Event ID 1031: Routing Engine завершает пересылку и обработку сообщения.
  • Сравним только что рассмотренную последовательность событий с той, которая наблюдается при отправке сообщения в почтовый ящик на том же самом сервере (та же последовательность характерна для направления сообщения в почтовый ящик в другую группу хранения - Storage Group, SG).
  • Event ID 1027: клиент передает сообщение на обработку Store Driver.
  • Event ID 1019: Store Driver передает сообщение на обработку Advanced Queuing.
  • Event ID 1025: Advanced Queuing обрабатывает сообщение.
  • Event ID 1024: Categorizer получает сообщение и приступает к его обработке.
  • Event ID 1023: Routing Engine помещает сообщение в локальную очередь доставки (delivery queue).
  • Event ID 1028: Store доставляет сообщение в почтовый ящик.

Сообщения, поступающие от клиентов Outlook Web Access (OWA), порождают аналогичную последовательность записей. Клиенты POP3 и IMAP4 используют SMTP для передачи сообщений непосредственно Routing Engine. Так как эти сообщения не проходят через Store Driver, последовательность событий начинается сразу с Event ID 1019.

Остальные записи включают Event ID 1023 (успешная доставка в локальный почтовый ящик) и Event ID 1029 (пересылка агенту MTA для последующей доставки). В отличие от журналов трассировки Exchange 5.5, в журналах версии Exchange 2000 отсутствуют записи для маркировки расширения группы рассылки. Вместо этого здесь имеется Event ID 1020, событие, которое прописано в журнале для каждого члена группы.

Более сложные случаи связаны с сообщениями, которые адресованы как отдельным получателям, так и группам рассылки. Такие сообщения разрешаются в локальные и удаленные адреса и представляют некоторую сложность для почтовых серверов, особенно если получатели входят в состав большого количества групп рассылки. Дело в том, что число сообщений, посылаемых в группу рассылки, определяется свойствами группы, а это еще более усложняет алгоритм обработки сообщений. Например, из свойств группы, как это показано на Экране 7, следует, что любые квитанции о доставке сообщений, адресованных группе, направляются отправителю. Другими словами, если группа содержит некорректный адрес (т. е. контакт, представленный почтовым адресом, более не существует, или, например, для почтового ящика превышены квоты), то отправитель получит уведомление о том, что сообщение доставить невозможно (nondelivery notification). Можно задать свойства группы таким образом, что уведомления о доставке станут подавляться, и почтовый трафик снизится, но тогда пользователи будут постоянно испытывать беспокойство — непонятно, а получают ли адресаты сообщения? Routing Engine выполняет аналогичную обработку сообщений, уведомляющих об отсутствии в офисе (out-of-office notification), и их также можно подавить или активизировать с помощью свойств группы рассылки. Очевидно, что, настраивая свойства групп рассылки по-разному, в результате получаем и различную обработку сообщений.

Экран 7. Расширенные свойства группы рассылки.

Поскольку система Exchange 2000 уведомления о доставке и об отсутствии получателя формирует для каждого сообщения в отдельности, в ситуации, когда сообщение отправляется в две группы, а свойства одной из них требуют уведомлять о доставке, а другой — подавлять уведомления, Routing Engine должен будет сгенерировать два набора сообщений. Таким образом, адресаты первой группы получат копию сообщения с указанием уведомлять о доставке, а получатели второй группы — копию сообщения с указанием подавлять подобное уведомление.

Пользователям ни к чему получать несколько копий одного и того же сообщения, а такая ситуация может возникнуть, если Routing Engine не обрабатывает все возможные случаи с квитанциями о доставке при построении списка получателей. Для оптимизации списка получателей программа Routing Engine должна раскрывать все группы рассылки, проверять установки квитанций о доставке и уведомления об отсутствии получателя, после чего генерировать необходимое число сообщений, удовлетворяющих требованиям каждой задействованной группы. В результате учета сложного алгоритма формирования списка получателей в журнале трассировки фиксируется большое число событий Event ID 1020 и Event ID 1028 по каждому адресу.

Для сравнения, Exchange 5.5 MTA использует механизм, называемый fan-out, чтобы раскрывать группы рассылки. MTA строит список адресов, затем находит оптимальный маршрут доставки копии сообщения по каждому адресу. Сервер Exchange 5.5 поддерживает разные наборы свойств для управления квитанциями о доставке и управления уведомлениями об отсутствии, поэтому список получателей строится проще.

Для обеих версий Exchange в случае, когда через Store проходят дублирующие сообщения, хранилище на сервере-получателе может воспользоваться идентификатором сообщения, установить факт дублирования и подавить лишнее отправление. Такой механизм — Backstop Mechanism — гарантирует, что Exchange не будет отправлять одно и то же сообщение одному и тому же адресату несколько раз.

Продолжение анализа

Загружая журнал трассировки, например, в Microsoft Access, выполнять анализ данных становится еще проще. Однако если данные трассировки нужны как основа для исследования объема почтового трафика, идентификации основных источников сообщений и анализа трафика на отдельных серверах, вероятно, придется написать небольшую программу для получения базовой статистики (например, число сообщений за указанный промежуток времени, диапазон адресов, размер сообщения). В такой ситуации предстоит обрабатывать очень большие массивы данных, поскольку одно-единственное сообщение, адресованное большой группе рассылки, генерирует сотни записей в журнале трассировки. Допустим, сообщение, направленное в две группы рассылки с общим числом членов 1350 (некоторые из них дублируются), в нашей компании породило более 4000 записей. Я бы сказал, что Perl — тот язык, на котором без особых усилий можно написать программу анализа журнала трассировки.

При желании для выполнения подобных задач можно приобрести коммерческую программу, такую, например, как PROMODAG Reports for Microsoft Exchange Server. MessageStats от Quest Software предоставляет возможность более глубокого анализа содержимого журналов трассировки и получения большого числа разнообразных показателей, например самая популярная группа рассылки, самый частый отправитель. Некоторые утилиты не всегда одинаково хорошо обрабатывают различные ситуации — скажем, иногда не удается обработать сообщение, адресованное вложенному списку рассылки (в котором также содержатся списки), — но в большинстве случаев имеющиеся в наличии продукты надежнее тех, которые администратор системы сможет быстро создать, что называется, «на коленке».

Администратор может не обращать никакого внимания на Message Tracking Center, если никто не просит его проследить путь сообщения от отправителя до получателя. Но уж если это случается, то надо признать, что обмен сообщениями — действительно важный способ взаимодействия пользователей, и нужно суметь разобраться с журналами трассировки, а при необходимости и проанализировать содержащиеся в них данные.

Тони Редмонд — редактор Windows 2000 Magazine, вице-президент в Compaq Global Servises. С ним можно связаться по адоесу: exchguru@win2000mag.com.