Столкнулся с интересной проблемой в Microsoft Exchange Server 2010 (характерна она и для версий Exchange Server 2007 / 2013). Некоторые пользователи стали жаловаться на периодическую невозможность получить сканы с МФУ и сендеров, настроенных на отправку почты через сервер Exchange с ролью CAS (Client Access Server). При этом почта между пользователями Exchange в рамках сервера доставлялась без каких либо проблем.
Для диагностики проблемы попробовал вручную отправить письмо из командой строки с помощью telnet. Так как конфигурация представляет собой два CAS сервера, объединённых в CAS Array с помощью NLB, пришлось выполнять проверку для каждого сервера. На первом сервере отправка прошла без проблем, а на втором после выполнения команды mail from появилась ошибка: 452 4.3.1 Insufficient system resources
В журнале приложений сервера при этом регистрируется событие EventID: 15006 от источника Source: MSExchangeTransport
Queue database logging path («C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\») = 96% [High] [Normal=92% Medium=94% High=96%]
Physical memory load = 90% [limit is 94% to start dehydrating messages.]
The following components are disabled due to back pressure:
Inbound mail submission from Hub Transport servers
Inbound mail submission from the Internet
Mail submission from Pickup directory
Mail submission from Replay directory
Mail submission from Mailbox server
Content aggregation
The following resources are in normal state:
Queue database path («C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que») = 95% [Normal] [Normal=95% Medium=97% High=99%]
Version buckets = 0 [Normal] [Normal=80 Medium=120 High=200]
Private bytes = 14% [Normal] [Normal=71% Medium=73% High=75%]
Batch Point = 0 [Normal] [Normal=2000 Medium=4000 High=8000]
Submission Queue = 0 [Normal] [Normal=1000 Medium=2000 High=4000]
Причина возникновения ошибки – окончание свободного места на диске, на котором находятся очереди службы Exchange Hub Transport. Дело в том, что в Exchange есть специальный компонент мониторинга доступных ресурсов Back Pressure, который в том числе отслеживает свободное место на диске, на котором хранятся очереди транспортной службы Exchange.
При превышенной пороговых значений Exchange может:
- порог Medium (90%) — перестать принимать по SMTP почту от внешних отправителей (почта от MAPI клиентов при этом обрабатывается)
- порог High (99%) — обработка потока почты полностью прекращается
Поэтому, в случае возникновения подобной ошибки можно:
- Очистить диск от мусора
- Отключить мониторинг Back Pressure (плохой вариант)
- Перенести транспортные очередь на другой диск достаточного объёма.
По умолчанию транспортная очередь хранится на системном диске. После анализа диска C:\ я обнаружил, что почти 15 Гб места занимала папка с логами IIS (C:\inetpub\logs\LogFiles\W3SVC1). Как правило, эти логи можно спокойно удалить и включить для них скрипт автоматического удаления старых логов IIS.
Если же освободить место не удается, можно переместить каталог транспортной очереди Exchange на другой диск.
Путь к каталогу с очередью задается в конфигурационном файле $env:exchangeinstallpath\bin\EdgeTransport.exe.config следующими переменными:
<add key="QueueDatabasePath" value="C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue" />
<add key="QueueDatabaseLoggingPath" value="C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue" />
Достаточно указать новый путь до каталога с очередью, и перезапустите службу Microsoft Exchange Transport (
Restart-Service MSExchangeTransport
)и Exchange автоматически их создаст.
Ошибка Exchange “452 4.3.1 Insufficient system resources” возникает, но ошибки 15006 и подобных, указывающих на Back Pressure, нет. Места на всех дисках достаточно, перенесла очереди — не помогло (ну этого можно было ожидать).
Какая версия Exchange и WIndows Server? Какие размеры дисков, сколько свободного места? Попробуйте еще место почистить.
Огромное спасибо за статью!
Очень помогло! Оставалось 4 Гб и Эксчанг как всегда по тихому, скромно ни кому не сообщая перестал принимать входящие из вне, внутри сети все так же бодренько работал…
Не могу понять, о чем думали разработчики, когда решали как же должен вести себя сервер корпоративной(!) почты если вдруг закончится место, но в такие критические моменты можно было и оповещение прислать что-ли!?
Как и описано, много места занимали логи IIS 32Гб(!)… их удаление спасло ситуацию…
Спасибо автору!
Спасибо, за разъяснения. Статья помогла в решении. Только вот евентов на exchange где была база пользователя не было. Возможно из за того, что у нас связка exchange+pstfix, ошибки были в логах самого postfix.