SGriffin's MAPI Internals

MAPICDO May 2013 Update

Stephen Griffin - MSFT — Mon, 20 May 2013 13:38:09 GMT

It;’s here! It’s finally here! The May 2013 update of MAPICDO is live here:

http://www.microsoft.com/en-us/download/details.aspx?id=39045

At that same link, you’ll also find the long awaited configuration guidance. It’s not immediately obvious it’s there. Just hit the Download link and it will be offered to you. As a reminder, this configuration guidance will help you in configuring an RPC/HTTP (aka ROH) profile using this MAPI/CDO download package. These instructions do NOT apply equally to Outlook’s implementation of MAPI. Attempting to use these guidelines to build a profile for Outlook’s MAPI, or attempting to “port” a profile between the two implementations WILL lead to failure.

Installation details:

This version is 6.5.8320.0. All of the files in the update are dated April 29th, 2013.
If you already have a version of the MAPI Download installed, you must uninstall it before installing the new version. The installer does not upgrade, nor does it warn you if you try to install it without uninstalling the previous version.

Fixes:

ROH now works when running under Local System context
Proxy server settings are no longer case sensitive.
PR_PROFILE_RPC_PROXY_SERVER can now be set using Unicode.
Improved support for mixed 2010/2013 environments.

Enjoy!

Outlook and the Credential Manager

Stephen Griffin - MSFT — Fri, 17 May 2013 17:32:03 GMT

Recently, I’ve had a few different customers coming to me asking about Outlook’s interaction with the Credential Manager. If you’ve not looked at the Credential Manager before, you can read a bit about it here. Interaction with the Credential Manager is fairly straightforward. There’s one function, CredWrite, which is used to store credentials, and another, CredRead, which is used to retrieve them. The customers who contacted me both had the same goal: use CredWrite to cache a set of credentials for Outlook to use so the user isn’t prompted for a password.

While this seems a simple request, it turns out that once you start considering all the various scenarios for which Outlook has to cache credentials (O365, Exchange on-Premise, machine in the domain versus out of the domain, multiple profiles, multiple credentials for a single profile), it gets complicated real fast. Even if you figure out how to cache credentials for Outlook to use for one scenario, a slight change to that scenario means the credentials have to be cached differently. So while the set of functions to be used in managing credentials is simple, the logic that goes into making these calls is very complex. We ran this by development just to make sure, but the results were as we expected: We cannot support any third party manipulation of the credentials used by Outlook. If a user wants to cache credentials, they need to enter them at the credential prompt.

Message Header Analyzer Hits the Big Time

Stephen Griffin - MSFT — Thu, 02 May 2013 17:02:07 GMT

Anybody remember that Message Header Analyzer App for Office I wrote about last month? Well, the folks who do support for Exchange and Office 365 caught wind of it and liked it. In fact, they liked it so much they asked me to port the code into their Remove Connectivity Analyzer. Here’s the blog entry they just put up yesterday announcing this:

http://blogs.technet.com/b/exchange/archive/2013/05/01/introducing-message-analyzer-an-smtp-header-analysis-tool-in-microsoft-remote-connectivity-analzyer.aspx

So even if you don’t have Exchange 2013, you can still use the Message Header Analyzer by going to https://testconnectivity.microsoft.com/?tabid=mha. Feature requests and bug reports can either be directed through the feedback link on that site or by contacting me.

Enjoy!

March 2013 Second Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Tue, 02 Apr 2013 20:42:46 GMT

The March 2013 Second Release (build 15.0.0.1039) is live: http://mfcmapi.codeplex.com.

This is an emergency build to correct a problem a few people were having running MFCMAPI on Windows XP.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MFCMAPI: On Windows XP, got an error that it was not a valid win32 application.

Enjoy.

March 2013 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Wed, 27 Mar 2013 18:56:03 GMT

The March 2013 Release (build 15.0.0.1038) is live: http://mfcmapi.codeplex.com.

A few smaller changes this round: I’ve upgraded the project to support Visual Studio 2012. I also fixed a bug in the new PST parsing, and inserted a new dialog into the “Open from GAL” path to give the user the opportunity to adjust the server DN (this should help in testing Exchange 2013 scenarios).

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MrMAPI: Fixed –PST whitespace calculations to account for Outlook 2013 OSTs correctly
QuickStart: Added binary output to Nickname quickstart
SmartView: Added parsing for Contact Address Book container entry IDs
MFCMAPI: Added dialog to allow Open from GAL to edit the server DN
Upgraded projects to Visual Studio 2012
MFCMAPI: Fixed visual artifact which creeps in to folder hierarchy (vertical line next to the arrows)

