Mailboxes on a database are Quarantined in an environment with System Center Operations Manager

Update 07/03/2012: Expanded the Workaround section to include more details.

We wanted to bring to your attention an issue that we have been seeing recently in CSS where many mailboxes on the same mailbox database become quarantined seemingly for no reason. Upon inspecting the Application log, you will see many 10018 events with text containing to the following information.

Log Name: Application
Source: MSExchangeIS
Event ID: 10018
Task Category: General
Level: Error
The mailbox for user <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.

Additionally, the following event ID 5410 will appear in the Microsoft-Exchange-Troubleshooters/Operational event log for each mailbox quarantined by the database space troubleshooter:

Log Name: Microsoft-Exchange-Troubleshooters/Operational
Source: Database Space
Event ID: 5410
Level: Warning
Keywords: Classic
The database space troubleshooter quarantined mailbox <guid> in database <DBName>.

The key here is the last sentence. “The database space troubleshooter”. In environments where System Center Operations Manager has been deployed, a Monitor is in place by default to check free disk space for database and log volumes. This monitor uses the PowerShell script Troubleshoot-DatabaseSpace.ps1, which ships with Exchange 2010 by default. To read more about the Troubleshoot-DatabaseSpace.ps1 script, refer to the following TechNet article:

Manage Database Log Growth by Using the Troubleshoot-DatabaseSpace.ps1 Script in the Shell

The System Center team recently released Service Pack 2 for the Exchange Management Pack. Among other things, this adjusted a timeout value for running the script. Prior to the Service Pack, the timeout value was 300 seconds, and the monitor was set to fire every 5 minutes. This meant that in many large organizations, the script was virtually guaranteed to timeout, causing it to not complete. After installing the upgrade, the new timeout value is 1200 seconds. In addition, the monitor now runs once per hour instead of every 5 minutes. The effects of this change are that the troubleshooter is now reliably executing code that it previously did not execute prior to the SP2 update. This has caused the troubleshooter to find a bug in the Information Store perfmon counter used by the troubleshooter to determine rate of log byte generation for the database (the perfmon rate can exceed 1.0E+19 Bytes/Hr). When the estimated hourly rate of log generation exceeds the capacity of remaining free disk space on database or log volume, the troubleshooter begins to quarantine mailboxes to stop log generation from consuming all free space and causing the database to dismount. The troubleshooter appears to hit this condition when the perfmon counter has a bogus value (the perfmon counter is updated once per minute and should not have a bogus value for more than 1 min)… so it doesn’t occur frequently but does occur with moderate probability.

What does this mean for you?

Well, as documented in the TechNet article, the main function of the script is to keep track of the log generation rate, and to check free disk space for the database and log volumes. When the script runs, it uses a store perfmon counter to determine the rate of log generation, and calculates whether the current rate will cause the disk to run out of space within the threshold of hours (default is 12 hours), and if so, it will optionally start quarantining mailboxes (up to 150 at a time). The script will then also optionally quarantine mailboxes when the percentage of free disk space goes below a specified value. The default free disk space percentage value used is 25%. In order to quarantine mailboxes when either of these conditions are met, the –Quarantine parameter must be passed to the script.

The monitor utilized by SCOM 2007 and higher uses the Quarantine parameter by default, and there is no option supported option to change this because the Management Pack is sealed. This means that if the free disk space for either the database or log volume for a database goes below 25%, AND if the log generation rate is calculated to consume remaining disk space within the next 12 hours, the heaviest users will be quarantined. When there are many mailboxes on a database, this can mean many mailboxes can be quarantined in a short period of time.

What can you do?

Obviously, having many mailboxes quarantined is not a desired behavior, as it causes outages for those users, though it is still better than the alternative of having the entire database dismount due to lack of disk space, which will cause an outage for all users on that database. Although quarantined mailboxes can be manually released by removing that mailbox GUID from the registry, this is not an optimal solution, as the next time the monitor runs, the same mailboxes may end up being placed into quarantine again.

Quarantined mailboxes are identified in the following location:

Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {Mailbox GUID}

We want you to know that we are aware of this situation and are working to implement a fix. While we work to identify the best way to solve this going forward, we want to let you know of a workaround that can be implemented to prevent mailboxes from being quarantined. In the meantime, to help prevent more customers running into this problem, we have temporarily removed the Exchange 2010 SP2 Management Pack from the Download Center.


Create an override to disable the monitors that check the free disk space. This will prevent the Troubleshoot-DatabaseSpace.ps1 file from being run at all.

When creating overrides, it is best practice to place them into a new management pack specifically for customizations within System Center Operations Manager. This allows you to quickly and easily manage your overrides or other custom settings. If you do not already have a management pack for this, you can create one by following the steps below:

  1. In the Operations Console, click the Administration button. In the Administration pane, right-click Management Packs and then click Create Management Pack. The Create a Management Pack wizard displays.
  2. In the General Properties page, type a name for the management pack in Name, the correct version number in Version, and a short description in Description. Click Next and then Create.


Once you have designated a management pack for the overrides, you will want to create them for the 4 monitors listed here:


