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

Самые упорные, дочитавшие до сюда, и просмотревшие ссылки, могут заметить, что некоторые сессии накладываются друг на друга. Так что придётся разрываться 🙂

Еще один хорошо описанный компонент Exchange 2010 – Shadow Redundancy, который позволяет гарантировать доставку почты внутри организации. Строится он на базе механизма Delayed Acknowledgement. В двух словах он работает следующим образом. В Exchange 2010 smtp-сессия держится открытой до тех пор, пока отправляющий сервер не получит подтверждение от всех промежуточных серверов об успешной доставке теневого сообщения (Shadow message). Если промежуточных серверов несколько, то первый открывает smtp-сессию и держит её. Если следующий сервер (на который открыта smtp-сессия) успешно открывает smtp-сессию на следующий сервер по маршруту доставки, то он это письмо помещает к себе в Shadow Queue, а на первый сервер отправляет ответ 250 и закрывает сессию. Если по каким то причинам smtp-сессия на следующий сервер открыта быть не может, то первоначальная smtp-сессия остаётся открытой, пока не истечёт время, указанное в MaxAcknowledgementDelay. Красивая картинка, которая примерно объясняет то, что я написал:

ShadRed

В smtp-логе принимающего коннектора в это время происходит примерно следующее:

1,helo
2,250 mail.domain.com Hello [xx.xx.xx.xx]
3,mail from: some.user@domain.com
4,250 2.1.0 Sender OK
5,rcpt to: bill.gates@microsoft.com
6,250 2.1.5 Recipient OK
7,data
8,354 Start mail input; end with <CRLF>.<CRLF>
...
9,Tarpit for '0.00:00:33.967' due to 'DelayedAck',Expired;Timeout
10,250 2.6.0 12345678@internalserver.domain.com [InternalId=987654] Queued mail for delivery
11,quit
12,221 2.0.0 Service closing transmission channel

Между шагами 8 и 9 идёт задержка в 30 секунд. И фигурирует интересная фраза “Expired;Timeout”. В данном случае, некий сервер (internalserver.domain.com), а точнее некоторое приложение на нём пытается отослать сообщение через Exchange внешнему адресату. Так как Exchange про Delayed Acknowledgement в курсе, то он пытается это письмо “отследить” до получателя и в итоге отваливается по таймауту через 30 секунд, о чём нам и сообщает (см. шаг 9) . Письмо при этом помещается в очередь на отправку (шаг 10), гарантировать его доставку в случае проблем на маршруте прохождения письма дальше наших серверов мы не можем. Затем сессия закрывается (шаг 12).

А вот что происходит, когда получатель у нас внутренний:

1,helo
2,250 mail.domain.com Hello [xx.xx.xx.xx]
3,mail from: some.user@domain.com
4,250 2.1.0 Sender OK
5,rcpt to: big.boss@domain.com
6,250 2.1.5 Recipient OK
7,data
8,354 Start mail input; end with <CRLF>.<CRLF>
...
9,Tarpit for '0.00:00:01.567' due to 'DelayedAck',Delivered
10,250 2.6.0 12345678@internalserver.domain.com [InternalId=987654] Queued mail for delivery
11,quit
12,221 2.0.0 Service closing transmission channel

Здесь идёт доставка тем же самым приложением письма уже внутреннему адресату (шаг 5). Задержка при отправке составляет чуть больше секунды (шаг 9), после чего письмо уходит в очередь на доставку. При этом в шаге 9 видно (Delivered), что Exchange смог проследить письмо до самого себя (сюрприз!)

Теперь переходим к самому главному. Если наше воображаемое приложение таки существует и делает при этом рассылки (через соответствующий анонимный коннектор), то по умолчанию, письма оно сможет отправлять с большой задержкой. Если писем много – то они будут копиться в очереди на стороне приложения. И это будет происходить до тех пор, пока мы не поменяем значение MaxAcknowledgementDelay. Для стандартных коннекторов оно будет:

Get-ReceiveConnector -Server mailserver | ft Name,MaxAcknowledgementDelay
Name                                    MaxAcknowledgementDelay
----                                    -----------------------
Default MAILSERVER                      00:00:30
Client MAILSERVER                       00:00:30

Меняем, и наслаждаемся результатом:

Set-ReceiveConnector "Some Receive Connector" -MaxAcknowledgementDelay 00:00:00

Я специально не стал указывать здесь какой-нибудь дефолтный коннектор, ибо лучше использовать для таких целей специальный коннектор. Кстати, аналогичная ситуация наблюдается при миграции с Exchange 2003 или Lotus Notes на Exchange 2010.

Полезные ссылки:
Understanding Shadow Redundancy
Configure Shadow Redundancy
Shadow Redundancy Mail Flow Scenarios

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

EMC-Error

Чтобы EMC переподключился к другому серверу необходимо сделать следующее:

  • Закрыть консоль EMC
  • Удалить файл C:users(username)AppDataRoamingMicrosoftMMCExchange Management Console
  • Удалить ключ в реестре HKCUSoftwareMicrosoftExchangeserverv14AdminToolsNodeStructureSettings

Update: похожая проблема наблюдается при удалении контроллера домена, с которым работает EMC. Решение то же самое – удалить кэш MMC.