Enjoy.

Developing Apps For Office

Stephen Griffin - MSFT — Thu, 21 Mar 2013 13:14:31 GMT

So – I’ve been playing a lot with Apps for Office lately. I even wrote and published an app:

http://office.microsoft.com/en-us/store/message-header-analyzer-WA104005406.aspx

My management encouraged me to put together a presentation on everything I learned while developing this app. I did, and they asked me to record a video of me delivering this presentation. So – now you all get to hear me drone on about App development. Here’s the entry on the Partner Technical Services blog containing my presentation:

http://blogs.technet.com/b/ptsblog/archive/2013/03/20/microsoft-office-lessons-learned-developing-apps-for-the-office-store.aspx

And here’s the direct YouTube link:

Microsoft Office - Lessons Learned Developing Apps for the Office Store

and the direct link to the slide deck:

https://skydrive.live.com/view.aspx/Documents/AppsForOffice.pptx?cid=8d22925062e717b6&id=documents&authkey=!AOsqoQIn-Xb4nBk&&wdSlideId=274

In case you don’t want to dig through the slide deck for the links I reference, here they all are:

Topic	Link
Getting Started	http://msdn.microsoft.com/en-us/library/fp179924.aspx
Trusted Sites Workaround	https://*.sharepoint.com, and discussion: http://social.msdn.microsoft.com/Forums/en-US/appsforsharepoint/thread/fa6abb31-7251-4744-ab14-634cde38a42d
Office App Validation Policy	http://msdn.microsoft.com/en-us/library/office/apps/jj220035.aspx
JQuery	http://jquery.com/
Mail App Permission Levels	http://msdn.microsoft.com/en-us/library/fp161087.aspx and http://msdn.microsoft.com/en-us/library/fp161047.aspx
App Limitations	http://msdn.microsoft.com/en-us/library/fp142267.aspx

Finally, my JQuery EWS parsing trick:

(function ($) {
     $.fn.filterNode = function (name) {
         return this.find('*').filter(function () {
             return this.nodeName === name;
         });
     };
 })(jQuery);
