Storedriver exchange что это

Автор: Super User. Категория: ИТ.

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

Принципиальную схему пути сообщения (Exchange 2013 Mail Flow / Transport Pipeline) описывает данный рисунок:

Отслеживание писем в Exchange 2013

Мой подход к отслеживанию сообщений в Exchange вот такой:

Почему нельзя использовать только Get-MessageTrackingLog (ведь он умеет достаточно быстро искать по логам сразу на нескольких серверах)? У Get-MessageTrackingLog есть только одна неприятная особенность: в результатах он отдает записи из логов с некоторой временной меткой (TimeStamp), так вот коммандлет отдает эту метку с точностью до секунды, хотя в текстовых логах хранится время с точностью до тысячной секунды. Так вот многие операции происходят в течение одной единственной секунды, и из-за этого невозможно выстроить хронологию событий.

Именно поэтому мы будем обрабатывать логи через Log Parser 2.2. Это унивесальный парсер логов от Microsoft, который работает с языком SQL в качестве запросов.

Ищем письма с помощью Get-MessageTrackingLog

В составе Exchange 2013 есть замечательный коммандлет Get-MessageTrackingLog. Он позволяет найти нужное сообщение с использованием параметров в качестве фильтра. Самое подробное описание фильтрующих параметров смотрите вот тут: https://technet.microsoft.com/en-us/library/aa997573(v=exchg.150).aspx.

Вот пример, как использовать Get-MessageTrackingLog для поиска MessageId:

Скопируем MessageId и двигаемся дальше.

Пользуемся Log Parser 2.2 и Log Parser Studio

Во-первых нам нужно установить Log Parser 2.2 и Log Parser Studio (GUI для Log Parser 2.2). Вот ссылки:

Обратите внимание: указываем логи сразу с двух серверов (если их два)!

Выполняем запрос и получаем результат:

Анализ лога

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

Для вашего и своего удобства привожу самые полезные сведения тут.

Возможные значения поля event-id

AGENTINFO

Это событие используется агентами транспорта для журналирования пользовательских данных.

BADMAIL

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

CLIENTSUBMISSION

Сообщение было отправлено из папки «Исходящие» почтового ящика.

DEFER

Доставка сообщения отложена.

DELIVER

Сообщение было доставлено в локальный почтовый ящик.

Создано уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).

DROP

Сообщение было отклонено без уведомления о доставке (также называемого сообщением возврата или отчетом о недоставке). Например:

сообщения о выполненных запросах для утверждения;

нежелательные сообщения, удаленные автоматически без отчета о недоставке.

DUPLICATEDELIVER

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

DUPLICATEEXPAND

При расширении группы рассылки обнаружен повторяющийся получатель.

DUPLICATEREDIRECT

Альтернативный получатель сообщения уже являлся получателем.

EXPAND

Была расширена группа рассылки.

FAIL

Не удается доставить сообщение. Источники: SMTP, DNS, QUEUE и ROUTING.

HADISCARD

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

HARECEIVE

Теневое сообщение было получено сервером в локальной группе обеспечения доступности баз данных или на сайте Active Directory.

HAREDIRECT

Создано теневое сообщение.

HAREDIRECTFAIL

Не удалось создать теневое сообщение. Сведения сохранены в поле source-context.

INITMESSAGECREATED

Сообщение отправлено контролируемому получателю, поэтому оно отправлено в почтовый ящик вынесения решения для утверждения. Подробнее см. в разделе Управление утверждением сообщений.

LOAD

Сообщение успешно загружено при загрузке.

MODERATIONEXPIRE

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

MODERATORAPPROVE

Модератор контролируемого получателя утвердил сообщение, поэтому оно было доставлено контролируемому получателю.

MODERATORREJECT

Модератор контролируемого получателя отклонил сообщение, поэтому оно не было доставлено контролируемому получателю.

MODERATORSALLNDR

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

NOTIFYMAPI

Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере.

NOTIFYSHADOW

Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере, и необходимо создать теневую копию сообщения.

POISONMESSAGE

Сообщение помещено в очередь сообщений о сбое или удалено из нее.

PROCESS

Сообщение успешно обработано.

RECEIVE

