Exchange administrators often have to deal with various damages and logical errors in users’ mailboxes. Such logical errors appear in such problems as synchronization errors, Outlook hangs, incorrect representation of the folder items, wrong items number, search and public folders errors, etc.
These errors mostly occur due to failures on the Outlook, in case when client incorrectly updates MAPI flags during mailbox folders elements processing. Most often, this happens with shared mailboxes which is used by several users simultaneously. In most cases, the user may not even be aware of the presence of errors in the connected mailbox or folders, formally everything is working fine. However, with some errors, the user may experience problems while accessing the mailbox or certain folders, viewing or deleting emails or folders, etc.
If the user encounters such problems, the administrator of the Exchange server should use one of three following ways to restore such a damaged mailbox.
- Importing data from Outlook running in cached mode to a .PST file, removing and re-creating a new mailbox for “problem” user, and finally importing data from the PST file to the new Exchange mailbox. This method assumes a certain amount of manual manipulation on the user’s computer.Tip. You can import and export data to PST files in Exchange Server 2019/2016/2013/2010 using the New-MailboxImportRequest and New-MailboxExportRequest cmdlets.
- Complete unmounting of mailbox store and checking it with Isinteg.exe (Information Store Integrity Checker) utility which allows to fix damages in Exchange base on application level. This method requires quite long mail service downtime for all users whose mailboxes are allocated in a disconnected database.Note. In some cases, you can try to move all user`s mailboxes to the “healthy” mailbox database. In this case, you can check store integrity without disabling a large number of users. However, this technique is not always applicable for various reasons.
- Restore the Exchange database from backup, import data from a specific mailbox to PST file, and further data transfer to the re-created mailbox. This method has one disadvantage – all emails which got to the user`s mailbox after the last backup execution time can be lost.
Exchange server administrators had to use all methods described above up to Exchange 2010 SP1 release when more convenient functions appeared to restore the logical structure of the damaged mailbox – the new PowerShell cmdlet New-MailboxRepairRequest. This cmdlet allows you to find and fix all logical errors and corruptions in the Exchange database on the application level. You can search and fix all errors for both a certain mailbox and all mailboxes in the database.
In addition, when you use the New-MailboxRepairRequest cmdlet, you do not need to completely take the mail database to offline mode. Only one mailbox for each database is unavailable, the one for which the verification and integrity is currently being performed. Before performing any of described above radical ways to restore of mailbox integrity you should definitely try to use this PoSh command.
You can use this cmdlet to find, repair, and monitor corrupted mailboxes in all supported versions of Exchange 2010, 2013, and 2016.
The syntax of New-MailboxRepairRequest cmdlet is as follows:
New-MailboxRepairRequest -Mailbox -CorruptionType <MailboxStoreCorruptionType[]> [-Archive ] [-Confirm []] [-DetectOnly ] [-DomainController ] [-WhatIf []]Cmdlet allows you to find and fix the following corruption types in Exchange mailboxes:
- SearchFolder – errors in search folders;
- AggregateCounts – check and correction on the number of items in folders and their sizes;
- FolderView – incorrect content represented by folder views;
- ProvisionedFolder – folder logical structure damage.
Using the DetectOnly parameter, you can check one mailbox or mailbox database without performing any actions, for example:
New-MailboxRepairRequest -Mailbox woshub -DetectOnly -CorruptionType ProvisionedFolder, SearchFolderThe following example will start the process of woshub user mailbox analysis and recovery for all 4 types of damage.
New-MailboxRepairRequest -Mailbox woshub -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, FolderviewThe following example will start the process of woshub user mailbox analysis and recovery for all 4 types of damage:
New-MailboxRepairRequest -Database “NYMailBase1” -CorruptionType ProvisionedFolder, SearchFolder, AggregateCounts, FolderviewThe command runs in background mode and its results are not displayed in the PowerShell console. You can trace it by the taskID (RequestID) or / and with the help of Windows event log (event source: MSExchangeIS Mailbox Store; EventID 10059 – repair request start; EventID 10048 successful completion of the repair request).
The following EventIDs can also be useful (for ease of tracking the recovery procedure for Exchange mailboxes, you can combine them into a custom event view with the source MSExchangeIS Mailbox Store)
- 10044 – The mailbox repair request failed for provisioned folders
- 10045 – The database repair request failed for provisioned folders
- 10046 – The provisioned folders repair request completed successfully
- 10047 – A mailbox-level repair request started
- 10048 – The repair request successfully completed
- 10049 – The mailbox or database repair request failed because Exchange encountered a problem with the database or another task is running against the database
- 10050 – The mailbox repair request task skipped a mailbox
- 10051 – The database repair request was cancelled because the database was dismounted.
- 10059 – A database-level repair request started
- 10062 – Corruption was detected
- 10064 – A Public Folder repair request started
One of the features of the New-MailboxRepairRequest cmdlet – after it is started, the mailbox repair process cannot be interrupted without stopping the Exchange Information Store service and unmounting the mailbox database.
If there are several mailbox databases on the server, in order to maintain the performance of the Exchange server, it is not recommended to run New-MailboxRepairRequest at the same time for a large number of databases (although only one MailboxRepairRequest process is supported for one database and up to 100 repair requests per server).
Let`s look at one small case as a practice-oriented example of cmdlet usage.
The Exchange 2016 user encountered the inability to view messages in one of the Outlook folders. Appointed folder was recovered from mailbox backup. However it’s appeared impossible to delete this folder with a help of Outlook / Outlook Web App / MFCMAPI (soft or hard deletion). When you try to delete a folder in Outlook 2016, you receive the following error:
Outlook is synchronizing local changes made to items in this folder. You cannot remove this folder until the synchronization with the server is complete
To check and restore the Exchange mailbox integrity, the following PoSh command was run:
New-MailboxRepairRequest -Mailbox [email protected] -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview
After the successful completion of recovery operation (eventid 10048), the corrupted folder immediately disappeared from Outlook Web App. As for the Outlook, here we had to delete local cache (ost file) for correct mailbox display.
