Wrong unread counts, folders that show the wrong items, broken search folders, a mailbox move that keeps failing on corrupted items: these point to logical corruption inside a mailbox rather than a damaged database. Exchange Server SE and Exchange 2019 fix it online with New-MailboxRepairRequest, the successor to the old ISINTEG tool. In this post I'll cover what it repairs, how to run it safely against a mailbox, an archive or a whole database, and how to confirm the result.
Errors this guide fixes
Event ID 10062 (MSExchangeIS Mailbox Store)Application logEvent ID 10048 (MSExchangeIS Mailbox Store)Application logEvent ID 10047 (MSExchangeIS Mailbox Store)Application logEvent ID 10059 (MSExchangeIS Mailbox Store)Application log
How it works#
A repair request runs inside the Information Store against the mounted database, so nothing has to be dismounted. A few rules from Microsoft's cmdlet reference shape how you use it:
- Only the mailbox currently being processed is disrupted; the other mailboxes in the database keep working.
- Once a request has started, you can't stop it except by dismounting the database.
- Per server, only one database-level request can be active, or up to 100 mailbox-level requests.
- It's an on-premises cmdlet; it isn't available in Exchange Online.
It repairs logical structures such as folder views, counts, search folders and the folder hierarchy, not physical page damage. If the event log shows ESE errors such as checksum failures, or a database copy reports corruption, fix the database (reseed from a healthy DAG copy or restore) rather than the mailbox.
You need a role that includes the cmdlet; Organization Management has it. To see which roles grant it in your organization, run Get-ManagementRole -Cmdlet New-MailboxRepairRequest.
Choosing the corruption type#
-CorruptionType is mandatory. These are the values you'll use most:
| Value | What it targets |
|---|---|
AggregateCounts | Folder totals, such as item and unread counts, that don't match the contents |
FolderView | Folder views that don't return the right contents |
SearchFolder | Corrupted search folders |
ProvisionedFolder | Provisioned folders pointing into parent folders that aren't provisioned |
MissingSpecialFolders | Missing default folders (Exchange 2013 and later) |
LockedMoveTarget | A mailbox locked by a move; valid only while the mailbox is locked |
AbandonedMoveDestination | Abandoned move destinations; database level only (Exchange 2016 and later) |
The reference lists many more values, several reserved for Microsoft's internal use, and marks a number of them, including LockedMoveTarget and DropAllLazyIndexes, as values you can only use on their own. Microsoft's own examples combine the classic four (ProvisionedFolder, SearchFolder, AggregateCounts, FolderView) in one request; run anything else in a request of its own.
Step-by-step#
1. Detect first#
New-MailboxRepairRequest -Mailbox alex@contoso.com -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView -DetectOnly-DetectOnly reports problems without changing anything, which is the right first step for an important mailbox or when you need evidence before a change window.
2. Watch the request#
Get-MailboxRepairRequest -Mailbox alex@contoso.com | Format-ListEach corruption type becomes its own task. Look at the job state (Queued, Running, then Succeeded or Failed), the progress percentage and the number of corruptions detected and fixed. Requests wait for workload management to dispatch them, so a few minutes in Queued is normal. The -Force switch runs a request immediately instead of waiting, so keep it for urgent cases.
3. Repair#
New-MailboxRepairRequest -Mailbox alex@contoso.com -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView
# The user's archive mailbox
New-MailboxRepairRequest -Mailbox alex@contoso.com -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView -Archive
# Special cases: one value per request
New-MailboxRepairRequest -Mailbox alex@contoso.com -CorruptionType MissingSpecialFolders
New-MailboxRepairRequest -Mailbox alex@contoso.com -CorruptionType LockedMoveTargetWarn the user first: access to the mailbox is disrupted while it's being processed, and the request can't be cancelled once it starts.
4. A whole database, or a mailbox by GUID#
New-MailboxRepairRequest -Database DB01 -CorruptionType AggregateCounts
Get-MailboxRepairRequest -Database DB01
$mbx = Get-MailboxStatistics alex@contoso.com
New-MailboxRepairRequest -Database $mbx.Database -StoreMailbox $mbx.MailboxGuid -CorruptionType FolderViewA database-level run works through every mailbox in turn, and only one can be active per server, so start it out of hours and expect it to take a while on large databases. The -StoreMailbox form is handy when all you have is a mailbox GUID, for example from an event or a move report.
5. Check the event log#
The Application log records repair activity under the MSExchangeIS Mailbox Store source. The IDs worth knowing:
| Event ID | Meaning |
|---|---|
| 10047 | A mailbox-level repair request started |
| 10059 | A database-level repair request started |
| 10048 | The repair request completed successfully |
| 10062 | Corruption was detected; the event lists each corruption and whether it was fixed |
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=10047,10048,10059,10062} -MaxEvents 20 |
Format-List TimeCreated, Id, ProviderName, MessageGet-MailboxRepairRequest remains the authoritative status; the events are the audit trail and give you the detail of what was found.
Verify#
- Run the same request again with
-DetectOnly. Good looks like every task finishingSucceededwith zero corruptions detected. - Check the original symptom in Outlook on the web first, because it reads the server directly. If cached-mode Outlook still shows old counts or views, test with a fresh OST or profile before assuming the repair failed.
- If the repair was for a failed move, retry the move and read its report again; see stalled and failed mailbox moves.
Tips & gotchas#
- Detect, then repair. It costs a few minutes and gives you a record of what was wrong.
- One database-level request per server. Plan database-wide runs one after another, not in parallel.
- Corruption that keeps returning points elsewhere: storage, a misbehaving client or add-in, or physical damage. Check
Get-MailboxDatabaseCopyStatusand the event log for ESE errors. - Repair before you migrate. Once a mailbox lives in Exchange Online this cmdlet isn't available to you, so fix known problems while the mailbox is still on-premises.
- Don't reach for eseutil. Logical problems in one mailbox don't justify taking a whole database offline.
