Ваш надежный
хостинг партнер
(495) 797-8-500

8-800-700 40 36

У Вас нет выбранных услуг.



Новости компании, технические статьи

Решение проблем с отправкой писем через Exchange 2010 29.10.2017

Решение проблем с отправкой писем через Exchange 2010

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

Проблемы с задержкой писем и таймаутами в Exchange


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

Tarpit for '0.00:00:30.591' due to 'DelayedAck',Expired;Timeout

Суть проблемы заключается в том, что в Exchange присутствует параметр –MaxAcknowledgementDelay. Изначально, по дефолту значение этого параметра выставлено на отметке 30. Таким образом, Exchange осуществляет попытку проверить успешную доставку письма получателю за тот период времени, который соответствует данному параметру с возвращением уведомления клиенту.

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

Set-ReceiveConnector "Connector Name" -MaxAcknowledgementDelay 0.

Проблемы с потоком/транспортом почты Exchange 2010


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

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

Решение проблемы со сбоями доставки сообщений


На этапе предварительной подготовки делегируется роль администратора организации Exchange. Для этого входим в систему под учеткой, которая входит в локальную группу админов.

Для определения конкретного места сбоя в доставке сообщения, а также места создания отчета о том, что доставка не прошла, необходимо:
  • задействовать средство просмотра очередей на транспортном пограничном сервере либо на сервере-концентраторе – это поможет определить точку, в которой произошел сбой доставки сообщения. К примеру, отсылаемое письмо может быть распределено в очередь доставки в состоянии Retry. Также это может быть очередь для сообщений с недостигаемым назначением;
  • изучить отчет о недоставке. Здесь нужно выяснить коды уведомлений о доставке, а также вычислить компонент либо сервер, которые создают такой отчет.
Далее в командной консоли Exchange используем командлет Test-ServiceHealth, который поможет убедиться в том, что на транспортных серверах, в рамках которых доставка не была осуществлена корректно, работают все нужные службы.
  
Также нужно убедиться, что на диске, где хранится база данных очередей для сообщений, хватает свободного дискового пространства. По дефолту БД для очереди сообщений расположена в директории Exchange(диск_ установки)>\Program Files\Microsoft\ExchangeServer\TransportRoles\data\Queue. Контроль этого местоположения осуществляется в конфигурационном файле EdgeTransport.exe.config через параметр QueueDatabasePath.

В Exchange 2010 изначально под БД для сохранения очередей сообщений предусмотрено от 4 Гб дискового пространства. При условии, что объем свободного пространства меньше заданного значения, система прекращает доставку почты.

Открываем окно просмотра событий в Windows и смотрим события приложений, которые записывались в журнал в рамках транспортного сервера-концентратора, а также сервера почтовых ящиков и пограничного сервера – все они участвуют в доставке сообщения. Уровень для ведения журнала процессов отправки сообщений в Exchange может быть повышен.

Посредством ADSI-редактора проверяем, правильно ли записаны значения для объекта получателя с атрибутами Active Directory, представленными в этом списке:
  • msExchMailboxGuid;
  • msExchMailboxSecurityDescriptor;
  • msExchHomeServerName;
  • proxyAddresses;
  • proxyAddresses;
  • proxyAddresses;
  • proxyAddresses;
  • Legacyexchangedn.
Важно, чтобы значение атрибута объектов получателей проверялось на том же сервере глобальных каталогов, на котором был задействован транспортный сервер, где и произошел сбой в доставке письма. Этот сервер можно посмотреть через консоль управления в свойствах транспортного сервера Exchange.

Далее сравниваем значения AD-атрибутов объекта получателя, которые удалось определить на предшествующем шаге со значением на сервера глобальных каталогов, который содержит почтовый ящик получателя. В случае несовпадения хотя бы одного из представленных значений выполняем следующие действия:
  1. Проверяем, функционирует ли корректно репликация между серверами глобальных каталогов.
  2. Если в вашем случае присутствуют серверы, на которых были установлены ранние версии Exchange Server, нужно проверить работоспособность соединителей для серверных плацдармов и групп маршрутизации.

Проблемы с очередями


Важно понимать, что тип очередей, в который помещаются сообщения, непосредственным образом зависит от его маршрутизации. В Exchange 2010 применяют такие типы очередей как:
  • отправочная очередь;
  • доставочная очередь для почтовых ящиков;
  • очередь сообщений о сбоях;
  • очередь удаленной доставки;
  • «недоступные».
В процессе устранения неполадок в рамках отправки писем через Exchange 2010, связанных с очередями, в большинстве случаев целесообразно начинать с очередй категории «недоступные». Раздел «сообщения с недостижимым назначением» представляет собой непрерывную очередь, которая содержит сообщения, которые система не может отправить по назначению. Данная очередь содержит сообщения с адресами, которые являются недоступными, вне зависимости от назначения. В очереди сообщений с недостижимым пунктом назначения письма будут находиться до тех пор, пока не произойдет их повторная отправка админом классификатору. 

Неполадки в событиях MSExchangeTransport


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

Когда пороговые значения требований к ресурсам превышены, их регистрируют события 15-001…-005. Для каждого ресурса обычная загруженность – штатный режим работы, средняя – говорит о том, что загрузка потенциально высока. В случае с высокой загруженностью на сервере не хватает ресурсов, что и служит причиной к прекращению передачи новых сообщений. В этом случае сообщения, которые

Были отправлены посредством MS Outlook Office либо WebAccess могут остаться в папке исходящих сообщений, если прочие серверы-концентраторы отсутствуют. С другой стороны, когда произведена попытка подключиться к SMTP-соединителю приема, выводится строка с состоянием 452 4.3.1, что означает недостаточность системных ресурсов.

Возврат к списку