Problem with Custom message store for Outlook 2013

Question

Outlook 2013 failed to display content from our custom MAPI message store in content view

Operating system: window 7 32 bit and 64 bits

Application: Outlook 2013

Custom Integration: custom MAPI message store

Description of the problem:

We have a custom message store already integrated with all previous Outlook versions including Outlook 2010, 2007 and 2003. But when we tried our message store with Outlook 2013, the nodes from our message store can be shown in Outlook folder view (left hand pane) without problem. But whenever one of our node is selected, Outlook failed to display the content in content pane (right hand pane). The information displayed in the content view:

“Cannot display the folder. Microsoft Outlook cannot access the specified folder location. The information store could not be opened.”

Or

“Cannot display the folder. Microsoft Outlook cannot access the specified folder location. Out of memory or system resources. Close some windows or programs and try again.”

Or sometimes Outlook just crash.

We have debugged into our message store code to see what is going on there, but could not figure out what were wrong there.

When our node is selected, we see Outlook calls our CMsgStore::OpenEntry() on the selected folder ,

      and then call our CMAPIFolder::GetProps() a few time to retrieve properties as listed below

PR_PARENT_ENTRYID                   

PR_ACCESS                        

PR_ACCESS_LEVEL                         

PR_RECORD_KEY                            

PR_STORE_RECORD_KEY             

PR_MAPPING_SIGNATURE        

PR_DISPLAY_NAME                       

PR_FOLDER_TYPE           

PR_CONTENT_COUNT

PR_CONTENT_UNREAD                               

PR_SUBFOLDERS             

PR_STORE_SUPPORT_MASK     

PR_CONTAINER_CLASS                

PR_DEFAULT_VIEW_ENTRYID

, and a bunch of other properties, which our message store does not understand or support and return  PT_ERROR for.

In normal case, Outlook should try open Content table from the selected folder. However in Outlook 2013 environment, Outlook calls Unadvise() on our message store right after querying properties of the folder, which is abnormal.

We just wonder what were wrong on our message store side, or what specific properties are missing from our message store in Outlook 2013 environment.

Is there any new added requirements for message store implementation or known issues for Outlook 2013? What is the best course of action for figuring out this type of issues.

Thanks

jhou

Answer 1

What are the other properties that do you do support? Does PST provider return them?

---

Dmitry Streblechenko (MVP)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.4 is now available!

Answer 2

Thanks for your reply.

Follows are the tags we do not know and return error:

Tag: UNKNOWN (0x6670)  Type: PT_BINARY
Tag: UNKNOWN (0x10f4)  Type: PT_BOOLEAN
 Tag: UNKNOWN (0x36da)  Type: PT_BINARY
 Tag: UNKNOWN (0x36de)  Type: PT_LONG
Tag: UNKNOWN (0x672d)  Type: PT_LONG
 Tag: UNKNOWN (0x6853)  Type: PT_LONG
Tag: UNKNOWN (0x6731)  Type: PT_LONG
 Tag: UNKNOWN (0x6730)  Type: PT_I8
 Tag: UNKNOWN (0x6732)  Type: PT_UNICODE
Tag: UNKNOWN (0x6733)  Type: PT_UNICODE
Tag: UNKNOWN (0x3020)  Type: PT_BINARY
Tag: UNKNOWN (0x3021)  Type: PT_BINARY

Those are the properties queried about a folder. My impression is that we could not see the source code at MAPIFolder level in the sample PST message store. I will check into that.

Thanks again.

jhou 

Answer 3

Do you use the same muid for all entry ids in your store?

The properties are 

Tag: UNKNOWN (0x6670)  Type: PT_BINARY - PR_LONGTERM_ENTRYID_FROM_TABLE
Tag: UNKNOWN (0x10f4) Type: PT_BOOLEAN - PR_ATTR_HIDDEN
Tag: UNKNOWN (0x36da)  Type: PT_BINARY - PR_EXTENDED_FOLDER_FLAGS
Tag: UNKNOWN (0x36de)  Type: PT_LONG - PR_NET_FOLDER_FLAGS
Tag: UNKNOWN (0x672d)  Type: PT_LONG - PR_MANAGED_FOLDER_INFORMATION
Tag: UNKNOWN (0x6853)  Type: PT_LONG - PR_WLINK_CALENDAR_COLOR
Tag: UNKNOWN (0x6731)  Type: PT_LONG - PR_MANAGED_FOLDER_STORAGE_QUOTA
Tag: UNKNOWN (0x6730)  Type: PT_I8 - PR_MANAGED_FOLDER_SIZE
Tag: UNKNOWN (0x6732) Type: PT_UNICODE - PR_MANAGED_FOLDER_ID
Tag: UNKNOWN (0x6733)  Type: PT_UNICODE - PR_MANAGED_FOLDER_COMMENT
Tag: UNKNOWN (0x3020)  Type: PT_BINARY - ?
Tag: UNKNOWN (0x3021)  Type: PT_BINARY - ?

---

Dmitry Streblechenko (MVP)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.4 is now available!

Answer 4

I believe so, if I understand what muid means. All our entry IDs contain a same provider GUID ID.

Do you think our message store failed to return any mandatory properties for OL2013?

Thanks again for your response.

jhou

Answer 5

Yes, I was thinking that Outlook was trying to call IMAPISession::OpenEntry on an entry id that was not registered with MAPI.

---

Dmitry Streblechenko (MVP)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.4 is now available!

Answer 6

So what are the properties our message store should implement? Where should we intercept the call (IMAPISession::OpenEntry ) in our code to verify the problems?

Thanks for information!

jhou

Answer 7

My theory was that the previous versions of Outlook called IMsgStore::OpenEnttry directly on your store, but Outlook 2013 called IMAPISession::OpenEntry, which could not redirect the call correctly.

I would open a support case with MS if I were you...

---

Dmitry Streblechenko (MVP)
http://www.dimastr.com/redemption Redemption - what the Outlook Object Model should have been Version 5.4 is now available!

Answer 8

Thank you very much for your information. I will open a support case with MS, and post back the result/solution, once it becomes available.

jhou

Answer 9

OK. The problem was as following:

When Outlook queries certain properties which our message store does not support or understand, our message store return error on those properties but omitting the property ID. We should return the property ID along with an error type. This did not cause much problem with OL2010, but matters with OL2013.