Чистим почтовые ящики мониторинга


Как я уже писал, встроенный в Exchange Server 2013 механизм контроля здоровья обладает широкими возможностями по восстановлению работоспособности системы вплоть до рестарта сервисов и системы. Если этот механизм неисправен, то это может вызвать серьёзные проблемы в работе Exchange Server. Поэтому нужно следить за исправностью этого механизма. Вот пример такой ситуации.

На днях Operation Manager показал алерты для Exchange Server 2013 указывающие на проблемы в передаче почты. При анализе было установлено, что не отрабатывает монитор контролирующий доставку писем MailboxDeliveryAvailabilityMonitor. Если нет SCOM, то проблемные мониторы можно вывести командой:

Get-ServerHealth | ? AlertValue -eq "Unhealthy"

В этих объектах есть поле с точным временем возникновения события (как и в алерте SCOM), по которому можно найти и посмотреть сообщение об проблеме в журнале Microsoft-Exchange-ActiveMonitoring.

У меня в этом сообщении оказалось:

ResultId 133824024

ServiceName MailboxTransport

IsNotified 0

ResultName MailboxDeliveryAvailability

WorkItemId 53

DeploymentId 0

MachineName EXMB1

Error Probe to HealthMailbox3450f0e101ee42a79de34ab630a5753a@domain.ru failed with error BDAT response not as expected. Actual: 250-250 2.0.0 STOREDRV.Deliver; delivery result banner 250-250 2.0.0 OK[resubmit=False] 250 554 5.2.2 mailbox full; …

Как видно в сообщении служебный почтовый ящик с именем HealthMailbox3450f0e101ee42a79de34ab630a5753a переполнен. Таким образом сама система работоспособна (почтовые сообщения клиентов передаются нормально), но мониторинг частично не работает и провоцирует алерты.

Причина переполнения служебного ящика в том, что на него действует квота почтовой базы на размер почтовых ящиков. Как исправить проблему и предотвратить её в будущем?

Самый простой путь устранения проблемы это пересоздать почтовые ящики мониторинга скриптом, который я опубликовал ранее. (Либо скачать в TechNet Gallery) (Если вы просто хотите почистить существующие почтовые ящики мониторинга, то это не решит проблему: вы не сможете это сделать, т.к. часть из этих ящиков заблокирована для доступа.)

Как предотвратить проблему в дальнейшем? Можно использовать политики хранения. Если вывести свойства почтового ящика мониторинга, то в поле RetentionPolicy увидим «Default MRM Policy». Значит по умолчанию политика назначается, и нам нет необходимости назначать её вручную скриптом. Только эта политика по умолчанию ничего не чистит. Следовательно, мы можем изменить эту политику так, чтобы старые письма удалялись автоматически, например, через неделю.

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

Будьте внимательны с активным мониторингом (Active Monitoring) и управляемой доступностью (Managed Availability)!

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: