The case of the erroneous disk space checker

Following on my post about how a glitch in Managed Availability in Exchange 2013 RTM CU2 can cause BSODs in multi-domain configurations, another problem in Exchange’s automated monitoring and reporting systems is causing furrowed brows for administrators. In this instance, it’s the case of the persistent but erroneous disk space check that appears on servers after the installation of Exchange 2013 RTM CU2.

Think of this as the DatabaseDriveSpaceTrigger conundrum. On the on hand it’s good to check that your disks have sufficient space for Exchange to do its stuff, on the other it’s wearisome to be told quite so often that insufficient space exists on a disk that Exchange should not care about because no databases are located on the drive.

For whatever reason, the check generates event 1006 from source MSExchangeDiagnostics in the application event log on mailbox servers. The event text is something like this:

The performance counter '\EXSERVER2LogicalDisk(C:)Free Megabytes' sustained a value of '11,002.00', for the '15' minute(s) interval starting at '28/08/2013 18:12:00'. Additional information: None. Trigger Name:DatabaseDriveSpaceTrigger. Instance:c:

Every disk on the server is monitored by Exchange’s diagnostics service and an event is duly logged even if copious free space is available on the drive or, as noted above, databases are not on the drive. (It is acknowledged that monitoring free space on drive C: is important because of its use as the location for so many system files; indeed, if you install Exchange and take the default options, you'll end up with important files such as the transport database on drive C:).

The solution is to delve into the bowels of the product and use your favorite text editor to open the Microsoft.Exchange.Diagnostics.Service.exe.config configuration file, which is found in Exchange’s bin directory. This file is read in by the Microsoft Exchange Diagnostics service when it initializes to tell it what conditions should be checked in order to keep a server happy and healthy. We need to disable the check that generates the 1006 events, and this is done by searching for DatabaseDriveSpaceTrigger and then changing its enabled status from “True” to “False”.

The edited text is shown below:

Save the file and the restart to Microsoft Exchange Diagnostics service to force it to read in the configuration file and all should be well.

The downside of making changes like this is that Exchange 2013 includes this check for a very good reason. Running of out disk space on a drive that holds mailbox databases is a very bad problem as the Information Store will come to a crashing halt if space is unavailable. Exchange includes ten reserved transaction logs to ensure that in-memory data is preserved but that’s no real comfort if users discover that they cannot send or receive email. Without an automated check running it becomes the responsibility of the administrator to ensure that free disk space is available.

It’s therefore important to revisit the check after Microsoft next updates Exchange. CU3 might overwrite the entire diagnostics configuration file or it might leave it intact. In the former instance the DatabaseDriveSpaceTrigger check will be reactivated. In the latter, it won’t and you might want it to be.

I anticipate that some will point to this problem as yet another example of quality issues within Exchange 2013. I’d call this one an irritation rather than a real issue, but it obviously shouldn’t be there. Then again, no software is perfect and the events are easily suppressed. If only all problems could be dealt with so easily.

Follow Tony @12Knocksinna