Summary: When the database crashes or dismounts from the Exchange Server, it can cause outage as users can neither access their mailbox nor they can send or receive new messages. Learn how to fix error "The mailbox with mailbox guid caused a crash or resource outage on database", mount the database and restore mailboxes using the built in tools and an advanced Exchange recovery software.
Developers always add new features for Exchange Server to make the lives of the Exchange Admins more relaxed and include more automation to the monitoring, secure and keep our Exchange Server running in good health and as safe of possible. With this in mind, Microsoft have introduced the automatic procedure to quarantine a mailbox in case it is deemed as costly to present it to the user or it will hinder the performance of the server.
This feature is available from Exchange Server 2010 with Service Pack 1 and onwards. It?s an excellent feature that protect your Exchange Server from mailboxes which are hungry for resources being attacked from a virus or ransomware, abnormal activity like for example an antivirus scanning the mailbox or a hacker spamming from it, basically if something is not in the norm. Exchange will identify these mailboxes and if a thread or more is accessing the mailbox either freezes for more than 60 seconds or it?s making the Information Store consume much CPU usage, it will be marked and quarantined. This will scale down some work from the admins who would constantly check the Exchange Server for any abnormal activity.
So why a normal healthy Exchange Server would have to worry about this feature and apart from the above, why would a mailbox be quarantined? The normal behaviour of this option is that if more than five threads to a mailbox freeze for more than 60 seconds or three threads crash in a period of two hours, the Information Store will flag the mailbox as a troubling mailbox and eventually quarantine the mailbox leaving the user or application unable to access the mailbox for 24 hours. If a normal user accesses his or her mailbox on a normal office work it should not create this issue but MAPI clients like Outlook would open more than one thread with the mailbox server so if an Outlook client is crashing or is heavy on the mailbox for a reason like virus or a third party application, this could get a mailbox quarantined.
To check if a mailbox is quarantined, you would need to use the Get-MailboxStatistics PowerShell cmdlet as below
Get-MailboxStatistics user01 | Select DisplayName, IsQuarantined | Format-Table -AutoSize
The IsQuarantined parameter will show false if the mailbox is not quarantined and true if it is. To disable a mailbox from quarantine you would need to use the Disable-MailboxQuarantine cmdlet as below.
Disable-MailboxQuarantine ?user01?
This will disable the mailbox from quarantine. In a normal scenario this would stop there and the issue would have been found, but one might find other issues hidden that might create havoc and a lot of headaches where in an Exchange Server 2013 mailboxes are quarantined without any warning or reason and to top that off the mailbox database would dismount.
The below event is also found in the event viewer when a mailbox is quarantined
ID: 1014
Level: Warning
Source: MSExchangeIS
Machine: ex01.mail.lan
Message: The mailbox with mailboxguid “6fe22b67-e191-4d84-b878-b452c85a8303” has been quarantined. Access to this mailbox will be restricted to administrative logons for 1.00:00:00 since the last report.
This is normal when a mailbox is quarantined, but then you will have the below error as the whole mailbox database is dismounted
ID: 1013
Level: Error
Source: MSExchangeIS
Machine: exchangeserver.contoso.com
Message: The mailbox with mailboxguid “6fe22b67-e191-4d84-b878-b452c85a8303″ caused crash or resource outage on database (GUID=”e2732878-db4a-413a-afe5-f0390b882c25”)
ID: 126
Level: Error
Source: ExchangeStoreDB
Machine: ex01.mail.lan
Message: At ’10/10/2019 5:35:03 PM’ the Exchange store database ?EX01-DB01′ copy on this server encountered an error that caused the database to be dismounted. For more detail about the failure, consult the Event log on the server for other “ExchangeStoreDb” or “msexchangerepl” events. A successful failover restored service.
This will surely create a panic as all the mailboxes will not be available. In case you are using high availability with Database Availability Groups (DAG), the database would simple failover to the next available member. First thing to check in such cases is that the Exchange Server databases and server have ample storage. The other thing is to trace back any changes which were done before this happened for example server, hardware, network, antivirus changes or patches during that period. In a case the issue was that the admins have installed Microsoft .Net Framework 4.6 which is not supported in Exchange Server 2013. To solve the issue was to remove the .Net Framework in question. This is a simple solution to the problem thou if in one?s case this is not the issue, it could be that the database has been corrupted with either a job or a task which is hogging your Exchange Server resources like a bad hard drive in your RAID pack or a third party software which accesses the database file. Unfortunately this could corrupt your database or mailbox which could be the cause of the database being dismounted. If you would have other databases in your Exchange Server and these are not affected, then it mostly be due to corruption.
In such cases it would be ideal to create a new database and move the mailboxes to this new database, but if the database would dismount at any time, it will stop the migrations consume a lot of time and resources apart from users unable to access their mailboxes. Even if you manually export it PST files using the New-MailboxExportRequest PowerShell cmdlet you will end up in the same situation. In such cases and more, Stellar Repair for Exchange is the ideal application to get your Exchange running in no time. With Stellar Repair for Exchange, you will be able to open a corrupted database, export to PST and other formats along with exploring the EDB file in an Outlook like interface.
In this case you can create the new database in Exchange and export the mailboxes in your corrupted EDB file directly to the new live Exchange database without dismounting it and the users can continue working.
