Normal issues on Exchange can be handled easily with no issues but when you have an Exchange Server dismounting your database unexpectedly with no particular reason will make you scratch your hair until it falls off, especially if you are trying to research and investigate the issue while frustrated users are constantly questioning when the service is coming back. Every Exchange Admin will encounter issues but the biggest headache is getting the service up and running in no time. This is a strange issue which can be very frustrating to solve since it’s unexpected.
If you are suffering from this issue the first place to look into, is in the event viewer after sorting by source MSExchangeIS under Application. Here you will find some errors with the ID 1001, 1002 and 4999 as below
Unhandled exception (Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: Unable to apply maintenance insert, index corruption?
Log Name: Application
Source: MSExchange Common
Event ID: 4999
Task Category: General
Watson report about to be sent for process id: 11204, with parameters: E12, c-RTL-AMD64, 15.00.0712.024, M.E.Store.Worker, M.E.S.Storage.LazyIndexing,
M.E.S.S.L.LogicalIndex.HandleIndexCorruptionInternal, M.E.Diagnostics.ExAssertException, 213a, 15.00.0712.000.
If you are using Exchange Server 2013 you might look into the Microsoft KB2846288 where the Exchange Information Store worker process crashed. The article might be related to you, if this happens every time you export a mailbox. From the article although it might not be related, you need to have your Exchange Server 2013 updated to Cumulative Update 2. So, you might need to install the update and see if the problem occurs again. If it does, then we need to dig deeper to see the cause of the issue.
One thing to try is to disable the indexing to test it out to see if the index is corrupted or not which if it is, it might affect your database. To disable the index means that any search is done against the database and it will impact performance. To disable it, we must use the PowerShell cmdlet Set-MailboxDatabase as below since this cannot be done from the Exchange Admin Center (EAC). Thou before starting here one must check the performance of the server, check if any updates where recently installed and list them and also check if there were any changes to the server in regards to third party software like antivirus or backup software and of course check the overall health of the server.
To enable the index again simply run the command with $True in the end of the command. Another thing to do is to stop the Exchange Search service which can be done by PowerShell using the cmdlet below or by stopping the service from the Services console and marking it with start-up disabled so that it doesn’t automatically start.
Give it some time to see if the issue re-occurs. If it doesn’t then you could try to re-index your database. This can be done by first stopping the Microsoft Exchange Search Service and the Microsoft Exchange Host Controller Service . The next process is to delete the existing CI catalog folder or move it to another location. After this process has been done, you would need to start the services in the order of Microsoft Exchange Search Service and the Microsoft Exchange Host Controller. Now, depending on the size of your database and number of mailboxes/ emails this could take some time.
If the problem still persists the only suggestion is to move to another database by creating the new database and move the mailboxes from one database to another. I am saying this since the database might be corrupted and the only way is to migrate. Also for the reason of support from Microsoft. To native tool EseUtil can be used to try to fix a corrupted database, I am saying try because it depends on the level of damage the database has sustained as it isn’t a fool proof tool. The reason being we didn’t go through this tool is for the reason that when you run the EseUtil against a database, there is a repair count parameter which is increased every time the database is repaired. If you would reach out to Microsoft for support and they find out that the count is greater than 0, they will not attempt to fix the issue and suggest to move to another database.
To move to another database you must open the EAC, click on Recipient and click on Migration. Click on the + button and click on Move to a different database.
Add the users you want to move and click Next.
Enter a name for the migration, select the Target databases for the mailbox and archive and select how you would want the migration being just mailbox, or archive if available. Enter the Bad item limit. This limit will tell the process to stop if 10 (default) issues are found with the database.
After this you would need to select one recipient to receive the report and if it is going to start manually or automatic. Once done, the migration will start and you can see the progress from the EAC or wait until you receive the notification via email.
So this is the process to move the mailboxes from tone database to another, but since the issue is with the mailbox database dismounts unexpectedly, this will kill your process and you would need to restart the process each time. The solution would be to run these migrations in batches maybe it will finish before it dismounts. Another alternative is to use the New-MailboxExportRequest to export the mailboxes to PST and then use the New-MailboxImportRequest to import them into the new database, but you would still end up in the same problem. This is very time consuming to do apart from issues that you might encounter.
As the best solution that could be used in case your database is corrupt and to migrate to a new database one can call for help using the application Stellar Repair for Exchange. Exchange Server Recovery Software can open any EDB file of any format and damage. You can browse through the EDB file with a very good and familiar Outlook-ish interface. Exporting to PST and other formats such as HTML, EML and other with a click of a button. To solve the current issue of the migration, you can simply dismount the database from Exchange and selecting the mailboxes to export. With Stellar Repair for Exchange you can import a damaged EDB file directly to a live Exchange Database. You can also use the same method to migrate to Office 365.