Using the New-MailboxRepairRequest cmdlet

This cmdlet was mentioned in a previous blog post but I’ve noticed that the information on it that’s out there can be a bit sketchy. So, for my own reference as much as for anyone else’s, here’s my notes on it:

New-MailboxRepairRequest can be run against a whole database (like its predecessor, ISINTEG) or against just one mailbox within it. If a repair is run against a single mailbox, only that mailbox will have service interrupted: all other users within that database are unaffected.

There are four areas that can be checked:

Search folder corruption
This option looks for all folders named in ptagSearchBacklinks, ptagSearchFIDs, and ptagRecursiveSearchFIDs. It verifies that each folder exists. If the folder no longer exists then it removes that folder from that list.

Aggregate counts on folders
Tallies up all the messages in a folder and keeps a running total of counts and sizes. Once the iteration is complete it will verify the computed counts against the persisted counts on the Folders table record. If there is a discrepancy it will update the persisted counts with those it has calculated.

Provisioned folders
Checks for provisioned folders with unprovisioned parent folders or vice versa

Folder view
Iterates all views for a folder then reconstructs a temporary copy of them. If there is a discrepancy between the two it will delete the view so it can be rebuilt from scratch the next time it is requested.

This cmdlet also includes a detectonly switch, if required, to simply report on problems without making changes. This switch doesn’t seem to affect user service (when tested). It should be safe to use even when a user hasn’t been notified of a service interruption. However that point may be moot: to repair any detected damage with this cmdlet you will affect the user.

Examples

A check on a user’s mailbox’s folder views, but without undertaking a repair, would be similar to:

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType FolderView -DetectOnly

The ‘MailboxID’ value can be a GUID, DN, UPN, LegacyExchangeDN, SMTP address, alias or in the format ‘domain\user’.

A more thorough check of a user’s mailbox, reviewing all four checkable areas at once, and completing a repair, would interrupt the user’s service. The command would look like this:

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

A check on a database, for search folder corruption only, (and repairing any errors found) would be similar to this:

New-MailboxRepairRequest -Database <DatabaseName> -CorruptionType SearchFolder

Output

There is no direct output from this tool into the Powershell console. To see what’s been found you must open the application event log of the Exchange Server which hosts the mailbox (you may need to check which is the active database) . Start by looking for MSExchangeIS Mailbox Store events with the event ID 10047 and 10048. To make things a little more challenging note that if you’ve run the New-MailboxRepairRequest cmdlet more than once the event log will only show the mailbox by GUID. To assist in finding the right one you may therefore want to run Get-Mailbox <name> |FL name,ExchangeGuid.

Event ID	Description
10044	The mailbox repair request failed for provisioned folders. This event ID is created in conjunction with event ID 10049.
10045	The database repair request failed for provisioned folders. This event ID is created in conjunction with event ID 10049.
10046	The provisioned folders repair request completed successfully.
10047	A mailbox-level repair request started.
10048	The mailbox or database repair request completed successfully.
10049	The mailbox or database repair request failed because Exchange encountered a problem with the database or another task is running against the database. (Fix for this is ESEUTIL then contact Microsoft Product Support Services)
10050	The database repair request couldn’t run against the database because the database doesn’t support the corruption types specified in the command. This issue can occur when you run the command from a server that’s running a later version of Exchange than the database you’re scanning.
10051	The database repair request was cancelled because the database was dismounted.
10059	A database-level repair request started.
10062	Corruption was detected. View the repair log details to see what the corruption type was and if it was repaired.

To make these events easier to find, you may want to create a custom view in the Event Viewer:

On the Action menu, click Create Custom View.
In Create Custom View, click By source, and then in the Event sources list select MSExchangeIS Mailbox Store.
In the box labelled <All Event IDs>, add the event IDs for the repair request events that you want to see. For all of this cmdlet’s events enter 10044,10045,01146,10047,10048,10049,10050,10051,10059,10062.
Click OK.
In Save Filter to Custom View, type a name for this view.
Click OK.

N.B.

To ensure that performance isn’t negatively impacted by this tool it is limited to working on one store at a time per server, or to examining 100 mailboxes.
This tool has a partner utility for public folder databases (New-PublicFolderDatabaseRepairRequest) which will accept only ReplState as the corruption type to query. All other syntax is the same.

anon says:

05/09/2014 at 9:27 pm

Thank you for this nice writeup.

Pete says:

23/06/2016 at 12:38 pm

Excellent, just what I was looking for.

Sean says:

14/11/2017 at 5:02 pm

Thanks for this, needed it during a mail migration.
For anybody that’s wondering like I was. A 6 GB mailbox took 2 minutes to find an error and fix it.
Will try the migration to 2016 again.

Nexus: News