New-MailboxRepairRequest failed with Event ID 10049

Bharat BhushanSolution Manager
Experts in data recovery from corrupt Exchange mailboxes, SQL database, and Outlook emails.
Published:
Updated:
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corruptions within Exchange mailboxes.

Sometimes they can fail giving rise to a more pressing question – is there a sure-shot way to deal with Exchange corruption? Let us find out!

Microsoft Exchange server plays home to thousands of user mailboxes in any organization. Damages and corruption within Exchange servers can be catastrophic since they can result in server downtime and mailbox inaccessibility for hundreds of users. That was probably what prompted Microsoft to develop the New-MailboxRepairRequest cmdlet to detect and fix mailbox corruptions in Exchange versions 2016. While more often than not, this cmdlet succeeds in repairing mailboxes, users have reported some cases where it has failed giving rise to even more problems. We’re exploring one such situation in this article.

The New-MailboxRepairRequest Cmdlet

As already mentioned, the New-MailboxRepairRequest cmdlet is used to detect and fix mailbox corruptions in on-premises Exchange Server 2016. This cmdlet can be run against a specific mailbox or a database and once it begins working, it can't be stopped unless you dismount the database being repaired. The cmdlet aims to fix the following types of mailbox corruptions:

  • Aggregate counts on folders reflecting incorrect values
  • Search folder corruptions
  • Views on folders returning incorrect contents
  • Provisioned folders pointing into incorrect un-provisioned parent folders


The account that is used to run this cmdlet must be assigned specific permissions before doing so. Also, once it completes execution, administrators can use the Exchange Event Viewer to view the details of the request (whether it succeeded or failed).

Problem Scenario

Now coming to the main point of discussion here; consider a scenario where a mailbox database that was in “dirty shutdown” state was repaired using the eseutil /p command. While the database mounted successfully indicating that errors were fixed, some unexpected issues cropped up with some users' mail not showing up in Outlook when running in Cached Exchange mode.

Such a situation is indicative of corruption within the mailbox database. The best way to resolve this problem is to run the New-MailboxRepairRequest to detect and fix corruption within the database in question. However, we recently came across a technical forum where a user reported that New-MailboxRepairRequest failed with Event ID 10049.

A few Manual Solutions

Event ID 10049 of the New-MailboxRepairRequest indicates that the mailbox or database repair request failed because Exchange encountered a problem with the database or another task is running against the database. A few manual ways to fix this problem are:

Solution 1:

  1. Run the New-MailboxRepairRequest command again.
  2. If the problem persists, run Eseutil to check the drive for errors.
  3. Then run the Microsoft Exchange Troubleshooting Assistant v1.1 with the tagISINTEG property. Save the ExTRA log trace information and then contact Microsoft support services.

Solution 2:

  1. Create a new mailbox database and then move the affected mailboxes over to it
  2. Export the emails from the affected mailbox to a PST folder
  3. Delete the mailbox
  4. Create a new mailbox and import the emails in from the PST

Solution 3:

If you are using third party tools like virus scan or anti-spam, disable these tools and then try the repair process again.

Solution 4:

Move the affected database file to another Exchange server and run the command

What if manual methods don’t work?

While the above mentioned manual methods tend to fix mailbox database corruptions, in rare situations, all of these methods might fail. In such a scenario, you would either have the option of contacting Microsoft customer support and wait for their assistance (and experiencing downtime till you get it), or get instant help from reliable third-party automated Exchange database repair software.

If you decide to go with third-party Exchange repair product (which is a good choice by the way!), we suggest that you use Stellar Phoenix Mailbox Exchange Recovery. This professional software efficiently repairs even severely corrupted Exchange Database (EDB) files and helps restore mailbox contents into usable MS Outlook PST files. You can use this product to recover dismounted EDB files, and repair large or multiple EDB files simultaneously. With advanced options like facility to export recovered mailboxes to Live Exchange and Office 365, option to save recovered emails in multiple formats like MSG / EML / HTML / RTF / PDF, and compatibility with various Exchange versions, this application will prove to be your one-stop solution to 99% of Exchange troubles encountered on a day to day basis.

Summing it up

When facing Exchange problems, don’t forget to take ample and proper backups before trying out any kind of repair / recovery mechanisms. Read up and try out only those manual solutions about which you are sure or which have no side-effects. Else, avoid worsening the damage and use reliable third-party Exchange repair software like Stellar Phoenix Mailbox Exchange Recovery.

1
3,091 Views
Bharat BhushanSolution Manager
Experts in data recovery from corrupt Exchange mailboxes, SQL database, and Outlook emails.

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.