Exchange 2010 SP1 added a new script called Troubleshoot-DatabaseSpace.ps1 that is used to detect excessive growth of database and log drive volumes. This script can be run manually by administrators but if you have Microsoft System Center Operations Manager (SCOM) 2007 it is run automatically every 15 minutes.
This script performs the following actions:
1. Track log generation rate for the highest log generators (mailboxes) per database. This helps determine which users are logging too heavily and potentially causing space issues;
2. Track available disk space for both database and log files. If either of these is within a configurable threshold of being full (25% by default), further action must is taken;
3. Track log generation rate. If it appears that the disk is going to run out of space within the value specified by the HourThreshold parameter (12 hours by default and based on the log generation rate), further action is taken;
4. If all of the above conditions are fulfilled, the script determines the list of top 25 users who accessed the database during the last 1 hour period. The script then quarantines the top high-usage mailboxes for 6 hours, during which they will not have access to e-mail;
5. If the troubleshooter is unsuccessful at dropping the log generation rate to below the threshold level, it will write out events that translate into health model alerts. At this point, the script removes the database from provisioning by running the Set-MailboxDatabase cmdlet with the ExcludeFromProvisioning parameter set to $True against the specified database;
When mailboxes are quarantined, you will see entries in the Registry of the mailbox server hosting that database/mailbox in:
To check the events logged by this script go to the mailbox server you want to check and then Event Viewer -> Application and Services Logs -> Microsoft-Exchange-Troubleshooters/Operational. Note that if you run the script manually through the Shell it will not produce any output - you have to check the Event Viewer.
If you run the script manually without any parameters or if you have SCOM running this script automatically, then it will use default values specified in the StoreTSConstants.ps1 script located in the same folder. This is where you can customize the 25% threshold, for example, if it is not ideal for your environment:
# The percentage of disk space for the EDB file at which we should start quarantining users.
$PercentEdbFreeSpaceDefaultThreshold = 25
# The percentage of disk space for the logs at which we should start quarantining users.
$PercentLogFreeSpaceDefaultThreshold = 25
# The percentage of disk space for the EDB file at which we are at alert levels.
$PercentEdbFreeSpaceAlertThreshold = 16
# The percentage of disk space for the EDB file at which we are at critical levels.
$PercentEdbFreeSpaceCriticalThreshold = 8
#The number of hours we can wait before running out of space.
$HourDefaultThreshold = 12
In order for mailboxes to be quarantined, the –Quarantine parameter must be passed to the script, which the SCOM monitor uses by default. Because the Exchange Management Pack is sealed, you can’t change this...
So, if 25% is too high for your environment, you can change the value by updating the StoreTSConstants.ps1 script across all your mailbox servers or, ultimately, simply disable the SCOM monitors that run this script:
• KHI: Failed to execute Troubleshoot-DatabaseSpace.ps1
• KHI:The database copy is low on database volume space and continues to grow. The volume has reached critical levels 8% free.
• KHI:The database copy is low on database volume space and continues to grow. The volume has reached error levels under 16% free.
• KHI:The database copy is low on database volume space and continues to grow. The volume is under 25% free.