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

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,

Dave has a post up about the fate of the System Attendant Mailbox in Exchange 2010 . Since this mailbox isn’t there anymore in 2010, if you have a solution that depended on it, you’ll need to rework it. Dave gives a few suggestions, such as creating your own mailbox/account (the best option since you can then control your exact permission set) or using the System Mailbox . Enjoy! digg_url = "http://blogs.msdn.com/stephen_griffin/archive/2009/10/09/so-long-system-attendant-mailbox.aspx";digg_title

My colleague Edwin, writing for the Exchange Support Team Central Europe blog , posted an article on accepting meeting requests with CDO . The key takeaway from the post is this: This means that when calling the respond method on meeting updates / requests, the sequence number must be read from the request and written to the response, otherwise Outlook will not be able to match the response to the original meeting. (The proposed solution is to read the dispidApptSequence from the original message

I just closed case where the customer was trying to create a profile but Check Name was constantly prompting for credentials and then failing. This wasn’t the reconfig issue I mentioned before – they couldn’t create the profile in the first place. Even GCReconnect showed the same behavior – repeated prompts for credentials, then failure, with the error MAPI_E_USER_CANCEL. We took a network trace of the attempt to create the profile to see where the failure came from. The trace showed us attempting

When I posted the Referral Madness article, there was an intriguing comment that I didn’t get a chance to investigate until it came up in a case. The commenter noted that when we used RPC_C_AUTHN_GSS_NEGOTIATE as our authentication mechanism, we could no longer use “Check Name” in the dialog brought up by ConfigureMsgService : If we hit Check Name, we get an error that the name could not be resolved due to network problems: To understand why we get this error, we look at one of the caveats I noted:

The first time we saw this, we wrote it off as an odd thing one customer did. But we’ve seen it a few times over the past couple years and it deserves some discussion. The issue is with Exchange Client Extensions (remember – they’re dead in 2010 !): Customers would report that, when client extensions from certain companies are loaded, Outlook will behave strangely. The symptoms would usually be a crash or a hang. On debugging, we would find that even the hang was preceded by an access violation.

I got a bug report this morning that using Profile\Launch Profile Wizard in MFCMAPI returned MAPI_E_NO_SUPPORT in Outlook 2010. Further investigation showed it also failed on Outlook 2007. A quick debug revealed that the function had been rewritten before we shipped Outlook 2007, so that it always returns MAPI_E_NO_SUPPORT. Why was it removed? During the development of Outlook 2007, the function was flagged as having some problems that were going to be costly to resolve. Outlook was no longer dependent

I’m in the process of updating the Outlook 2007 MAPI Samples for Outlook 2010 and ran into something that deserves some clarification. Suppose you have a 32 bit application which uses MAPI and which links in mapi32.lib. In preparation for 64 bit MAPI, you decide to try rebuilding as a 64 bit app. You install the updated MAPI headers , point your installer at them, then try building a 64 bit flavor. The 64 bit compiler might catch a few type casting errors, which you fix, then it’s time to link. Now

I noticed something about downloading/installing the Outlook 2010 MAPI headers . I use Windows Server 2008 as my development machine, and when I ran the installer, which is really a self extracting zip file, it offered to copy the headers to “C:\Program Files\Microsoft SDKs\Office\14.0\Include”. However, when I looked there, the files weren’t there. Instead, after a bit of looking around, I found them here instead: C:\Users\sgriffin\AppData\Local\VirtualStore\Program Files\Microsoft SDKs\Office\14.0\Include