Outlook Calendar issue troubleshooting steps published to TechNet

Scott Fellman — Sun, 31 Aug 2008 08:31:00 GMT

A great read on common Outlook calendaring issue troubleshooting and data gathering has been recently published:

http://technet.microsoft.com/en-us/library/cc891495.aspx

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

Issue - Programmatically posting WSS 2007 Discussion List Items shows sender as "System Account" in Outlook 2007

Scott Fellman — Tue, 18 Dec 2007 06:35:00 GMT

I have been working through some hardware issues so Part two of my SPSreport blog continues to hold , but I wanted to take a few minutes to share some findings from a recent case with you.

In this case, our customer is a programmer who sent in some code wherein he was programmatically setting the Email Sender and From field in WSS Discussion list items using OM code like this:

SPListItem discussion = SPUtility.CreateNewDiscussion(list.Items, "subject");

discussion[SPBuiltInFieldId.Body] = "body";

discussion[SPBuiltInFieldId.Categories] = "category";

discussion[SPBuiltInFieldId.EmailSender] = "SenderEmail@email.com";

discussion[SPBuiltInFieldId.MessageId] = "Server Internet Message ID";

As most of you know, I describe myself as a "code toddler"; I can read some code, I can write "Hello World" in a couple of languages. So I didn't know if I would be able to help our customer… but I knew I needed to try to do so. And I can understand that the code above should be setting values on specific columns and fields for a Discussion Board item. So off we went!

The above code shows the proper person, as pushed from the OM into each of the appropriate custom columns in WSS's UI. But from the other side of this issue, after a sync to Outlook the From column is the Creator of the post as shown in the Outlook UI, i.e., the person that ran the code in SharePoint. In our case, this was the system account.

In my initial research, I found a couple of OOB reasons why we might see the System Account as the sender. First, of course, is if the Creator of the post is the system account (never discount the obvious!). Second, if you see content in the document library that is assigned to the system account, it sometimes means that the document library has treated the incoming mail as an anonymous user due to the inability to resolve the name in the list of users with rights to submit mail to the list. To check to see if this was the cause of our issue, we checked to see if the library was set to accept mail from all senders. You check this from WSS by browsing to the Discussion list, then choosing Settings > Discussion Board settings > Incoming Email Settings (and then navigate to the bottom of the page). Neither of these was the case when we checked them…

To reset: the code makes the "poster" looks good on the Discussion Board list item, but on the sync to Outlook, the From field is changed to the WSS System Account. Nothing left to do but break out the troubleshooting tools! For this issue, my weapons of choice were netmon, Outlook Spy and source code for SharePoint and Outlook (sorry, no links for these :)).

I set up an OOB Discussion list (modified the theme, thus the difference in color), added a column (blue), started netmon and performed an Action > Sync to Outlook from the list.

In reviewing the netmon of the trace, I see two properties in the

In reviewing the netmon of the trace, I see two properties in the XML going across the wire; these are ows_author and ows_editor:

0000 00 08 74 15 39 b5 00 07 b3 0f 59 ca 08 00 45 00 ..t.9.....Y...E.

0010 03 80 77 26 40 00 37 32 84 9e 9d 36 1a 25 41 35 ..w&@.72...6.%A5

0020 4b f7 f7 9c 09 4a 00 00 00 8a 00 50 11 b0 4d d7 K....J.....P..M.

0030 80 23 a2 25 e3 b8 50 18 ff e9 d2 4f 00 00 33 34 .#.%..P....O..34

0040 45 43 44 38 38 38 33 33 32 36 33 42 38 38 43 39 ECD88833263B88C9

0050 43 34 42 26 67 74 3b 26 6c 74 3b 64 69 76 26 67 C4B><div&g

0060 74 3b 26 6c 74 3b 2f 64 69 76 26 67 74 3b 26 6c t;</div>&l

0070 74 3b 2f 64 69 76 26 67 74 3b 27 20 6f 77 73 5f t;/div>' ows_

0080 54 68 72 65 61 64 49 6e 64 65 78 3d 27 30 78 30 ThreadIndex='0x0

0090 31 43 39 45 46 30 35 34 31 43 41 46 34 45 37 35 1C9EF0541CAF4E75

