Exchange 2010 проверка базы на ошибки

В прошлой статье мы обсудили вопрос мягкого восстановления базы данных при помощи команды Esutil /R. В подавляющем большинстве случаев эта команда отрабатывает успешно и базу удается смонтировать на сервер. Но бывают и такие ситуации, когда база сильно повреждена и мягко восстановить её не получается, в таких случаях необходимо попытаться вытащить из базы как можно больше информации.

Исправление

Для исправления базы данных придется использовать команду ESEUTIL /P. Стоит несколько раз подумать, прежде чем пользоваться функцией Repair, т.к. данная операция в ЛЮБОМ случае приведет к потере данных, и сколько именно данных будет потеряно спрогнозировать не реально, можно только с уверенностью сказать, что информация, находящаяся в лог-файлах будет на 100% потеряна.

Все дело в том, что база данных почтовых ящиков не является реляционной, а состоит из множества деревьев с указателями на страницы с данными. Так вот, ESEUTIL /P будет проверять все эти указатели и при обнаружении несоответствий, просто удалит указатель, в независимости от того, на какие данные он ссылается.

Процесс исправления запускается не по отношению к лог-файлам, как было с восстановлением, а по отношению к файлу самой базы данных.

eseutil /P MDB2.edb

После запуска на экран выводится предупреждение, которое позволяет одуматься и отказаться от этого метода восстановления базы.

Рис.1: Предупреждение перед операцией Repair.

Если все же вы твердо решили продолжать, то нужно нажать ОК и утилита ESEUTIL сделает все сама.

Рис.2: Исправление базы при помощи команды ESEUTIL /P.

После операции Repair может быть заметно снижена производительность базы данных, в связи с этим рекомендуется делать автономную дефрагментацию базы при помощи команды ESEUTIL /D, в результате выполнения команды будет создана абсолютно новая база данных, но тут нужно помнить, что для дефрагментации базы у вас должно быть свободного места больше на 110%, чем занимает исходная база.

Проверка логической целостности

После дефрагментации нужно будет проверить логическую целостность базы данных. Ранее, для этого используется утилита ISINTEG. На серверах Exchange 2007 и старше можно было выполнить команду:

isinteg -s имя_сервера -fix -test alltests

тем самым инициировав процесс проверки базы данных.

Рис.3: Проверка логической целостности базы при помощи ISINTEG.

Описание программы ISINTEG.

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

Exchange 2010

Плюсом к этому, с приходом Exchange 2010 ISINTEG перестала понимать все функции новой базы данных. Но это и нормально, ведь данное средство не изменялось с 2000-го года!

К счастью, сервер Exchange 2010 и не нуждается в отдельном средстве проверки базы, т.к. по умолчанию, для каждой базы на сервере ежедневно по расписанию производится фоновое обслуживание, которое автоматически находит ошибки и при этом не требует отключения базы.

Рис.4: Фоновое обслуживание базы данных.

Exchange 2010 SP1

С входом Exchange 2010 SP1, появилась замена средства ISINTEG в виде новых командлетов:

· New-MailboxRepairRequest – тестирование и исправление почтовых ящиков;

· New-PublicFolderDatabaseRepairRequest – тестирование и исправление общих папок.

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

Синтаксис использования командлетов следующий:

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

Здесь

· Mailbox или Database – это соответственно почтовый ящик или база данных;

· CorruptionType – вид проверки, которую вы желаете запустить:

o SearchFolder;

o AggregateCounts;

o ProvisionedFolder;

o FolderView.

· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;

· DomainController – определяет контроллер домена для обновления данных.

Для того, чтобы запустить сразу все виды проверки, то необходимо их перечислить через запятую:

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

Если нужен только один вид проверки для базы данных, то команда будет выглядеть следующим образом:

New-MailboxRepairRequest –Database MDB2 –CorruptionType AggregateCounts

Рис.5: Проверка всей базы.

В результате команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows вы найдете событие под номером EventID = 10059, которое будет означать запуск сканирования

Рис.6: Запуск сканирования базы данных в журнале событий Windows.

И событие с EventID = 10048, которое будет означать успешное завершение операции.

Рис.7: Завершение операции сканирования базы данных в журнале событий Windows.

Заключение

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

Since the earliest versions of Exchange Server, the Information Store Integrity Checker (ISInteg) has offered Exchange administrators a way to check mailbox and public folder database integrity. ISInteg checks and fixes Exchange database errors that may prevent the database from mounting, prevent the user from logging on or from receiving, opening or deleting email. Curious to know what changes are coming to ISInteg in Exchange 2010 SP1? Let’s take a look.

Cool Features

These new ISInteg cmdlets come with some cool new functionality!

• The cmdlets work with the database mounted. It’s no longer required to unmount the database to perform an integrity check or fix database errors.
• You can repair logical corruption at the mailbox level.
• You can fix corrupt search folders.
• You can fix the Provisional Fid.
• You can fix Aggregate Counts.

ISInteg can now work at the database or mailbox level

How does it do that? Well, the new schema in Exchange 2010 effectively partitions the database by mailbox. So the top problems fixed by ISInteg are now mostly limited to the affected mailboxes only. Previous versions of ISInteg required the database to be offline while validation and fixing are in progress. In Exchange 2010 SP1, the ability to do these checks at the mailbox level removes the need to dismount the database. It is actually required to have ISInteg operate against an online database!

New-MailboxRepairRequest

The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions:

• Search folder corruptions (SearchFolder Repair tasks now look for all folders named in ptagSearchBacklinks, ptagSearchFIDs, and ptagRecursiveSearchFIDs and verifies that each folder exists. If the folder no longer exists, then it will remove that folder from the list.
• Aggregate counts on folders that aren’t reflecting correct values (AggregateCounts Repair tasks tally all messages in a folder and keep a running total of various counts and sizes. Once the iteration is complete, it will verify the computed counts against the persisted counts on the Folders table record for the folder. If there is a discrepancy, it will update the persisted counts to reflect the computed counts.
• Views on folders that aren’t returning correct contents (FolderView Repair tasks will iterate over all views for a folder and for each one, bring the view fully up to date and then reconstruct a temp copy. If there is a discrepancy between the existing view and the contents of the temp table, it will delete the view so it can be rebuilt from scratch the next time it is requested.
• Provisioned folders that are incorrectly pointing into unprovisioned parent folders (ProvisionedFolder Repair tasks can fix Provisioned folders incorrectly pointing into unprovisioned parents or vice versa.

Syntax

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

New-MailboxRepairRequest -Database <DatabaseIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Parameters

New-PublicFolderDatabaseRepairRequest

The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes Public Folder replication state problems.

Syntax

New-PublicFolderDatabaseRepairRequest -Database <DatabaseIdParameter> -CorruptionType <PublicFolderDatabaseCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Parameters

• Database: (required) Specifies the Public Folder database on which you will run this command. You can use one of the following values:
  • GUID of the database
  • Database name
• CorruptionType: (required) Pretty easy, there’s only one value.
  • ReplState
• DetectOnly: (optional) Specifies that you want this command to report errors, but not fix them. You don’t have to specify a value with this parameter.
• Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type «get-help about_commonparameters».

Examples

New-MailboxRepairRequest -Mailbox administrator@contoso.com -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

New-MailboxRepairRequest -Mailbox administrator -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -WhatIf

Ne
w-PublicFolderDatabaseRepairRequest -Database PFD01 -CorruptionType ReplState -DetectOnly

Some additional examples are provided in the cmdlet help. You can retrieve them using the following commands, or refer to New-MailboxRepairRequest and New-PublicFolderDatabaseRepairRequest cmdlet reference:

Get-help New-MailboxRepairRequest -examples
Get-help New-PublicFolderDatabaseRepairRequest -examples

I recommend that you get to know the cmdlets by using the cmdlet reference docs, or by using the following commands to retrieve detailed help from the shell:

Get-help New-MailboxRepairRequest -detailed (or -full)
Get-help New-PublicFolderDatabaseRepairRequest -detailed (or -full)

Event Reporting

After submitting the Mailbox or Public Folder repair request, you can monitor its progress with the Event Viewer. That’s right, no more text logs to weed through. The events are logged under the MSExchangeIS Mailbox Store source.

The following event IDs will be logged for repair requests:

• 10047 A mailbox-level repair request started
• 10064 A Public Folder repair request started
• 10048 The repair request successfully completed.
• 10050 The mailbox repair request task skipped a mailbox .
• 10059 A database-level repair request started.
• 10062 Corruption was detected.

Figure 1: Mailbox or Public Folder database repair request events are logged in the Application event log

Things to remember:

• Only 1 active repair task is permitted to be running per server if the active task is a database level repair.
• Only 100 mailbox level active repair tasks are permitted to be running at once per server.
• There is no -Server parameter to do all databases or mailboxes on a server.
• The repair task dies on database dismount or store stop/crash.
• The only way to stop a repair is to stop the store or dismount the database.
• Mailbox access will be disrupted for the mailbox that is being repaired.
• Repair for a mailbox will skip a mailbox if it has been quarantined.
• Repair will cause a move-mailbox operation to be delayed until the repair is completed.

Перейти к содержанию

Couldn't mount the database that you specified. Specified database: Mailbox Database; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)

Статья посвящена достаточно распространенной проблеме, с которой рано или поздно сталкиваются все администраторы 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 <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

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

Summary: New-MailboxRepairRequest cmdlet is the successor of the Microsoft ISInteg tool. In this write-up, the users will learn everything about this command and how to use it to fix corruption issues in the Exchange database.

Everyone knows that Microsoft Exchange databases are prone to corruption. As it stores all the crucial data of organizations, it becomes necessary for the administrators to keep the Exchange data safe and secure. The Exchange administrators usually go with the New-MailboxRepairRequest command to detect and repair the .edb file mailboxes from corruption.

You can use this command only in on-premises Exchange Server, that too in Exchange Server 2010, 2013, 2016, and 2019 only.

For Example:

Point to be Noted: The New-MailboxRepairRequest cmdlet doesn’t repair corrupt offline / dismounted Exchange database and mailboxes. For this, users can use the smart solution by SysTools that can remove corruption from dismounted as well as offline Exchange database files.

Users can use this command on all Exchange database mailboxes or on a specific mailbox. During the process, you cannot access the mailbox that is being repaired. To stop the request one has to dismount the database otherwise user cannot terminate the command.

To maintain the performance, there can be only one request active on the server for Exchange database-level repair, and for mailbox-level repair, there can be up to 100 requests active on Exchange Server.

How Many Types Of Corruption Repaired By New-MailboxRepairRequest Cmdlet?

There are 4 types of corruption that you can use by this Exchange PowerShell command:

• FolderView
• SearchFolder
• ProvisionedFolder
• AggregateCounts

Note: You must have a required set of permissions to execute the New-MailboxRepairRequest PowerShell cmdlet. If you don’t have these permissions, then you won’t be to run the command or will get an error message.

Different Parameters Of New-MailboxRepairRequest Command

Users can use the parameters in the cmdlet given below while repairing the mailboxes and database:

-Archive
-Confirm
-CorruptionType
-Database
-DetectOnly
-DomainController
-Force
-Mailbox
-WhatIf
-StoreMailbox

Use Exchange PowerShell New-MailboxRepairRequest Cmdlet

Follow the commands given below to repair the database and mailbox:

1. Detect and repair all Folder views for Max mailbox

New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType FolderView

2. Following cmdlet only detect and report corruption issue on Search & Provisioned folder for Meghan mailbox.

New-MailboxRepairRequest -Mailbox Meghan -CorruptionType ProvisionedFolder, SearchFolder -DetectOnly

3. This command repair and detect aggregate counts of all Exchange mailbox on keven database

New-MailboxRepairRequest -Database Keven -CorruptionType AggregateCounts

4. Detect and Repair all corruption types for vox mailbox and archive

New-MailboxRepairRequest -Mailbox vox -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView -Archive

5. To detect and correct all existing corruption issues, create a variable to identify Kev mailbox. Later on, this variable is used to specify values for StoreMailbox and Exchange database parameters to generate the request.

$Mailbox =Get-MailboxStatistics Kev
New-MailboxRepairRequest-Databases$Mailbox.DatabaseStoreMailbox$Mailbox.MailboxGuid-CorruptionType ProvisionedFolder,SearchFolder,AggregateFolder,FolderView

This cmdlet doesn’t provide any feedback information in the Exchange Management Shell. For this one has to check the feedback logs in the application in Event Viewer under the Microsoft ExchangeIS Mailbox Store.

Perfect Alternative for the Aforementioned Command

If you feel the above-discussed procedure is a bit difficult for you or you are facing some sort of issues while running these commands, then you can go with SysTools Exchange Server Recovery Software. This is a competent solution that helps users to repair minor as well as major corruption issues with ease.

Download Now Purchase Now

The software is designed with advanced set of algorithms that makes the repair job seamless. The only thing that you need to do is to dismount the EDB file of the mailbox that you feel is corrupted. Then, load that EDB file into the software and repair those Exchange EDB files without any issue.

Additionally, once the corruption level is fixed, you can import the EDB file into Exchange using the same software. So, it is a complete solution for you to get your job done in quick steps.

Bringing It All Together

In this write-up, we have explained about the New-MailboxRepairRequest cmdlet, where it is used, various parameters, and types of corruption it repairs. The user and Exchange admin can easily repair Exchange mailbox and database without dismounting it. To use this command, you must have the technical knowledge and hands-on experience, if you find any difficulty to use this method then you can use the tool mentioned here which repairs the corrupt offline/dismounted file in a simplified way.