Сообщение было получено компонентом получения протокола SMTP службы транспорта или из каталога раскладки или каталога преобразования (источник: SMTP ), или сообщение было отправлено из почтового ящика в службу отправки почтовых ящиков (источник: STOREDRIVER ).

REDIRECT

Сообщение было перенаправлено другому получателю в результате поиска в Active Directory.

RESOLVE

В результате поиска в Active Directory для получателей сообщения был найден другой адрес электронной почты.

RESUBMIT

Сообщение было автоматически повторно отправлено из сети безопасности. Подробнее см. в разделе Система безопасности.

RESUBMITDEFER

Сообщение, повторно отправленное из сети безопасности, было отложено.

RESUBMITFAIL

Сообщение, повторно отправленное из сети безопасности, не удалось отправить.

SEND

Сообщение было отправлено протоколом SMTP между службами транспорта.

SUBMIT

Служба отправки почтовых ящиков успешно передала сообщение службе транспорта. Для событий SUBMIT свойство source-context содержит следующие данные:

MDB GUID базы данных почтовых ящиков.

Mailbox GUID почтового ящика.

Event Порядковый номер события.

CreationTime Дата и время отправки сообщения.

SUBMITDEFER

Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта была отложена.

SUBMITFAIL

Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта не была выполнена.

SUPPRESSED

Передача сообщения была отменена.

THROTTLE

Сообщение было отрегулировано.

TRANSFER

В результате преобразования содержимого, ограничения числа получателей или работы агентов получатели были перемещены в сообщение с ветвлением. Источники: ROUTING или QUEUE.

Возможные значения поля source

ADMIN

Источник события был введен пользователем. Например, администратор использовал средство просмотра, чтобы удалить сообщение, или отправил файлы сообщений с помощью каталога воспроизведения.

AGENT

Источником события был агент транспорта.

APPROVAL

Источником события была платформа утверждения, используемая для контролируемых получателей. Подробнее см. в разделе Управление утверждением сообщений.

BOOTLOADER

Источником события были необработанные сообщения, которые присутствовали на сервере на момент загрузки. Это относится к типу событий LOAD.

Источником события было DNS.

Источником события было уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).

GATEWAY

Источником события был внешний соединитель. Подробнее см. в разделе Внешние соединители.

MAILBOXRULE

Источником события было правило для папки «Входящие». Дополнительные сведения см. в статье Правила для папки «Входящие» в Outlook Web App.

MEETINGMESSAGEPROCESSOR

Источником события был обработчик сообщения о собрании, который обновляет календари в соответствии с обновлениями собрания.

ORAR

Источником события был альтернативный получатель, запрошенный отправителем (ORAR). Вы можете включить или отключить поддержку ORAR на получающих соединителях, используя параметр OrarEnabled в командлете New-ReceiveConnector или Set-ReceiveConnector.

PICKUP

Источником события был каталог раскладки. Подробнее см. в разделе Каталог раскладки и каталог преобразования.

POISONMESSAGE

Источником события был идентификатор сообщения о сбое. Дополнительные сведения о сообщениях о сбое и очереди сообщений о сбое см. в разделе Queues and messages in queues

PUBLICFOLDER

Источником события была общедоступная папка, поддерживающая почту.

QUEUE

Источником события была очередь.

REDUNDANCY

Источником события было избыточное теневое копирование. Подробнее см. в разделе Теневая избыточность.

ROUTING

Источником события был компонент разрешения маршрутизации классификатора в службе транспорта.

SAFETYNET

Источником события была сеть безопасности. Подробнее см. в разделе Система безопасности.

SMTP

Сообщение было отправлено компонентом отправки или получения SMTP службы транспорта.

STOREDRIVER

Источником события была MAPI-отправка из почтового ящика на локальном сервере.

Источник

Отслеживание сообщений

Журнал отслеживания сообщений — это подробный отчет о всех действиях по потоку почты через транспортный конвейер на серверах почтовых ящиков и на транспортных серверах edge. Отслеживание сообщений можно использовать для судебной экспертизы сообщений, анализа потока сообщений, отчетности и устранения неполадок.

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

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

Журналы отслеживания сообщений содержат огромное количество данных по мере перемещения сообщений через сервер почтовых ящиков или на границе транспортного сервера. Когда речь заходит о поиске журналов отслеживания сообщений, у вас есть варианты:

