The irritation of mailbox database pings and event 6002

Continuing a campaign to rid Exchange of annoying and silly details (like the error message discussed recently), my next target is event 6002, which is logged on an ongoing and continuous basis by “MS Exchange Mid-Tier Storage” (whatever that is).

Generally speaking, event logging is goodness because it reveals a lot of interesting and valuable information about what happens under the covers of an application or system component. The problem here is not that information is being recorded. Rather, it’s the constant stream of useless events that clutter up the log and deliver exactly zero value to an administrator.

Take the screen shot above as an example of one of the 12,500 similar 6002 events logged on a small test Exchange 2013 mufti-role server that supports five mounted databases (to illustrate the quantity of the captured events, a production server logged 45,000 such events from Friday to Monday). We’re told that:

This is a warning event, so we need to be careful.

Get-MailboxDatabase | Format-List Name, Guid –AutoSizeName Guid                ---- ----                DB2  79c03cca-9b53-4959-982a-8773591c5f70VIP  79f3c611-4b4a-472c-bd9e-2cf207b179d1DB3  329cb440-7fa8-4d01-be09-29879ad488d0DB1  4a7d814c-8029-4575-b9f8-5acb80853d2aDB5  a028a310-f739-4bb3-8f0f-fcb98e1efbc3

So, the event tells the curious administrator that a ping took zero seconds against a database that was online and was last successfully verified at the same time as the unsuccessful ping. This sounds very much like Managed Availability, for this is the component that appears to be responsible for the check (the clue is that the task category is “ResourceHealth”), is getting its proverbial knickers in a knot and has disappeared up its rear end. Either that or some bizarre logic exists to justify annoying people with extraneous events that add zero value.

Going through 12,500 events would be a wearisome process and not one that I think I would like, so I didn’t analyze every single logged event to detect patterns that might lead to the root cause. What I can say is that events appear to be logged every fifteen minutes or so and that not every mounted database is pinged unsuccessfully to cause an event to be logged. Events were logged for every database on the server but fewer events appear to be logged for replicated databases than for those where copies don’t exist. This might be a quirk of the server, which is a member of a DAG but doesn’t replicate every database.

The long and the short of the situation is that warning events are logged that are useless. And like the boy who cried wolf, the existence of useless events is bad because they might hide a serious underlying situation. I have no idea why an Exchange developer decided that it was a good idea to generate 6002 events. Perhaps it was the result of a bad Monday morning in Redmond after an excellent previous weekend. We shall never know.

This problem has existed since Exchange 2013 was released. I had hoped that it would have been fixed in Exchange 2013 SP1 but that didn’t happen. It would be really nice if the next cumulative update included code to suppress the unwanted 6002 events or fix whatever routine generates the unwanted events. Only warn when necessary – isn’t that the way it should be?

Follow Tony @12Knocksinna