A great read on common Outlook calendaring issue troubleshooting and data gathering has been recently published:
This is a huge article, suggesting many standard requirements from a data and informational perspective. As I reviewed the article, I saw a couple of points I would suggest changing or ammending:
“A missing or corrupted meeting often cannot be recovered. You might try to delete and re-create the meeting”
Deleting a meeting is a tough step for many users to take. Before deletion, you may want to try to:
– Back the meeting up, via either exporting the meeting using drag and drop to your desktop, or by using a low level editor like MFCMAPI (www.codeplex.com/MFCMAPI) or Outlook Spy (www.dimastr.com). Note that neither of these are Microsoft supported products (you can’t get hot fixes from Microsoft for them), but the authors of each do take feature/fix requests.
– Put an end date on a corrupt meeting item instead of deletion. This way you can get to any attachments you have made to the meeting using the aforemention MAPI editors. Create a new meeting with the starting point where you ended the old meeting.
“Without all the data requested, the support engineer will not be able to definitively determine why there is a problem with the meeting item.
Even with all the data requested, we may not be able to find a root cause of what in the meeting is corrupt. Outlook doesn’t have any kind of back-end database that keeps a record of changes or other referential mechanisim Once a property is stamped with a value, it is stamped. Period. While Outlook logging, Exchange logging, or third-party logging MAY catch the bad property being stamped, none of these solutions monitor EVERY property of every calendar item that gets stamped. Even on a simple meeting with a subject, body and no recurrences, attachments or other attendees, there are about 80 to 90 properties:
There are other requirements in the article for things like Exchange Store tracing, third-party tracing and Outlook tracing (Tools > Options > Other > Advanced > Check the box for Outlook logging and restart), and process monitor as well! Each of these data collection pieces use lots of resources, so you will need to do a couple of things as an administrator:
– Use the logging steps in a test enviornment before putting them on a prodcution machine. Perf by some of these tools can push a given box over the edge, so don’t be that guy that doesn’t test!!!
– Make sure that you have a feeling for how much disk space the logs are consuming per unit of time. If for example, you are engaging Outlook logging on a client machine with an 80 GB drive, and 20 gigs of that is free when you start testing, run the test for 10 minutes. Figure out how much disk you are filling per hour! Say you collected 1 gig of data in 10 minutes. You do the math and figure out that this is 6 GB per hour consumed by the logging. This means you can log safely for three hours before needing to pull the logs off the machine. You can perform the move manually, or script it, but you don’t want to fill up that drive in hour four by not moving the data out!!!! If you let this happen, you have a bigger issue than you started with!!!
Finally, realize that the resolution of any given problem may not be the one that you initially sought. Resolution may take various forms: working around the issue by taking steps to avoid it, or reseolution may be to restore a backup, or it may be a code change request, or it may be a logging of the issue internally with Microsoft for future review. Calendaring issues are complex, and they often require many hours to research, dig, prod, poke and postulate just to get to the point of “I don’t know what is causing this”. Be patient on calendar issues, and be observant. Finally, remember you are working the problem with a serious group of Microsoft Engineers who will do everything possible to get you to an acceptable resolution!
Quote for this blog: Outlook Good! – Magic Eight Ball