How to tell the Exchange team to do a better job of documenting an eventID

You may have seen a link in your eventlog that, when you click on it, takes you to a microsoft web site where theoretically there is supposed to be useful information telling you what to do about that specific event, but often there is not.

If this has happened to you enough times that you stopped clicking on the links, hear my plea: Keep clicking! The reason is that we look at the hit count of these web hits to determine the priority of the events we should document in our event lookup (here for E2K, here for E2K3 - both listed on this page).

If the web content doesn't help you troubleshoot the problem, Google and are the Exchange admin's best friend to look up more information.

Also note that for Exchange 2003, there was a big effort to document many more events than we used to, so hopefully the E2K3 event lookup has helped you more than the E2K one did. If you have a specific event that you were looking up that did not have content in the eventid lookup, add a comment here and I'll put together the feedback and send it on to the people who own that site.

Also, I should add that the above isn't the only way we document events. Many events are documented in the KB, and those may come from bugs in our database, customer reports, etc. We could do a better job of synchronizing the content between those two back-end systems though.

Comments (5)

  1. Dave says:

    But surely the point is to simply provide useful information, without waiting to see that 10000 people are suffering from the same problem and then deciding to write something?

    The first person to see an event logged is entitled to the same answer the 10000’th is.

    After all, you seed the event id’s in the code, so they’re all raised because of something! Write a probably or possible reason at the point of allocation!

  2. KC Lemson says:

    Dave: Of course, ideally we’d have every single possible combination of every single error fully documented. But realistically, we have to prioritize our efforts, and we want to spend our resources on where we can get the biggest bang for the buck.

    Also, note that this doesn’t mean we DON’T document events that aren’t commonly hit. There are various other paths where we document things, I will update the entry.

  3. adam says: has been one of my favourite sites for years along with

  4. Andy says:

    would it make sense to have a comment form available for the not-found events so that folks can provide some real world information on what they’re seeing? perhaps that’s better at, but on some events, the situation that causes it may be so obscure that the microsoft authors wouldn’t have thought to document it in the same way as the users would find useful.

    It’s a little surprising that even events that have KB articles don’t show up when clicked, like the 9548 error.

  5. KC Lemson says:

    Andy: Yep, good idea. I’ll send that along to the page owners. One of the complexities is that the template for the web page is the same for all products, so any links/UI changes would need to apply to all, and so there’s a lot of coordination that needs to happen for these kinds of changes.

    And yeah, I definitely agree that not having a link between this content and KB searches is a problem. I don’t think we’ll be able to address this in the short term though.

Skip to main content