Im going to preference all these post by the words “I THINK:”
This means that I believe all this stuff to be technically accurate, but I don’t gurantee it. I could be wrong, or have missed something in my testing. More than anything I want it to come across as a brain dump. So read at your own risk …
Down in the architecture of Outlook, different message types are represented by “objects” that kind of encapsulate everything that is associated with them. Everyone is familiar with task items and contact items, and appointment items for example.
One of the newer item types is the Sharing Item. You will see Sharing Items when you sent or reply to a sharing invitation in Outlook 2007. Sharing items have a message class of IPM.Sharing.
Sharing items at the mapi level contain special properties (named properties in a special propset) that tell outlook about the sharing characteristics (the URL to the sharing provider, a GUID to identify it, etc). So these 10 or 12 custom properties have to be present on a sharing item to “make it work”.
Now an interesting scenario happens if you have an environment where a non MAPI method is used to generate or reply to a sharing item. The non mapi sender would either have to be smart enough to construct a TNEF blob (which encapsulates mapi properties) and store that in the RFC822 message, or it would have do use something other than mapi properties.
The good news is that Outlook 2007 will actually look for and use X-Header information for all these needed properties. So if a message arrives that does NOT have the needed mapi properties, outlook will look in the PR_TRANSPORT_MESSAGE_HEADERS prop and parse out any X-header information that is there. If the Sharing props are present, they will be used, and the sharing message will render and behave like you expect. If the mapi props are not there, and the X-header props are not there, Outlook will yield a cryptic “Cannot open this item” dialog, and ask you if that dialog was helpful (I’ll leave it to the reader to decide whether the dialog was helpful).
One common scenario where you might see this is when using MOSS 2007 Alerts. These alerts are sharing items that tell you that something has changed on one of your sharepoint lists. They are sent via SMTP from the server. Unfortunately, if you receive these alerts through Exchange server 2003 and then sync them down to cached mode of Outlook 2007, the sharing message properties do not make it to outlook. The result is that when you try to open the sharing item, you get the error.
This is a known problem and we are currently investigating a fix that will allow the props to survive the trip, and allow the sharing item to work. I’ll post again when/if that fix becomes available.