Quarantined or poisioned shared mailboxes

Mailboxes will be automatically quarantined for the following reasons:

  • Mailbox threads crashing
  • Stuck threads that have not progressed for an excessively long time.
  • Corrupt data or email causing store to crash or become unresponsive.
  • Corrupt software causing overconsumption of CPU
  • Network failure

Outlook clients (MAPI connections) uses multiple threads, when threads get stuck, freezes, or crashes, it causes the Information Store process to consuming more CPU then necessary to service the threads. Quarantining is performed by a background thread, runs every two hours, and checks number of crashes by mailboxes. If it exceeds the normal range, the mailbox is deemed a threat to the overall stability of the store.

A single mailbox with corrupted data could cause Information Store to crash or become unresponsive. If this happens repeatedly, then that would be considered a poison mailbox. The default behavior of Exchange is to quarantine a mailbox if identified as causing a failure or deadlock three times in a two-hour timespan (abnormal).

When a mailbox is quarantined, EventID 10018 will be logged into the application event log and this can be easily picked up by monitoring tools. 

If a mailbox gets quarantined, you will see the a entry created here: 

  • HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}

The keys CrashCount or LastCrashTime will hold the necessary data but these keys will not be created until the store has crashed at least one time by a mailbox. 

CrashCount: number of times mailbox has crashed a thread within the Store
LastCrashTime: last time that a mailbox thread crashed within the Store

Remediation:

To make it instant without having to restart the services. You can change the “CrashCount” value to “2” and don’t remove the registry. This makes the mailbox work instantly until time is available outside of production hours is available to remove the key. I do not recommend this unless absolutely necessary, as the underlying problem that caused the Store to quarantine has not been addressed.

Exchange 2010:

Delete the mailbox’s GUID entry from under the QuarrantinedMailboxes registry key and restart the Exchange Information Store. 

  1. Identify the MailboxGUID and Database for affect user

Get-MailboxStatistics <username> | ft DisplayName,Database,MailboxGUID –AutoSize

  1. Identify GUID of the mailbox database

Get-MailboxDatabase <MailboxDatabase> | ft Name,Guid –AutoSize

  1. Restart Exchange Information Store:

You can either go through services.msc, or open an elevated command prompt (cmd) and run :
net stop “Microsoft Exchange Information Store”
net start “Microsoft Exchange Information Store”

Additional Information:

Get-MailboxStatistics for a mailbox also has a property to indicate if a mailbox is quarantined.
Get-MailboxStatistics alias | Select DisplayName, IsQuarantined | Format-Table -AutoSize

Use the following command to detect  corruption and repair a mailbox
New-MailboxRepairRequest -Mailbox alias -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,FolderView –Archive User: – detectonly instead of -archive (for detect only)

Check Users Outbox for any large, looping, or stranded messages using the following command, but this does not get information for users that are running in cached mode.
Get-mailbox -ResultSize Unlimited| Get-MailboxFolderStatistics

Use the following command to repair a mailbox database:
New-MailboxRepairRequest -Database $Mailbox.Database1 -StoreMailbox $Mailbox.Mailbox1Guid -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview

 

 

 

 

 

 

 

epic
Author Details
Contributer and Author Enterprise Communications Engineer Hi Epic

testest test 

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments