We recently had a customer who was copying messages around using CopyTo. They found that for certain messages, if the target message store was a PST, they’d get MAPI_E_NO_ACCESS (0x80070005). They saw this for the same messages every time, when other messages would copy to the same PST just fine.
When I debugged the failure, I found the root of the problem was that the source message had an attachment with the property 0x67100003 set on it. The PST provider does not allow this property to be set on a messages in its store, so any attempt to set it returns the error MAPI_E_NO_ACCESS. When they did the CopyTo of the message properties, because PR_MESSAGE_ATTACHMENTS was not excluded, one of the side effects was that MAPI looped through the the attachments and copied them, using calls to CopyTo at the attachment level. These CopyTo calls did not use an exclusion array at all, so every property on the source attachments were copied to the destination. When CopyTo reached the property 0x67100003, the PST provider returned an error, which caused the attachment level CopyTo to fail, which in turn caused the customer’s CopyTo call to fail.
By the way, 0x67100003 isn't the only property that causes this problem. In fact, most properties in the service provider defined non-transmittable range (0x6600-0x67FF) caused the same problem.
The fix we used was to add PR_MESSAGE_ATTACHMENTS to the exclusion list for CopyTo, then copy the attachments manually using OpenAttach, CreateAttach, and CopyTo, passing an exclusion array specifying that the non-transmittable properties should be excluded. Since this is the same logic CopyTo uses to copy attachments (without the exclusion array), doing the copy like this doesn’t have a performance hit.
It used to be that if you wanted to track a message through various Object Model events such as NewInspector and ItemSend, one way to do it was to grab PR_SEARCH_KEY. A customer recently discovered that this doesn’t always work after applying a recent hotfix. Before applying the hotfix, PR_SEARCH_KEY would remain unchanged during the various events. After applying the hotfix, if they were in cached mode they would see the search key change during the send event, but only if the user saved the message, or autosave kicked in, before submitting.
The hotfix in question is 973404. More specifically, the change that broke the customer’s code was to address the issue outlined in 974413. This issue is in how Outlook relates Read Receipts to the sent items using PR_SEARCH_KEY. In this issue, if a user created an item as a draft, perhaps to use as a template for commonly sent mail, then copied the message before sending, the draft item and the new item would have the same search key. This in turn broke the read receipt logic.
The fix we made was that whenever we copy a message in the Drafts folder, we don’t copy the search key, which allows the copy to get a new search key and allows the read receipt logic to function. Couple this with the user saving the message to Drafts while they’re working on it – under this new behavior the saved message now has a new search key. Some of the object model events the customer’s code would see would be for the message actually being submitted, and some were for the item in the draft folder. Before the read receipt fix, these different message objects would all have the same search key. But after the fix, the search keys can be different.
The fix here is not to rely on PR_SEARCH_KEY at all. In the customer’s scenario, they were using PR_SEARCH_KEY to ensure they didn’t “stamp” a message with their properties more than once during the submission process. However, since they were already stamping data on the message, it made sense to just look for their stamp before stamping again.
We just announced a new release of the MAPI Download that’s pretty much mandatory if you want to work with Exchange 2010. You’ll also need to get and apply Rollup 1 (RU1) for Exchange 2010.
Details about the MAPI Download:
The new MAPI Download fixes a number of problems MAPI had with Exchange 2010:
If I identify other issues fixed by the updated MAPI download, I’ll add them in here.
[Update: 12/14/09] Forgot to mention that you'll still need these tweaks for your profile, but you don't have to disable encryption anymore.[Update: 12/21/09] Added information about admin access to PF.