Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы Exchange – повреждение (логические ошибки) в почтовом ящике пользователя. Подобные логические ошибки проявляются в таких проблемах, как ошибки синхронизации и зависания в Outlook , неправильное представление элементов в папке, их неверное количество, сбои в поиске, ошибки в общих папках и т.д.
Эти ошибки в основном возникают из-за сбоев на стороне клиента Outlook, в том случае, если клиент при обработке элементов почтовых папок некорректно обновляет флаги MAPI (особенно часто это происходит с «общими» ящиками, с которыми одновременно работают несколько пользователей). В большинстве случаев пользователь может даже не подозревать о наличие в его ящике или папках ошибок, т.к. внешне все работает нормально. Но при некоторых ошибках пользователь может испытывать проблемы с доступом к ящику или отдельным папкам, просмотру или удалению писем или папок, хранящихся в ящике и т.п.
В том случае, если пользователь сталкивается с такими проблемами, администратору сервера Exchange приходилось прибегать к одному из трех способов восстановления такого поврежденного ящика:
- Импорту данных из Outlook, запущенного в режиме кэширования, в PST файл, удалению и пересозданию почтового ящика «проблемного» пользователя на сервере, и, наконец, импорту данных из PST-файла в новый ящик Exchange. Данная методика предполагает определенное количество ручных манипуляция на компьютере пользователя.
- Полное отключение (размонтирование) почтового хранилища и его проверка утилитой Isinteg.exe (Information Store Integrity Checker), позволяющей исправить повреждения в базе Exchange на уровне приложения. Данный метод требует довольно длительного простоя почтового сервиса для всех пользователей, чьи ящики располагаются в отключенной базе.
Примечание. В некоторых случаях, можно попытаться переместить все рабочие ящики пользователей в «здоровую» почтовую базу. В этом случае получится провести проверку целостности хранилища без отключения большого количества пользователя. Однако, эта методика, по разным причинам, не всегда применима.
- Восстановление почтовой базы Exchange из резервной копии, импорт данных конкретного ящика в PST файл и дальнейший перенос данных в пересозданный ящик. Такая методика имеет недостаток – будут потеряны все письма, которые попали в ящик пользователя после выполнения последнего бэкапа.
Описанными выше методиками приходилось пользоваться администраторам Exchange-серверов вплоть до выхода Exchange 2010 SP1, в котором появился более удобный функционал для восстановления логической структуры поврежденного ящика – комадлет Powershell New-MailboxRepairRequest. Данный командлет позволяет на прикладном уровне найти и исправить логические ошибки и повреждения в базе Exchange, причем поиск и исправление ошибок может производиться как для конкретного ящика, так и для всех ящиков в базе (последовательно). Т.е. не требуется целиком переводить почтовую базу в режим offline, а в каждый конкретный момент времени будет недоступен только один ящик, тот, для которого в данный момент проводится проверка и восстановление целостности. Перед выполнением одного из описанных выше радикальных способов восстановления целостности ящика, определенно стоит попробовать воспользоваться этой командой.
Данный командлет можно использовать для поиска, восстановления и мониторинга поврежденных ящиков во всех поддерживаемых версиях Exchange: 2010 ,2013 и 2016.
Синтаксис команды таков:
Командлет позволяет найти и исправить следующие типы повреждений в ящиках Exchange:
- SearchFolder – ошибки в папках поиска
- AggregateCounts – проверка и исправление информации о количестве элементов в папках и их размере
- FolderView – неверное содержимое, отображаемое представлениями папок
- ProvisionedFolder – нарушения логической структуры папок
С помощью параметра DetectOnly можно выполнить проверку ящика или почтовой базы без выполнения каких-либо действий, например:
New-MailboxRepairRequest -Mailbox winitpro -DetectOnly -CorruptionType ProvisionedFolder, SearchFolder
Следующий пример запустит процесс анализа и восстановления ящика пользователя winitpro на все 4 типа повреждений:
New-MailboxRepairRequest -Mailbox winitpro -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Так можно запустить поиск ошибок и их восстановление для всех ящиков базы:
New-MailboxRepairRequest -Database “MailBaseMsk1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, Folderview
Команда выполняется в фоновом режиме и в консоль PowerShell результатов выполнения не выводит. Отследить ее запуск и восстановление можно по идентификатору задачи RequestID и журналу событий Windows (источник событий MSExchangeIS Mailbox Store: событие EventID 10059 — запуск сканирования, EventID 10048 успешное завершение операции).
Также могут быть полезными следующие EventID (для удобства отслеживания процедуры восстановления ящиков Exchange, их можно собрать в отдельное представление журнала MSExchangeIS Mailbox Store)
- 10044 – ошибка выполнения запроса восстановления ящика
- 10045 — ошибка выполнения запроса восстановления базы
- 10046 – Восстановление логической структуры ящика завершено успешно
- 10047 – запуск запроса восстановления уровня ящика
- 10048 – запрос восстановления успешно завершен
- 10049 – ошибка выполнения восстановления, обнаружен другой выполняющийся запрос в этой же базе
- 10050 –запрос восстановления пропущен для ящика
- 10051 – запрос восстановления отменен из-за того, что база отмонтирована
- 10059 – запуск восстановления на уровне базы Exchange
- 10062 – обнаружено повреждние
- 10064 – запуск восстановления общей папки
В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).
В качестве практического примера использования командлета рассмотрим небольшой кейс.
Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:
Для проверки и восстановления целостности ящика была запущена команда:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).
