IT-блог компании "ЛанКей"

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

Source: MSExchange Unified Messaging
Event ID: 1185
Task Category: UMCore
The Unified Messaging server failed to submit a message to Hub Transport server 'EXCHANGE' due to the following error: Unexpected server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

Source: MSExchange Unified Messaging
Event ID: 1423
Task Category: UMCore
A pipeline stage encountered the following error. Details : 'Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. ---> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.CheckResponse(ServerResponseInfo response, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Command(SmtpChunk[] chunks, SmtpCommandType command, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.StartTls()
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpClient.Submit()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.SubmitMessage()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   --- End of inner exception stack trace ---

Server stack trace:
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.HandleTransientSmtpFailure(Exception e, InternalExchangeServer smtpServerToUse)
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.SynchronousWorkDelegate.EndInvoke(IAsyncResult result)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.EndSynchronousWork(IAsyncResult r)'

Роли Hub Transport и Unified Messaging находятся на одном и том же сервере, но тем не менее, голосовое сообщение, оставленное пользователем, в ящик получателя не попадает.

Из приведенных ошибок видно, что при попытке установления SMTP-соединения служба Hub Transport выдает ответ, что команда не распознана. По подробной информации видно, что ошибка возникает в процессе работы процедуры StartTls, то есть имеет место быть неудачная попытка установки шифрованного соединения.

Ошибка возникла из-за следующей тонкости:

Сам сервер внутри сети называется EXCHANGE.имя-домена. А опубликован в Интернет он под именем MAIL.имя-домена. Соответственно, в процессе настройки в Receive Connector захотелось внести изменения, чтобы при подключении сервер отвечал не своим внутренним именем, а внешним, отличающимся от внутреннего. Но – при несовпадении FQDN, предоставляемого в ответ на HELO или EHLO, и системного имени сервера, отказывается работать включенная по умолчанию аутентификация Exchange Server authentification. Соответственно, эта галочка и была выключена.

А если выключена Exchange Server authentication – то в ответ на команду EHLO сервер в списке допустимых команд НЕ ВЫВОДИТ команду X-ANONYMOUSTLS, и не отвечает на нее. А службы Unified Messaging пытаются установить соединение с Hub Transport именно этим способом.

Решение: в нашем случае помогло включение обратно пункта Exchange Server authentication, смена выдаваемого FQDN в окне Receive Connector обратно на внутреннее имя сервера, и перезапуск служб MSExchange Hub Transport и MSExchange Unified Messaging.

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

Недавно к нам обратилась одна компания с просьбой восстановить Exchange Server. В компании работает около 500 человек. Занимается компания бизнесом в Интернете. Можно себе представить насколько критичным для данной компании является сервис электронной почты, куда приходят все заказы от клиентов, и происходит общение между сотрудниками. Читать далее…

Некоторые наши заказчики ограничились использованием встроенного в Exchange 2007 антиспам функционала. Одним из антиспам фильтров является Content Filtering. Данный фильтр проверяет содержимое письма, на основании чего выставляет ему SCL (Spam Confidence Level) рейтинг (от 0 до 9). И на основании этого рейтинга настраиваются 3 дальнейших варианта действий: Reject (отклонить, отправив NDR), Delete (удалить письмо) и Quarantine (отправить в Карантин).

Чтобы случайно не потерять нужные письма, оптимальнее всего настроить помещение писем, определённых как спам, в Карантин. Для этого нужно создать какой-нибудь ящик, например spm@domain.ru, и указать его в параметрах Content Filtering.

Внимание!  - mail-enabled Public Folder указывать нельзя! Т.е. ящик spm@domain.ru должен быть mail-enabled user-ом.
Читать далее…

Известно, что добавить адрес в черный список content-filtering’а Exchange можно через графическую консоль – пункты Sender Filtering и Recipient Filtering. А вот добавить запись в белый список через графическую консоль нельзя – можно только через PowerShell. За это отвечает команда Set-ContentFilterConfig.

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

Решение для удобства можно оформить в виде скрипта, назвав его, например, add-wlemail.ps1:

Теперь можно запускать этот скрипт, указав в качестве параметра нужный нам адрес: .\add-wlemail.ps1 some-email@some-domain.ru

Этот скрипт занесет указанный нами e-mail в белый список и выведет на экран результирующий белый список адресов.

А вот другой скрипт – для занесения в белый список целых доменов – add-wldomain.ps1:

PS: Конечно, для того, чтобы эти скрипты работали, нужно либо снабдить их цифровой подписью, либо разрешить выполнение неподписанных скриптов командой Set-ExecutionPolicy Unrestricted.