function callback(asyncResult) {
         var response = $.parseXML(asyncResult.value);
         var responseDOM = $(response);
         var Prop = responseDOM.filterNode("t:InternetMessageHeaders")[0];

Enjoy!

Exchange 2013 Compatible MAPICDO

Stephen Griffin - MSFT — Thu, 28 Feb 2013 20:41:44 GMT

As several of you have noted, we recently released an update for the MAPICDO package. This is the update you have all been waiting for, as it is now possible to build an RPC/HTTP enabled profile to connect to Exchange 2013. What several of you have also noticed is that this update did NOT come with any guidance for HOW to build such a profile. Such guidance does exist, but hasn’t been published yet. I had delayed commenting on this new package until the guidance was ready, but it’s taking longer than I thought it would.

I’m working with the team responsible for publishing the guidance to get it out the door. We’ve almost got it ready, so I expect to see it up on the download site (or the Exchange blog) any day now. Once that guidance is published, Dave will most likely publish an updated version of his How to Build a Profile For MFCMAPI guidance. I’ll link to both as soon as they’re public.

Exchange 2013 Recipient Properties On Sent Items

Stephen Griffin - MSFT — Tue, 19 Feb 2013 19:37:16 GMT

http://msdn.microsoft.com/en-us/library/ee159108(v=exchg.80).aspxIf you’ve got an application that processes e-mails paying attention to the PR_RECEIVED_BY_* and PR_RCVD_REPRESENTING_* properties, you may notice these properties showing up on e-mails in the Sent Items folders of your users. That is, messages submitted by a user who doesn’t explicitly mark themselves as a recipient will still appear (in these properties) as if they received the message. This may interfere with your logic, especially if you have a need to distinguish mails a user sent from mails a user received.

Before we get into an explanation of why this is happening, some workarounds:

PR_MESSAGE_RECIP_ME, PR_MESSAGE_TO_ME, PR_MESSAGE_CC_ME: These Boolean properties will be true or false depending on whether the user is in the recipient list, specifically as either a TO or CC recipient. Together, these properties will cover every case except for when the user was BCC’d.
PR_TRANSPORT_MESSAGE_HEADERS: Typically only present on inbound message.
PR_SENDER_SMTP_ADDRESS: Typically only present on inbound messages. There are several related properties in the PR_SENDER_* family with the same quality.

Together, you should be able to use these properties to heuristically decide if a message was, from the user’s perspective, sent or received. And do note that any algorithm you put together here will by necessity be a heuristic. There is no single property that tracks whether a message in a user’s mailbox was sent by the user, received by the user, neither, or both.

Now – when/why does Exchange 2013 stamp these properties? When first: It appears Exchange 2013 will stamp these properties when Outlook (any version) submits a mail from a profile with only one Exchange mailbox in it. These properties will then be present on the copy of the message which ends up in Sent Items (or wherever the sent copy is to be saved). If the profile contains multiple Exchange accounts (aka Multi-Ex, possible in Outlook 2010 and higher), then Exchange 2013 does not appear to stamp these properties on the message that ends up in Sent Items.

Why: Exchange 2013 has a completely new store, written in managed code (the old, native, store.exe no longer exists). As part of this work, we found that it was possible for the transport to attempt to deliver a message multiple times. Part of the work involved in making sure this didn’t happen was to ensure these properties were set on messages as we processed them for transport. The difference in behavior with Multi-Ex is attributable to the fact that Outlook builds the messages it intends to submit differently in Multi-Ex.

It was suggested to me that this change in behavior means our documentation is now incorrect. I do not agree with this assessment. For instance, here’s a snippet from the MSDN documentation of PR_RECEIVED_BY_NAME:

Contains the display name of the messaging user who receives the message...These properties are an example of the address properties for the messaging user who receives the message. They must be set by the incoming transport provider.

And the [MS-OXOMSG] protocol doc:

The PidTagReceivedByName property ([MS-OXPROPS] section 2.961) contains the e-mail message receiver's display name, as specified by the DisplayName field of the RecipientRow structure ([MS-OXCDATA] section 2.8.3.2).

Note that the documentation does not indicate anything about what should or should not be present on sent items. It only documents these properties in relation to received messages. What happens with sent messages is undefined behavior, so any behavior is acceptable, as is changing behavior. I’m sending this article over to the protocol team, however, so they can note this behavior with respect to Exchange 2013.

Custom Providers and Outlook 2013

Stephen Griffin - MSFT — Tue, 29 Jan 2013 20:39:04 GMT

Some of you may have already noticed this by now, but the logic used to load MAPI providers has changed in Outlook 2013. Previously, we would use LoadLibrary to load a MAPI provider. This API has logic in it to search the user’s PATH for the provider, which is great if you placed the provider somewhere on the user’s PATH. In Outlook 2013, though, we call LoadLibraryEx, passing the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag. The effect of this flag is that Outlook no longer searches the path.

Fortunately, you can still put your provider wherever you want by putting the full path in MAPISVC.INF. You may need to rethink how you load your own dependencies, but now that you know what’s going on that problem shouldn’t be insurmountable. BTW – Process Monitor is invaluable in investigating this sort of issue.

January 2013 Release of MFCMAPI and MrMAPI

Stephen Griffin - MSFT — Mon, 28 Jan 2013 21:14:43 GMT

The January 2013 Release (build 15.0.0.1037) is live: http://mfcmapi.codeplex.com.

We’ve been working a few issues lately related to the size of a OST versus the size of a mailbox. I’ve added some features to MrMAPI to aid in these sorts of issues. First is the –Size switch, which calculates the size of all the items in a folder and it’s subfolders. You can combine it with the –Folder switch to get the size of any folder. For instance, using the @2 notation to refer to the Contacts folder, I can get the size in my own mailbox as follows:

C:\>mrmapi -size -f "@2"
Folder size (including subfolders)
Bytes: 388867
KB: 379
MB: 0

The second feature uses the documentation of the PST file format to read the header of a PST/OST file and report free space. Note that this does require that the file not be loaded in Outlook when you run it. Simply closing Outlook is sufficient. Here’s an example run against an OST here:

C:\>mrmapi -pst -i c:\Users\sgriffin\AppData\Local\Microsoft\Outlook\outlook.ost
Analyzing c:\Users\sgriffin\AppData\Local\Microsoft\Outlook\outlook.ost
Unicode PST
File Size           = 2.71 GB (2911577088 bytes)
Free Space          = 1.05 GB (1132028480 bytes)
Percent free        = 38.88%

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

MrMAPI: Added –PST for PST whitespace calculations
MrMAPI: Added –Size for folder size calculations
MrMAPI: Corrected handling of –Store parameter
QuickStart: Using QuickStart now populates the main window UI when appropriate
Property Editor: If you paste a property name in with extra whitespace or commas, these are now ignored
SmartView: Added a few more properties

Enjoy.