In System Center Operations Manager, go to the Authoring module, and then Monitors under Management Pack Objects. The monitors can be disabled by setting an Override and choosing to disable the Monitor for all objects of class Database Copy DB Logical Disk Space (as shown below):


Check the box next to Enabled, and then modify the override value by selecting False:


On the same Override dialog Properties box, be sure to select the management pack designated for customizations.


At this time, we feel that if you are being impacted by mailboxes being quarantined, the option to disable the Monitors is the only available workaround. We recognize that this will potentially prevent administrators from receiving alerts when disk space is low, but feel this is the best option to prevent mailboxes from being quarantined until a fix is released.

Note that when Database disk space is low, an alert will still be received when the transaction log drive coexists with database since this is generated by a different rule that is purely perfmon based.

Ben Winzenz, Kevin Carker

Comments (19)
  1. Dan Sheehan says:

    First – thank you for the heads up and for pulling the service pack 2 version of the Exchange 2010 Management Pack.

    Second – we were never aware that the System Center team had released SP2 of this management pack. Can you all cross post major releases of Exchange pieces from other teams in the future?

    Third – thankfully the System Center team addressed that very annoying 300 second timeout that causes SCOM warnings on all of our DAG nodes all day every day.

    We will be glad when this issue is resolved and the SP2 version of this management pack is re-released.

  2. Nalin Bhasker says:

    why not to just modify the script like below and replicate to all server by running the script to replace the script "Troubleshoot-DatabaseSpace.ps1"

    Like belwo :

    write-verbose ("Mailbox Quarantining but will not happen " + $topLogGenerators[$iNextUserToQuarantine].MailboxGuid)

                   # Set-QuarantineMailbox $topLogGenerators[$iNextUserToQuarantine].MailboxGuid

    i have done this change in My comapany.

    It will let me know if a mailbox needs to be quarantine and will decide by myself. It will help me in maintaining the SCOM and monitoring without of risk of running out of space.

    Hope this will help other.


  3. VincentK says:


    Since this version is pulled can anyone tell me where the "old" version can be downloaded? It can't be found on PinPoint anymore and any link on the technet article or other website is forwarded to a non-functional download location. Due to project deadlines I'm unable to wait for a new version to be released, especially since no eta is given.

    Thanks in advance,


  4. PatRick says:


    Does anyone have any idea when the management pack is going to be re-released?



  5. TimothyL says:

    I am also waiting for the newer version.

    But luckily I got an older version 14.2.x.x, How can I give you VincentK?

  6. VincentK says:

    @TimothyL . Thank you for the offer but company policies prevents me from getting this download from any unsecure and/or unidentified source. I still got to find some time to call MS Support and ask them for the old version or hope that the new version is available for download with in a few days…..

  7. I found that the "KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1" monitor is targeted to "Information store" class.

    You need to override this monitor for all objects of class "Information store"

    Only then the script will not run on exchange mailbox servers.

  8. Any update on the Exchange 2010 MP SP2?

    It's been 2 weeks since there has been an update and we were hoping the SP2 version of the MP would be re-released by now since the issue with it seemed to be a single bug.

  9. Nathan Campbell (Ohio) says:

    We were testing SCOM 2007 and Exchange 2010 SP1 against an Exchange 2010 environment running SP2 for several months without issues.

    We have migrating our testing to SCOM 2012.  Can the Exchange 2010 SP1 management pack be used in a SCOM 2012 environment?  We got use to the great information coming out of our testing in SCOM 2007, but now that I migrated everything to SCOM 2012 I am not sure what to do about this Exchange management pack situation – I would really like to get some Exchange alerting going for testing.

  10. BENNY says:

    love the way you ass munchers filter comments…y'all suck

  11. Robert says:

    Please can we have an update on the SP2 fixed re-release as with other I really need to get some Exchange 2010 monitoring in test :¬(

  12. Blake Mengotto says:

    I have the older MP and have been emailing it to those who have asked for it.  It is the pre SP2 release the MSFT pulled.  Get it from my skydrive if you want it.…/pre-sp2-exchange-2010-management-pack

  13. Dan Sheehan says:

    Exchange Team/SCOM Team,

    It's coming up on a month now with no update on the potential release date of the Exchange 2010 Management Pack SP2.

    Can you please just let us know what's going on and any expected ETA?


  14. Joe Clarke says:

    Thanks Blake, just grabbed it.

    Dittos for Dan…any ETA? Thanks all

  15. If anyone has the pulled version somewhere I would greatly appreciate getting my hands on it. There are several workarounds and none of them are especially hard to implement.

  16. Nick Cottrell says:

    Also seeking the pulled version.  I have a client with Exchange 2010 SP2 in production and no SCOM MP.  

  17. Blake Mengotto says:

    The new MP seem's to have been changed so much so that it causes a break the ability to upgrade.  This means you will have to remove the old MP and any dependent MP's (custom/override) then do the install.  Be aware of this.

  18. Marc Bogadi says:

    New version 14.03.0038.004 is back online…/details.aspx

Comments are closed.