00a0 30 38 33 32 32 45 31 34 37 45 43 42 30 44 38 44 08322E147ECB0D8D

00b0 41 36 34 45 34 43 35 36 39 34 43 27 20 6f 77 73 A64E4C5694C' ows

00c0 5f 41 75 74 68 6f 72 3d 27 31 3b 23 53 63 6f 74 _Author='1;#Scot

00d0 74 20 46 65 6c 6c 6d 61 6e 20 28 53 45 4b 49 57 t Fellman (SEKIW

00e0 41 4b 45 29 2c 23 4e 4f 52 54 48 41 4d 45 52 49 AKE),#NORTHAMERI

00f0 43 41 5c 73 66 65 6c 6c 6d 61 6e 2c 23 73 66 65 CA\sfellman,#sfe

0100 6c 6c 6d 61 6e 40 6d 69 63 72 6f 73 6f 66 74 2e llman@microsoft.

0110 63 6f 6d 2c 23 73 66 65 6c 6c 6d 61 6e 40 6d 69 com,#sfellman@mi

0120 63 72 6f 73 6f 66 74 2e 63 6f 6d 2c 23 53 63 6f crosoft.com,#Sco

0130 74 74 20 46 65 6c 6c 6d 61 6e 20 28 53 45 4b 49 tt Fellman (SEKI

0140 57 41 4b 45 29 27 20 6f 77 73 5f 45 64 69 74 6f WAKE)' ows_Edito

0150 72 3d 27 31 3b 23 53 63 6f 74 74 20 46 65 6c 6c r='1;#Scott Fell

0160 6d 61 6e 20 28 53 45 4b 49 57 41 4b 45 29 2c 23 man (SEKIWAKE),#

0170 4e 4f 52 54 48 41 4d 45 52 49 43 41 5c 73 66 65 NORTHAMERICA\sfe

0180 6c 6c 6d 61 6e 2c 23 73 66 65 6c 6c 6d 61 6e 40 llman,#sfellman@

0190 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 2c 23 73 microsoft.com,#s

01a0 66 65 6c 6c 6d 61 6e 40 6d 69 63 72 6f 73 6f 66 fellman@microsof

01b0 74 2e 63 6f 6d 2c 23 53 63 6f 74 74 20 46 65 6c t.com,#Scott Fel

01c0 6c 6d 61 6e 20 28 53 45 4b 49 57 41 4b 45 29 27 lman (SEKIWAKE)'

01d0 20 6f 77 73 5f 50 65 72 6d 4d 61 73 6b 3d 27 30 ows_PermMask='0

01e0 78 37 66 66 66 66 66 66 66 66 66 66 66 66 66 66 x7ffffffffffffff

01f0 66 27 20 6f 77 73 5f 5f 4d 6f 64 65 72 61 74 69 f' ows__Moderati

0200 6f 6e 53 74 61 74 75 73 3d 27 30 27 20 6f 77 73 onStatus='0' ows

0210 5f 5f 4c 65 76 65 6c 3d 27 31 27 20 6f 77 73 5f __Level='1' ows_

0220 55 6e 69 71 75 65 49 64 3d 27 33 3b 23 7b 37 45 UniqueId='3;#{7E

0230 41 34 43 38 41 44 2d 42 33 33 31 2d 34 36 44 46 A4C8AD-B331-46DF

0240 2d 41 33 37 38 2d 42 37 35 36 46 31 34 41 38 35 -A378-B756F14A85

0250 38 38 7d 27 20 6f 77 73 5f 46 53 4f 62 6a 54 79 88}' ows_FSObjTy

0260 70 65 3d 27 33 3b 23 31 27 20 6f 77 73 5f 46 69 pe='3;#1' ows_Fi

0270 6c 65 52 65 66 3d 27 33 3b 23 73 69 74 65 73 2f leRef='3;#sites/

0280 73 66 65 6c 6c 6d 61 6e 2f 4c 69 73 74 73 2f 44 sfellman/Lists/D

0290 61 6c 6c 61 73 20 43 6f 77 62 6f 79 73 20 44 69 allas Cowboys Di

