Падение Microsoft Exchange Transport (Excghange 2007) из-за большого роста mail.que

Файл mail.que распологается в папке:
C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue
и представляет из себя файл базы данных очереди сообщений для промежуточного хранения данных перед их доставкой. При быстром росте файла появляется множество файлов вида:
trn00000290.log
Вообщем работа с этим файлом у Exchange построена точно таким же образом как с базами хранения, и к нему применимы те же инструменты проверки целостности и дефрагментации типа eseutil и isinteg.
Суть проблемы:
Обнаружили, что вообще перестала досталяться вся почта, как внутри организации, так и на ружу. Оказалось что останавливается служба на транспортном сервере (с ролью HubTransport).
Архитектура:
Exchange 2007 - три узла - кластер почтовых ящиков и 3-й узел все остальные роли. (Exchange 2007 SP1 RollUp9 если не ошибаюсь).
Трабшутинг:
1.Останавливаем службу Microsoft Exchange Transport , если сама не "упала"
2.Удаляем всё содержимое папки "C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue" фсе необходимы файлы будут пересозданы.
3.Единственным инструментом, оказавщим реальную помощь оказалась бесплатно распространяемая программа ExInsight. Благодаря котрой удалось "угадать" того самого "проблемного пользователя", который "валил" транспортный сервер. Подключаемся к серверу почтовых ящиков - в нашем случае - кластер и смотрим во время сетевой активности от какого пользователя больше всего IMAPI пакетов. Надо сказать что днем, когда сетевая активность пользователей большая - это практически невозможно. Делал всё - поздно вечером. И при подскоках сетевой активности легко обнаружил пользователя. Надо сказать, что сервер вел себя очень интересно, так при запуске службы транспорта через некоторое время подскакивала сетевая активность и шел большой рост файла mail.que и числа вспомогательных файлов логов для него, видимо был повреждем почтовый ящик пользователя или какой-то глюк с одним из сообщений, и после определенного времени активность падала, но рост продолжался, видимо трафик буферезировался в оперативной памяти и и пока не был скинут в файл сетевая активность снова не подпрыгивала. Причем файл рос с такой скорстью что 5-ти мегабайтные логи не успевали урезаться. В прошлые разы таким способом на диске С заканчивалось всё свободное пространство и служба падала.
4.Пользовательский почтовый ящик (проблемный) переместил в хранилище почтовых ящиков для отключенных пользователей (оно у нас было специально) и отмонтировал хранилище для разбирательтва далее.