Error Solved-the Copy of Database on This Server Was Unexpectedly Dismounted
Summary: The Exchange database may dismount unexpectedly when damaged, inconsistent or corrupt. It may also dismount when the Exchange Services are stopped, or storage media where database or logs are stored runs out of space or has insufficient space. In such cases, you need to recover the database and mount it back. Sometimes, you may require using an advanced Exchange database repair software.
A database dismount in Exchange Server is a serious issue that prevents users from accessing their mailboxes or sending and receiving emails. It can lead to unexpected downtime and data loss if not fixed.
This may occur due to any underlying issues with your Exchange Server or common reasons, such as abrupt shutdown or crash, malware or virus intrusion, power failure, etc.
In this blog, we will help you resolve the unexpected dismounting of the database on Exchange Server 2010, 2013. 2016 and 2019.
Fix Copy of Database Unexpectedly Dismounted Error
If you are suffering from the unexpected dismounting of the Exchange database from the server and it is frequent, you should check the event viewer first.
Sort the events by source MSExchangeIS under Application and look for the errors with the ID 1001, 1002, or 4999 as below:
Log Name: Application
Source: MSExchangeIS
Event ID: 1001
Task Category: General
Level: Error
Microsoft Exchange Server Information Store has encountered an internal logic error. Internal error text is (Unable to apply maintenance insert, index corruption?
Log Name: Application
Source: MSExchangeIS
Event ID: 1002
Task Category: General
Level: Error
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
Level: Error
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. ErrorReportingEnabled: True
If you find the error, the Microsoft Exchange Information Store service may have crashed or stopped.
In such a case, you can press Windows+R, type services.msc and press the Enter key. Next, look for the Microsoft Exchange Information Store service. Finally, right-click on the service and choose Start or Restart.
Then mount the database using the Mount-Database cmdlet in Exchange Management Shell or the Exchange Admin Center (EAC) web interface.
However, if this happens frequently or every time you export a mailbox, you may need to repair or update your Exchange Server to the latest Cumulative Update. This may resolve your problem of unexpected Exchange database dismount.
In addition, you may also follow the below-mentioned solutions to try troubleshooting and fixing the unexpected Exchange database dismount issue.
Disable the Indexing
Another thing you may try is to disable the indexing. This will help you test and see if the index is corrupted. If it is, it might affect your database and lead to unexpected dismounts.
To disable the index means that any search query will be slow and adversely impact the database performance.
To disable it, you can use the Set-MailboxDatabase PowerShell cmdlet in Exchange Management Shell.
Though before starting here, one must check the performance of the server. Check if any updates were 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 server’s overall health.
Set-MailboxDatabase “EX01DB01” –IndexEnabled $False
To enable the index again later, you may run the above command with the $True parameter at the end of the command (replace $False).
Another thing to do is to stop the Microsoft Exchange Search service. You can use the PowerShell cmdlet below.
Stop-Service MSExchangeFastSearch Set-Service MSExchangeFastSearch –StartupType Disabled
To revert, you must either use the Services Console to set the start-up to automatic or start the service. In PowerShell, this can be done as below.
Set-Service MSExchangeFastSearch –StartupType Automatic Start-Service MSExchangeFastSearch
You may also use the Services console to stop the Microsoft Exchange Search service. Make sure to mark it with start-up disabled, so it doesn’t automatically start.
Give it some time and check if the issue re-occurs.
If it doesn’t, you can try to re-index your database. This can be done by stopping the Microsoft Exchange Search and the Microsoft Exchange Host Controller services.
The next step is to delete the existing CI catalog folder or move it to another location.
After this, restart the services in the following order:
- Microsoft Exchange Search Service
- Microsoft Exchange Host Controller
Now, depending on the size of your database and the number of mailboxes/ emails, this could take some time.
Move Mailboxes to Another Database
If the problem persists, you should try to move the mailboxes to another database. For example, you can move to another existing database or create a new database to move the mailboxes.
This is required as the database might be corrupted, leading to unexpected dismounts.
You may try the native tool EseUtil in the Exchange Server to fix the corrupt database and then move the mailboxes to a new or existing database.
Moving is important since when running the EseUtil against a database, the repair count parameter increases from 0 to 1.
If you have ever 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 moving to another database.
Follow these steps:
- Run the following command to verify the database state
EseUtil /mh <DatabasePath.edb>
- Check the outlook for State: value. If it displays the database state as Clean Shutdown, you may skip moving the mailboxes. If the State is Dirty Shutdown, run the following command to perform soft recovery.
Eseutil /r E01 /l <Log path location>/d <Database path location>
- Check the database state again using the following command.
EseUtil /mh <DatabasePath.edb>
- If the State is displayed as Clean Shutdown, you may mount the database using EAC and then move the mailboxes from the recovered database to a new database by following these steps.
NOTE: If the state is still a Dirty Shutdown, you may run Hard Recovery (EseUtil /p). However, this can lead to data loss as it purges irrecoverable data. Instead, use Exchange Recovery software to restore all your mailboxes from the old to a new database on your Exchange Server.
To move to another database, follow these steps:
- 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, and select the Target database for the mailbox and archive.
- Also, choose how you want to migrate—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, select one recipient to receive the notification report when the Migration is finished. Once done, start the Migration. You will see the progress from the EAC or wait until you receive the notification via email.
Wait for the synchronization (Migration) to finish. After mailboxes are moved, you may verify them and delete the database that dismounted unexpectedly.
Final Thoughts
Since the issue with the mailbox database is dismounting unexpectedly, you should check the database, recover it if required, and then move the mailboxes to a new database in small batches. This is important to avoid killing the migration process if the problematic database dismounts unexpectedly during the synchronization. If this happens, you will have to restart the process again.
Alternatively, use the New-MailboxExportRequest to export the mailboxes from the database dismounting unexpectedly to PST files. Then, use the New-MailboxImportRequest to import them into the new or another database.
However, this can be a time–consuming task apart from issues you might encounter.
The best solution to repair the database with complete integrity and move mailboxes from your corrupt or damaged Exchange database to a new database is using Exchange Server Recovery Software, such as Stellar Repair for Exchange.
The software can open any EDB file with any level of corruption or damage. It helps quickly recover and restore mailboxes to new PST files. You may also export them directly to a new database on Live Exchange Server or Office 354 tenant. It auto maps the source and destination mailboxes and uses a parallel processing technique for faster export.