В Exchange 2010 можно использовать следующие средства для отслеживания сообщений с максимальной детализацией:

Командлет Get-MessageTrackingLog. Ниже пример команды, которой можно посмотреть логи message tracking на всех серверах с ролями hub и mailbox в организации (ключевым моментом является получение всех серверов в организации и фильтрация их по ролям). 

Пример: 

Get-ExchangeServer | where {$_.isHubTransportServer -eq $true -or $_.isMailboxServer -eq $true} | Get-MessageTrackingLog -sender "iivanov@net.org" | Select-Object Timestamp,ServerHostname,ClientHostname,Source,EventId,Recipients | Sort-Object -Property Timestamp

Подробная информация по данному командлету есть здесь  https://technet.microsoft.com/en-us/library/bb124926(EXCHG.80).aspx

Так же можно использовать командлет
Search-MessageTrackingReport и Get-MessageTrackingReport (аналог delivery reports в Exchange control Panel).

Пример:
Search-MessageTrackingReport -Identity "iivanov" -Sender "apetrov@mynet.org" -ByPassDelegateChecking -DoNotResolve | ForEach-Object { Get-MessageTrackingReport -Identity $_.MessageTrackingReportID -DetailLevel Verbose -BypassDelegateChecking -DoNotResolve -RecipientPathFilter "apetrov@mynet.org" -ReportTemplate RecipientPath }

При этом, командлет Search-MessageTrackingReport возвращает несколько результатов, которые попадают под критерии поиска. Поэтому, если необходимо получить все результаты и обработать их командлетом Get-MessageTrackingReport, нужно передать их данному командлету как указано выше.

Поиск по части адреса. К сожалению, Search-MessageTrackingReport и Get-MessageTrackingReport не поддерживают wildcard, т.е. поиск по шаблону. Адрес, указанный в качестве параметра, должен быть корректным. Однако, можно использовать синтаксис как указано ниже. 

Get-ExchangeServer | where {$_.isHubTransportServer  -eq $true -or $_.isMailboxServer -eq $true} | Get-MessageTrackingLog -ResultSize Unlimited -Start "5/1/2011" -End "5/12/2011" | where{$_.recipients -like "*@net.org"} | select-object Timestamp,SourceContext,Source,EventId,MessageSubject,Sender,{$_.Recipients} | export-csv C:\ExchangeLogResults.txt

Данная рекомендация приводит к отключению так называемых "minor link state updates", отсутствие поддержки которых в более новых версиях может привезти к образованию "циклов маршрутизации". Это связано с тем, что в некоторых случах возможно возникновение циклов маршрутизации, например, в случае, если какой-то из коннекторов Exchange 2003 помечен как Down (недоступный) и Exchange 2003 выберет путь не с наименьшей стоимостью. В связи с чем, данная проблема может появиться не сразу, а через некоторое время.  

Однако в каком именно случае и почему может возникнуть зацикливание при маршрутизации сообщения?  Рассмотрим схему ниже в качестве примера. Предполагается, что коннекторы созданы к bridgehead серверам Exchange 2010 в разных сайтах (т.е. между сайтами есть некий site link cost, но в данном случае это не существенно). 
  
  

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

Т.е. в роунтинговую группу Exchange 2010 трафик может пойти одним из двух путей - CB-BA либо CD-DE, а далее сообщение уже будет доставлено локально в сайте, либо смаршрутизировано в другой сайт HUB серверами. 

При этом если на коннекторе DE  указано несколько bridgehead серверов Exchange 2010, то bridgehead сервер выбирается произвольно и таким образом достигается балансировка запросов, которые поступают на данный коннектор. При этом, если сообщение уже было смаршрутизировано на какой-то сервер и этот сервер становится недоступен – альтернативный маршрут выбран не будет. Т.е. сообщение будет находиться в очереди до тех пор, пока сервер не станет снова доступным. Link state содержит только информацию о состоянии коннектора, а коннектор всегда считается доступным, если хотя бы  один bridgehead сервер доступен.  Если же какой-то bridgehead сервер становится недоступным, то маршрутизация производится между оставшимися доступными серверами.

В данной конфигурации сложно представить ситуацию, которая может привести к возникновению циклов в маршрутизации. Например, это может произойти в случае, если оба коннектора BD  и BC не доступны (помечены как down). Тогда при отправке сообщений из A в C  будет выбран путь AB-BC как с наименьшей стоимостью и локальный для сайта. У B же единственный маршрут – обратно в A.  В случае недоступности одного коннектора может получиться неоптимальный путь для прохождения почтового трафика.

Но в случае, если бы стоимость коннектора BD была, к примеру, 20, то для возникновения аналогичной ситуации было бы достаточно только недоступности коннектора BC.

Поскольку в реальной жизни схема маршрутизации намного сложнее, анализ ее на предмет возникновения циклов маршрутизации является более затруднительным. Поэтому стоит последовать рекомендации, и все же отключить "minor link state updates", даже с учетом того, что ремаршрутизация сообщений больше не будет производиться серверами Exchange 2003.

Дополнительная информация по данному вопросу тут:

https://technet.microsoft.com/en-us/library/aa997292.aspx

https://technet.microsoft.com/en-us/library/aa996728.aspx

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

В Exchange 2003 подобная технология есть – это делается с помощью Auto Accept Agent либо outlook direct booking.
У каждого из способов есть свои плюсы и минусы. Auto Accept Agent требует установки и дополнительной конфигурации, этот функционал работает на стороне сервера и автоматически обрабатывает запросы на бронирование и отмену, а так же отправляет уведомление организатору встречи.  

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

Сравнение этих двух методов более подробно описано здесь:

https://blogs.technet.com/b/exchange/archive/2006/02/22/420275.aspx

Feature Comparison c Exchange 2007:

https://blogs.technet.com/b/exchange/archive/2007/05/14/3402515.aspx

Содержит сравнительную таблицу работы функционала в Exchange 2003 и Exchange 2007.

Auto Accept Agent deployment and Administration Guide

https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13011

How to direct book a resource in Outlook

https://support.microsoft.com/kb/291616

Так же для direct booking с помощью Outlook 2010 требуется дополнительная настройка.

https://support.microsoft.com/kb/982774

You should not register a resource mailbox for Auto Accept Agent in Exchange 2003 when you set up a resource for direct booking in Outlook

https://support.microsoft.com/default.aspx?scid=kb;EN-US;903290