02a0 73 63 75 73 73 69 6f 6e 2f 52 6f 6d 6f 20 72 6f scussion/Romo ro

02b0 63 6b 73 21 27 20 6f 77 73 5f 4d 65 74 61 49 6e cks!' ows_MetaIn

02c0 66 6f 5f 76 74 69 5f 76 65 72 73 69 6f 6e 68 69 fo_vti_versionhi

02d0 73 74 6f 72 79 3d 27 62 66 65 32 66 37 36 34 66 story='bfe2f764f

02e0 63 37 65 34 36 31 36 61 61 34 66 31 35 38 36 33 c7e4616aa4f15863

02f0 37 31 35 38 61 34 63 3a 31 27 20 2f 3e 0d 0a 3c 7158a4c:1' />..<

0300 2f 72 73 3a 64 61 74 61 3e 0d 0a 3c 2f 6c 69 73 /rs:data>..</lis

0310 74 69 74 65 6d 73 3e 3c 2f 47 65 74 4c 69 73 74 titems></GetList

0320 49 74 65 6d 43 68 61 6e 67 65 73 53 69 6e 63 65 ItemChangesSince

0330 54 6f 6b 65 6e 52 65 73 75 6c 74 3e 3c 2f 47 65 TokenResult></Ge

0340 74 4c 69 73 74 49 74 65 6d 43 68 61 6e 67 65 73 tListItemChanges

0350 53 69 6e 63 65 54 6f 6b 65 6e 52 65 73 70 6f 6e SinceTokenRespon

0360 73 65 3e 3c 2f 73 6f 61 70 3a 42 6f 64 79 3e 3c se></soap:Body><

0370 2f 73 6f 61 70 3a 45 6e 76 65 6c 6f 70 65 3e 01 /soap:Envelope>.

0380 01 06 78 2a 58 47 c6 34 92 6d f3 44 90 69 ..x*XG.4.m.D.i

When I look at the same message as rendered in Outlook, and specifically the MAPI properties, with Outlooks Spy, I see this:

In all, I see 4 MAPI properties with my name on them. I then went to a source search on each term. Ows_editor yielded one hit in Outlook source; he is responsible for conversion of the incoming ows_editor parameter. The conversion goes to the MAPI properties of PR_LAST_MODIFIER_NAME and PR_SENT_REPRESENTING_NAME; this is hard-coded. Searching source for ows_author yields that "Created By" in WSS maps to PR_ORIGINAL_AUTHOR_NAME_W. This is exactly confirmed by the Outlook Spy results above. So these are hard coded and cannot be modified simply by stamping a WSS property on them programmatically.

I then went through that same set of steps after adding a column called blue. When I viewed the trace, there was no ows_ property associated with the column that would be translatable by Outlook. So again, another thought, and another dead end.

Then my customer asked a question - "How do I add users to SharePoint that aren't in my domain". Having worked with contact lists in SharePoint, I knew that this is very simple; you just need to add a contact name and email address; there is no requirement from SharePoint that your contact be from your domain! And yes, from other work with our STSADM command line Administrative tool, I also knew that SharePoint will also recognize a local account of the SharePoint box as a valid user as well. This last piece of information is just what my customer needed.

With this piece of information, he wrote the code in WindowsAccount.cs, tied that in with WSSAccount.cs, and boom! A solution is now in place that is allowing him to use SharePoint and Outlook interoperability to programmatically list SharePoint posts and have them sync to Outlook as he wishes. This is a fantastic example of a code toddler like myself using wide product knowledge in the Microsoft Office Family and troubleshooting tools to help an experienced programmer build a custom business solution. Everyone wins when this kind of synergy happens!

Sample code attached with customer's permission! He reviewed ths blog before publishing as well; his desire here is that someone else might benefit from our work. All typical disclaimers apply, the code is not supported by Microsoft, nor myself - use at your own risk/benefit, etc...

Have a safe and happy holiday!

Scott

Outlook without religion is lame : Outlook Spy

Outlook Calendar issue troubleshooting steps published to TechNet

Issue - Programmatically posting WSS 2007 Discussion List Items shows sender as "System Account" in Outlook 2007