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 first version of the MAPI download which is compatible with Exchange 2010 is 6.5.8147 If you already have a version of the MAPI Download installed, you must unininstall it before installing the new version. The installer does not upgrade, nor does it warn you if you try to

Bunches of people have contacted me asking if the MAPI download works with Exchange 2010. My usual response has been that I know it works, but you have to tweak the profile. I didn’t know the specific tweaks ‘cause I hadn’t looked in to it. Dave Vespa just blogged those tweaks . Note that they’re very similar to the modifications we use with Exchange 2007 to get referral working. Also note that the profile Dave builds is not referral enabled, but this doesn’t matter any more. With Exchange 2010,

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:

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

Suppose you’ve scheduled an meeting and sent out meeting requests to a number of recipients. Some of those recipients don’t like the time you’ve scheduled for the meeting and decide to propose a new time . At this point, you will receive a message with message class "IPM.Schedule.Meeting.Resp.Tent". This message will contain information about the proposed new time, which Outlook will then tag on to the meeting when it processes the response. Now – suppose you also have some CDO based code

I had some extra time today, so I put together updates I’ve been working on for the GCReconnect sample/tool which we use to demonstrate/test referrals . The key addition here is an oft requested switch, –k, which requests that we keep the profile that GCReconnect built. I've posted the updated sample here . C:\>gcreconnect Creates a profile, optionally enabling referral and reconnect logic, and tests name lookup. Usage:  GCReconnect [-?] -m mailbox -s server [-e] [-x] [-n name] [-l] [-r]

This is an issue that has only been reproduced so far with Exchange 2003 , but I wanted to document it here in case anyone else is running in to it. Suppose you have a CDO 1.21 based application which uses GetAssociatedAppointment to accept meeting requests. Suppose further that this application receives and processes a meeting request that contains an embedded message. The resulting appointment item created on the calendar will have an attachment on it, but this attachment will be unusable. What’s

Working with a customer the other day, I went looking for my blog post discussing the fact that MAPI is not supported with .Net. Turns out, while I’ve mentioned it several times, I’ve never devoted a topic to it. So here goes. Here are the articles which outlines our official support policies for MAPI and .Net, from both the Exchange and Outlook perspectives: Support policy for Microsoft Exchange APIs with the .NET Framework applications Support policy for Outlook APIs that are used in the .NET Framework