Exchange не приходит почта

Причина: Outlook работает в автономном режиме.

Решение: убедитесь в том, что Outlook подключен к Интернету.

В меню Outlook снимите флажок Автономный режим.

Причина: Outlook не подключен к серверу Microsoft Exchange Server.

Решение: проверьте подключение к серверу Microsoft Exchange Server.

На ленте Сервис выберите Учетные записи.

В области слева найдите учетную запись Exchange. Если есть проблема с подключением, значок индикатора будет оранжевым.

Если вы успешно подключались к учетной записи раньше, попробуйте подключиться к ней из другого приложения Exchange, например из Outlook в Интернете. Чтобы проверить состояние сервера Exchange, можно также обратиться к его администратору.

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

Решение: очистите кэш приложения Outlook, чтобы оно могло скачать все элементы из учетная запись Microsoft Exchange еще раз.

Внимание: Описанная ниже процедура позволяет удалить все данные, которые не синхронизированы с сервером Exchange Server, в том числе почтовый сертификат контактов. При очистке кэша содержимое папки заменяется новейшими элементами с сервера Exchange Server. Перед очисткой кэша советуем создать резервную копию данных Outlook.

Убедитесь в том, что компьютер подключен к серверу Exchange.

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

На вкладке Общие нажмите кнопку Очистить кэш.

Когда папка очистится, приложение Outlook автоматически скачает элементы с сервера Exchange.

Дополнительные сведения

Причина: Outlook работает в автономном режиме.

Решение: убедитесь в том, что Outlook подключен к Интернету.

В меню Outlook посмотрите, не установлен ли флажок Автономная работа.

Причина: Outlook не подключен к серверу Microsoft Exchange Server.

Решение: проверьте подключение к серверу Microsoft Exchange Server.

В меню Сервис выберите пункт Учетные записи.

В области слева найдите учетную запись Exchange. Если есть проблема с подключением, значок индикатора будет оранжевым.

Если вы успешно подключались к учетной записи раньше, попробуйте подключиться к ней из другого приложения Exchange, например из Outlook Web App. Чтобы проверить состояние сервера Exchange, можно также обратиться к его администратору.

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

Решение: очистите кэш приложения Outlook, чтобы оно могло скачать все элементы из учетная запись Microsoft Exchange еще раз.

Внимание: Описанная ниже процедура позволяет удалить все данные, которые не синхронизированы с сервером Exchange, в том числе почтовый сертификат контактов. Перед очисткой кэша может потребоваться выполнить резервное копирование данных Outlook, которые хранятся только на вашем компьютере. Подробнее см. в статье Экспорт и архивирование вручную элементов Outlook.

Убедитесь в том, что компьютер подключен к серверу Exchange.

В область навигации, удерживая нажатой клавишу CONTROL, щелкните папку Exchange, для которой нужно очистить кэш, и выберите пункт Свойства папки.

На вкладке Общие в разделе Очистить кэш нажмите Очистить.

Когда папка очистится, приложение Outlook автоматически скачает элементы с сервера Exchange.

Всё делал по инструкции vmkh.net/nastroyka-exchange-server-2013 но с учетом, что хостинга у меня нет, то dns записи прописал следующие

Сервер ex1.cloud.local находится "в облаке", название домена отличается (типа cloud.local) как и контроллер домена, ip контроллера домена внешний *.*.*.28 (dc1.cloud.local)
У обоих серверов 2 сетевых адаптера и роли DNS

myhosting.com. NS ns1.hc.ru.
myhosting.com. NS ns2.hc.ru.
mail.myhosting.com A *.*.*.30
autodiscover.myhosting.com A *.*.*.30
mx01.myhosting.com A *ip
myhosting.com MX 1 mail.myhosting.com
@ TXT v=spf1 mx ptr:mail.myhosting.com mx:mx01.myhosting.com ip4: *.*.*.30 -al

В логах отправки вроде никакой подозрительной активности, внутри отбойники не приходят, письма типа отправились, но их нет. Антиспама-фарйвола тоже пока нет.
Если извне отправить, то придет "отбойник" с DNS Error: DNS server returned answer with no data

Помогите пожалуйста, буду признателен за любые мануалы.

Проблемы с почтой 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 FilesMicrosoftExchangeServerTransportRolesdataQueue. Контроль этого местоположения осуществляется в конфигурационном файле 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, что означает недостаточность системных ресурсов.


[an error occurred while processing the directive]
Карта сайта