Восстановление поврежденных ящиков и папок в Exchange 2016, 2013, 2010

Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы 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.

Синтаксис команды таков:

New-MailboxRepairRequest -Mailbox -CorruptionType [-Archive ] [-Confirm []] [-DetectOnly ] [-DomainController ] [-WhatIf []]

Командлет позволяет найти и исправить следующие типы повреждений в ящиках 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 2013 появился специальный командлет Get-MailboxRepairRequest, позволяющий узнать статус выполнения операции восстановления ящика.

Примечание. Одной из особенностей командлета New-MailboxRepairRequest – после его запуска, процедуру исправления ящика нельзя прервать без остановки службы Exchange Information Store и отмонтирования почтовой базы.

В том случае, если на сервере имеется несколько почтовых баз, с целью сохранения производительности сервера Exchange, не рекомендуется одновременно запускать New-MailboxRepairRequest сразу для большого количества баз (не смотря на то что, для одной базы поддерживается только один процесс MailboxRepairRequest, в рамках одного сервера одновременно может работать до 100 запросов).

В качестве практического примера использования командлета рассмотрим небольшой кейс.

Пользователь Exchange столкнулся с невозможностью просмотра писем в одной из папок Outlook. Указанная папка была восстановлена из резервной копии ящика. Однако саму папку ни из Outlook, ни из Outlook Web App, ни даже hard и soft удалением с помощью MFCMAPI, удалить не получилось. Ошибка клиента Outlook, мало о чем говорит:

Cannot delete this folder. Right-click the folder, and then click Properties to check your permissions for this folder. See the folder owner or your administrator to change your permissions. Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete

Для проверки и восстановления целостности ящика была запущена команда:

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

После успешного завершения операции восстановления (событие 10048 в журнале), поврежденная папка в Outlook Web App пропала немедленно, в Outlook же, для корректного отображения «обновленного» ящика пришлось удалить локальный кэш (ost файл).