Get-MessageTrackingLog. Администраторы могут использовать этот Exchange команды управленческой оболочки для поиска журнала отслеживания сообщений для получения сведений о сообщениях с использованием широкого спектра критериев фильтрации. Дополнительные сведения см. в журнале отслеживания сообщений поиска.

Отчеты о доставке для администраторов. Администраторы могут использовать вкладку Отчеты о доставке в центре администрирования Exchange или в окне поисковых сообщений Search-MessageTrackingReport и Get-MessageTrackingReport в оболочке управления Exchange для поиска журналов отслеживания сообщений для получения сведений о сообщениях, отправленных или полученных определенным почтовым ящиком в организации. Дополнительные сведения см. в сообщении о доставке для администраторов.

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

Другие места в именах файлов журнала представляют следующую информацию:

yyyymmdd — это дата создания файла журнала (в формате UTC). yyyy = год, мм = месяц и dd = день.

nnnn — это номер экземпляра, который начинается со значения 1 каждый день для каждого журнала.

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

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

Примечания:

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

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

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

#Fields: имена полей, которые используются в файлах журнала отслеживания сообщений.

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

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

Типы событий в журнале отслеживания сообщений

Различные типы событий в поле event-id используются для классификации событий, связанных с сообщениями, в журнале отслеживания сообщений. Некоторые события, связанные с сообщениями, отображаются только в одном типе файлов журнала отслеживания сообщений, а некоторые — во всех типах файлов. Типы событий, используемые для классификации каждого события, приведены в следующей таблице.

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

Значения в поле source в журнале отслеживания сообщений указывает на компонент транспорта, ответственный за событие отслеживания сообщений. В следующей таблице описаны значения поля source.

Примеры записей в журнале отслеживания сообщений

Не вызвавшее событий сообщение, отправленное между двумя пользователями, создает несколько записей в журнале отслеживания сообщений. Результаты можно просмотреть с помощью командлета Get-MessageTrackingLog. Подробнее см. в разделе Поиск в журналах отслеживания сообщений.

Это пример записей журнала отслеживания сообщений, созданных при успешной chris@contoso.com отправки тестового сообщения пользователю michelle@contoso.com. У обоих пользователей есть почтовые ящики на одном и том же сервере.

Журнал отслеживания сообщений и вопросы безопасности

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

Источник

Storedriver exchange что это

Question

what is the use of store driver? will it takes the mail from users out box?. If an out look user sends a mail to another user of the same organisation, but in another site.. how the mail will be routed to another site?

Answers

Firtst, the Store Driver provides persistent storage for a MailMsg object’s content when submitting the message by using MAPI or Exchange MTA.

Second, for the internal message transfer, the Store Driver is responsible for transmitting the message from the sender to the receiver when the two users on the same store. The message body in fact never leaves the Store at all.

For the Outbound message, the Store driver transfers the message to IIS for processing.

In your example, the message is placed in the Outbox of the user’s mailbox and marked for delivery. Since the sender and the receiver are in the different site, the message will be placed in the Remote delivery queue (SMTP) and calls the Store Driver to transfer the message to IIS, then Out via SMTP (Send Connector).

what is the use of store driver?

Yes the store driver takes mail from the users outboxes. It talks RPC MAPI not SMTP. and resides on every hub transport server. It is controlled by the Microsoft Exchange Transport Service.

If an out look user sends a mail to another user of the same organisation, but in another site.. how the mail will be routed to another site?

Exchange 2007 uses AD Sites and Services site links to get a network topology of the environment. By default Exchange 2007 will use the route with the lowest amount of site hops with the lowest site link cost.

In this diagram there are 4 ways to get from Site1 to Site3.

What if an exchange administrators wanted to to setup email replication different to active directory sites and services replication?

If you are not happy with the site link costs in AD, instead of updating sites and services you can use the powershell command Set-ADSiteLink to set new costs to that site link for exchange. This does not modify the value in sites and services. It only effects exchange. Whenever an exchange site link cost is specified, it will use this instead of the site link cost specified in AD Sites and Services. Very handy if you want mail to flow in a different direction to your AD replication.

Tricky Scenario

Hope this answers all your questions.

Kind Regards,
Clint Boessen MCSE, MCITP: Messaging

L7 Solutions, Microsoft Gold Partner
Perth, Western Australia

Источник