Как уже некоторые из вас знают Exchange Server 2010 позволяет отправлять и принимать SMS прямо из Microsoft Outlook или Outlook Web App (OWA). Но не все знают, как это настроить, или думают, что в России это не работает, т.к. не поддреживается сотовыми операторами. На самом деле это не так!
Столкнулись с проблемой: перестали доставляться сообщения голосовой почты, отправленные пользователям 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.
После перезапуска служб голосовые сообщения, ожидающие своей доставки пользователям, были им доставлены в ящик автоматически.
Компания ЛанКей приглашает вас посетить бесплатный семинар, проводимый совместно с компанями Microsoft и GFI Software, посвящённый новым серверным решениям и средствам информационной безопасности.
На семинаре будут рассмотрены решения на базе Windows Server 2008 R2, Exchange Server 2010, и платформа для объединённых коммуникаций на базе Office Communications Server 2007 R2. В рамках семинара будет рассказано о продуктах для обеспечения информационной безопасности компании GFI.
Программа семинара ориентирована как на руководителей ИТ-подразделений, так и на технических специалистов и системных администраторов. Также семинар будет интересен для владельцев, руководителей организаций и предприятий, топ-менеджеров, принимающих решения о стратегическом развитии компании. На данном семинаре вы узнаете о новых возможностях каждого из продуктов, узнаете, как с помощью того или иного решения можно сократить затраты на ИТ-инфраструктуру, обеспечить надёжность и отказоустойчивость информационной системы, повысить производительность труда пользователей, и тем самым обеспечить конкурентные преимущества для вашего бизнеса.
Количество мест ограничено!
Для участия в семинаре требуется регистрация: http://www.lankey.ru/?id=1072#reg
Информация о семинаре на сайте Microsoft: http://www.microsoft.com/rus/events/detail.mspx?eventid=1032445810
Информация о семинаре на сайте GFI: http://www.gfi.ru/getnews.php?newsid=50
Информация о семинаре на сайте LanKey: http://www.lankey.ru/?id=1072
Вчера был большой день для тех, кто занимается электронной почтой и объединенными коммуникациями – стала доступна для скачивания и установки RTM-версия Microsoft Exchange Server 2010. Вот она – http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=05741f65-2a7b-4070-879f-d74208d6171d
У одного из наших клиентов мы уже внедряем Exchange 2010, поэтому дистрибутив был тут же забран для обновления.
С Release Candidate до RTM версии апгрейд проводится просто запуском установки – обновление прходит без проблем. С Beta-версии до RTM апгрейд не предусмотрен – надо деинсталлировать Beta и устанавливать RTM.
Недавно к нам обратилась одна компания с просьбой восстановить 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:
param($email)
$list = (Get-ContentFilterConfig).BypassedSenders
$list.Add($email)
Set-ContentFilterConfig -BypassedSenders:$list
(Get-ContentFilterConfig).BypassedSenders
Теперь можно запускать этот скрипт, указав в качестве параметра нужный нам адрес: .\add-wlemail.ps1 some-email@some-domain.ru
Этот скрипт занесет указанный нами e-mail в белый список и выведет на экран результирующий белый список адресов.
А вот другой скрипт – для занесения в белый список целых доменов – add-wldomain.ps1:
param($domain)
$list = (Get-ContentFilterConfig).BypassedSenderDomains
$list.Add($domain)
Set-ContentFilterConfig -BypassedSenderDomains:$list
(Get-ContentFilterConfig).BypassedSenderDomains
PS: Конечно, для того, чтобы эти скрипты работали, нужно либо снабдить их цифровой подписью, либо разрешить выполнение неподписанных скриптов командой Set-ExecutionPolicy Unrestricted.