Зависшие объекты в очередях не редкость в Exchange server, но причины могут быть различны, поэтому всегда на время поиска причины включайте логирование и разбирайтесь детально в причинах в Вашей инфраструктуре.

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

Одна из причин - недостаток ресурсов, Exchange требует наличия дискового пространства для своей полноценной работы. Помните, что компоненты Exchange Server активно используют файловые потоки NTFS, поэтому не всегда Вы увидите актульно занятое место через проводник.

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

C:\Program Files\Microsoft\ExchangeServer\V14\TransportRoles\data\Queue.

Если Вы видите подобное - есть повод задуматься и запланировать shrink DB после устранения проблем (базы данных в Exchange не ужимаются сами если не выключены планы обслуживания)

Список изменений, внесенных в базу данных очереди сообщений, хранится пока эти изменения не будут зафиксированы в журнале транзакций и не перенесены в нормальную базу данных почтовых ящиков. Затем список фиксируется в самой базе данных очереди сообщений. 

Количество незавершенных транзакций во временной базе может увеличиться до неприемлемо высокого уровня из-за

1. неожиданно большого объема входящих сообщений,
2. спам-атак,
3. проблем с целостностью базы данных очереди сообщений
4. производительностью жесткого диска 
5. или свободного места на жестком диске.

За очередь отвечают роли транспорта Exchange и соответствующие им процессы.

Утилизация ОЗУ и жесткого диска ролью транспорта EdgeTransport (через виртуальную память - PAGE file) может быть до неприличия высокой.

При этом, отправителям Exchange может любезно писать отписки:

Диагностические сведения для администраторов:

Server returned '400 4.4.7 Message delayed'

Если Мы разобрались и не видим явных причин в логах (см. выше возможные причины), или мы уже устранились от них - неплохо провести maintenance для служб Exchange.

Проверим очередь

[PS] C:\Windows\system32>Get-Queue

Identity       DeliveryType                      Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain
--------       ------------                      ------ ------------ -------- --------- -------------- -------------
ees1\3          SmtpRelayToConnectorSourceServers Retry  26           0        Normal    0              mainQUEUE
ees1\4          SmartHostConnectorDelivery        Active 16           0        Normal    0              [ip-adress]
ees1\5          SmtpRelayWithinAdSiteToEdge       Ready  0            0        Normal    0              edgesync - de...
ees1\6          SmtpDeliveryToMailbox             Ready  0            0        Normal    0              ees1 mdb ord2
ees1\Submission Undefined                         Ready  0            0        Normal    0              Отправка

По очереди видим небольшое количество зависших объектов.

Заходим в Exchange Management Tool в нашу mainQUEUE (по разному может называться)

И видим ошибки:

452 4.3.1 Insufficient system resources

При этом на самой очереди:

LED = 451 4.4.395 Target host responded with error. -> 421.7.0  Too many protocol errors (6) on this connection closing transmission channel

Ковыряемся в логах (если их нет, включаем на службах транспорта и коннекторах).

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

Первый шаг : попробуем пропушить сообщения остановкой очереди

Suspend-Service MSExchangeTransport

После успешного выполнения команды возобновляем службу

Resume-Service MSExchangeTransport

Смотрим очередь спустя несколько минут после восстановления службы

Get-Queue

Если сообщения ещё есть идём дальше. перезапускаем службы Транспорта

[PS] C:\Windows\system32>restart-Service MSExchangeTransport
ПРЕДУПРЕЖДЕНИЕ: Ожидание остановки службы "Транспорт Microsoft Exchange (MSExchangeTransport)"...
...
ПРЕДУПРЕЖДЕНИЕ: Ожидание запуска службы "Транспорт Microsoft Exchange (MSExchangeTransport)"...

И службы FrontEnd транспорта 

restart-service MSExchangeFrontEndTransport

В случае затыка со стороны Exchange и особенностей механизма работы его компонентов на пропушивание подзависших сообщений (СТРОГО В СЛУЧАЕ УСТРАНЕНИЯ ПРИЧИНЫ ИХ ВОЗНИКНОВЕНИЯ см. логи) может потребоваться до нескольких часов.

Мониторить очередь можно полем MessageCount на предмет неувеличения количества элементов в очереди.

Get-Queue

Ещё мои статьи по диагностике, оптимизации и решению проблем с Exchange Server

• Exchange POP3 Logon failure: unknown user name or bad password

• Восстановление элементов почтового ящика русского Exchange

• Exchange SMTP 550 5.1.1 by Recipient Filter agent

• Методика тестирования Exchange DAG из двух узлов

• Решение проблемы с EWS Exchange 2013

• Коротко об архивации Exchange

• Exchange после перезагрузки error SSL endpoint 0.0.0.0:444

• Восстановление удаленного почтового ящика в Exchange

• OAB 0x8004010F or 0x80190193 Exchange

• Удаление базы данных Exchange по умолчанию с сохранением системных почтовых ящиков

• Register This Connection's addresses in DNS ломает Exchange

• Зависание миграции почтового ящика Exchange

Мы имеем широкий опыт по настройкам, обслуживанию, поддержке, оптимизации ИТ инфраструктуры .

В компетенциях нашей команды ТЮН-ИТ технологии Microsoft, Oracle, vmWare, Huawei, Citrix, Cisco, Astra Linux и много open source продуктов (Xen & KVM based гипервизоры, Nix системы, сетевые технологии). 

Обращайтесь к нам как со сложными вопросами ИТ: мы открыты как для больших, так и малых проектов.