Post navigation

Goodbye IsInteg, hello new-MailboxRepairRequest

Update (8/24/2010): The Exchange team at EHLO posted a blog on IsInteg replacements. This article has been updated with the information that there is also a cmdlet to integrity check public folder databases.

Note: The following information is based on Exchange 2010 SP1 Beta and subject to change in the final product.

As of Exchange 2010 the well-known IsInteg tool was dropped. The IsInteg tool could be used with earlier versions of Exchange to detect and repair inconsistencies in the Exchange databases also known as information stores. IsInteg was complimentary to ESEUtil; Where ESEutil is used for maintaining, verifying and repairing ESE databases (which could happen to be Exchange databases), IsInteg is used to check and repair the integrity of Exchange databases. Note that for the tools to work you had to take your Exchange databases offline. Also, the process could take a while with large databases.

Then came Exchange 2010’s with it’s online database maintance. The database maintenance runs 24 x 7 on your Exchange 2010 databases in the background, without the need to take databases offline. The ESEUtil is still installed when you install an Exchange 2010 Mailbox Server role. Its purpose shifted from maintenance (which is now done 24 x 7) to inspecting and recovering ESE databases. Jaap Wesselius has written a nice article on using ESEUtil in Exchange 2010.

IsInteg is also installed with the Mailbox Server role (default location C:\Program Files\Microsoft\Exchange Server\V14\Bin). But please, don’t use it. IsInteg hasn’t been updated to understand Exchange 2010’s new database structure. But I hear you asking, without IsInteg, how can you (manually) check database integrity?

This is where the SP1’s new cmdlet New-MailboxRepairRequest comes into play. This cmdlet is meant to be a replacement for IsInteg ability to check & repair the integrity of mailbox databases integrity. New-MailboxRepairRequest can be used to detect and fix mailbox corruption, per mailbox or per database. This functionality is an improvement over IsInteg, since you can not only check databases but individual mailboxes as well without taking databases offline. Even better, only the mailbox that is currently being checked becomes unavailable; all other mailboxes in the databases remain fully operational.

The syntax of New-MailboxRepairRequest is as follows (left common parameters like Confirm and WhatIf out):

As you can see, New-MailboxRepairRequest doesn’t show any results. For that, you need to open the application eventlog of the Exchange Server hosting the mailbox or (active) database you checked or repaired and look for ‘MSExchangeIS Mailbox Store’ events. Use the RequestID the cmdlet new-MailboxMoveRequest returned to look up the events. It will log when it started (and what parameters were specified) and log results. In the example above, New-MailboxRepairRequest returned 2661da49- … for the mailbox check. As we can see, the integrity check of the mailbox was succesful.

Exchange 2010 SP1 will also introduce a new cmdlet to repair public folder replication issues. The cmdlet to use is:

Be advised that, like ESEUtil and IsInteg, repairing an Exchange database or mailbox might cause data loss. To bring the mailbox or database back to a readable and consistent state the utility might cut out the parts it doesn’t understand .. with an axe.

And finally a quick note that to avoid possible performance issues the number of repair requests is 1 for database-level repairs and 100 for mailbox-level repairs per server.

Like this:

About Michel de Rooij

I'm a Microsoft Office Apps and Services MVP, with focus on Exchange Server, Office 365 and with a PowerShell affection. I'm is a consultant, publisher of EighTwOne, published author, and speaker. You can find me on Twitter, LinkedIn, Facebook.

This command doesn’t even work to repair anything. I’ve run it 100 times and data still exports via New-MailboxExportRequest into corrupt PST files. ISINTEG was way better IMO. You can’t even run ISINTEG anymore, it always crashes since SP1 depreciated it.

What type of corruption do you encounter? PSTs can’t corrupt because of exporting items to them (unless there are other issues); corrupt items maybe, yes, often when the mailbox is old and used with legacy Outlook versions. NMER only performs some (logical) checks, but it does it online. Moving the mailbox to a different database allows you to skip bad items (from Exchange’s standpoint).

Huh? I’m running the New-MailboxExportRequest and every PST that comes out is corrupt, SCANPST even confirms this. Yet this lovely command included to replace ISINTEG says everything in the database is great, ESEUTIL says everything is great too. I’ve already moved everyone to a new database, nothing is noted as corrupt and everything moves.

I have a question for you – I have been assigned a task to repair corrupt EDB and restore inaccessible mailboxes. I have gone though many top forums, some experts recommend powershell scripts to repair exchange 2010 edb file and some of them recommends third party exchange recovery tools like Stellar Phoenix Exchange Recovery, Datanumen exchange OST recovery. But I’m confused, which way to go – powershell cmdlets or third party tools? Which repairs corrupt EDB quickly and securely without data loss? Let me know your thoughts.

It depends. In any case, corruption is corruption and potential data loss (unless you have a backup somewhere). Exchange can often repair things itself, those 3rd party EDB tools are nice for mailbox extraction (I doubt if they can do a better job at fixing things – remember, corruption is corruption), and recovery from OST would be last resort (manual process). This is a typical example why you should have multiple database copies.

Yep. Same issue here. Exchange 2013 SP1 CU 12. The repair request simply sits at “Queued” indefinitely. I created a repair request using the -DetectOnly parameter and after a whole week, the request status still reports as being Queued. Absolutely nothing in the logs either as to why this is the case. All mailboxes in this environment were moved from legacy Exchange 2007 to 2013 as part of a mail systems migration.

Copyright

Unauthorized use or duplication of this material without permission from EighTwOne is strictly prohibited. Excerpts and links may be used, provided full and clear credit is given to EighTwOne with appropriate direction to original content.

Disclaimer

EighTwOne takes steps to make sure content of this site is correct. However, usage is at your own risk. EighTwOne does not accept responsibility or liability for errors or omissions in the content. Content is “as is”, without guarantees on completeness or accuracy of results obtained from using this information. Opinions expressed are my own.

About Michel de Rooij

Michel is an Office Apps & Services MVP with a PowerShell affection, and publisher of EighTwOne. You can find him on Twitter, LinkedIn, Facebook. Please use the Contact form for questions, or inquiries on consulting, support or other engagements.