The irritation of mailbox database pings and event 6002

Once more we plunge into the badlands of Exchange to investigate silly things that shouldn't be happening. This time it's the case of Event 6002, many of which you'll probably find cluttering up the application event log on your Exchange 2013 servers, mostly because Exchange keeps on recording these events for no good reason. It's a pain. The event conveys no useful information and there doesn't seem to be much of a reason for its presence. The developers need to suppress it or fix the event so it does something useful.

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.

  • A ping of a database was performed, presumably to determine that the database was online.
  • The database is identified by a GUID, much beloved of Exchange developers and computers but a mystery to humans until resolved by running the EMS command shown below, after which we know that the database in question is DB1.
Get-MailboxDatabase | Format-List Name, Guid –AutoSize

Name Guid                              
---- ----                                
DB2  79c03cca-9b53-4959-982a-8773591c5f70
VIP  79f3c611-4b4a-472c-bd9e-2cf207b179d1
DB3  329cb440-7fa8-4d01-be09-29879ad488d0
DB1  4a7d814c-8029-4575-b9f8-5acb80853d2a
DB5  a028a310-f739-4bb3-8f0f-fcb98e1efbc3
  • The ping failed after 00:00:00 minutes. Sounds like an immediate failure, which is curious because the database was online at the time Exchange logged the event.
  • The last successful check was at exactly the same time as the event was logged.

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

Please or Register to post comments.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×