Prior to Exchange 2013, when Outlook’s emsmdb32 provider would log on to the server, it would get various bits of information back from the server, including information needed to connect to the Public Folder store. The provider would use this information to add the Public Folder store to the profile. This work involved pumping messages and this is where the workaround given here was involved:

With Exchange 2013, logon no longer returns any information related to Public Folders. Instead, the information needed to connect to Public Folders is handled through Autodiscover. When we do the initial AutoDiscover for profile creation, we get an entry back indicating that there is a Public Folder mailbox. Here’s what it looked like for my test mailbox:

<PublicFolderInformation>

<SmtpAddress>TestPFMailbox@tailspintoys.com</SmtpAddress>

</PublicFolderInformation>

We see the name of the Public Folder mailbox is TestPFMailbox. Outlook uses this information to conduct another Autodiscover conversation to get information on the Public Folder mailbox. Essentially, we send a request that looks like this:

We get a response back with information on the PF mailbox. Outlook then uses this information to make a call to CreateProvider to actually add the Public Folder store to the profile. CreateProvider takes a set of MAPI properties, whose values were derived from the information in the Autodiscover response. The properties we pass to CreateProvider are all derived from the AutoDiscover response:

Property

Source/Value

Comment

PR_DISPLAY_NAME_W

Public Folders –%s”, where %s is the value of PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W. So, for my folder, it would be “Public Folders – sgriffin@tailspintoys.com”

I’ve done a bit of hand waiving above, and I’ve likely missed a number of corner cases, but this should be enough for someone to get started. All of this work actually happens in Outlook.exe, so there is no way for external MAPI processes to trigger it (though it’s possible it might happen while using the Outlook Object Model).

If you have an installer which uses MAPI, specifically, which calls MAPIInitialize, you should be aware of this. After calling MAPIInitialize from the installer, you may note that you can no longer start Outlook! This only happens with Outlook 2010 and higher.

The exact path may vary on different systems. The ACL we set contains three entries in it: System, the Administrators group, and the current user. When you start MAPI normally, the current user is the user the application is running as, which is typically the desktop user, so everything is fine. But when you run MAPI from the context of the installer, the current user can end up NOT being the desktop user. In that case we end up setting an ACL that denies the desktop user access to the registry key!

When Outlook subsequently tries to run, it finds it has no access to the Profiles registry key, so it has no MAPI profiles. Without MAPI profiles, Outlook can’t function, so you get an error, “Cannot start Outlook”. If you then try to run Outlook elevated, and you happen to be in the Administrators group, MAPI can then access this key and reset the ACL to the usual ACL, fixing the problem.

As far as I’m aware, not many applications call in to MAPI from an installer context, so this is somewhat a corner case. Additionally, it’s difficult to detect from MAPI’s perspective that we’re running like this. But if you want to avoid causing this problem for your users, you can use the functions GetSecurityInfo and SetSecurityInfo to grab the ACL before you call MAPIInitialize and then set the ACL back afterwards. Specifically, call GetSecurityInfo with SE_REGISTRY_KEY and a NULL Owner and Group parameter. Save off the Dacl and Sacl you get, then supply these to the SetSecurityInfo call after MAPIInitialize completes. This will prevent MAPIInitialize from rewriting the ACL on the Profiles key. You should only do this when running in an Installer or any other context where you find MAPI is writing an ACL that ends up affecting the desktop user.

If you dig around in the EWS documentation, you’ll find this element: WebClientReadFormQueryString, which should give you a URL for an item in OWA. When Exchange Server 2013 shipped, we had some EWS developers who noticed this element was still giving out URLs in Exchange Server 2010’s OWA URL format, which no longer works with Exchange 2013. If you look in the Remarks for the WebClientReadFormQueryString article, you’ll see we‘ve added documentation to allow you to build URLs for 2013 by hand.

So – what happened? As Kristian describes it, Outlook Web Access in Exchange 2013 is a complete rewrite from the previous versions of OWA. This means a whole lot of new features (like Office Mail Apps), but it also means some features got left out. This article gives the highlights. In that article, you’ll note that Outlook Web App customization, as it existed in earlier versions, is not available in Exchange 2013. Part of this includes the old 2010 style URLs that could be used to create and access different types of items.

So – with Exchange 2013, you can use the format given in the documentation for WebClientReadFormQueryString to create a URL to view an existing email message. We do not have a similar URL format for other types of items, such as Appointments, Contacts, or Tasks. We also do not have a URL format for creation of items.

Now that MAPICDO has been updated to support connecting to Exchange 2013 using RPC/HTTP, and the guidance for programmatically building profiles has been published, Dave has published a pair of articles which will be very helpful for customers using MFCMAPI in such environments. The first covers using the guidance to build a profile for connecting to Exchange 2013:

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.

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.

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:

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.

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:

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:

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.

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_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.

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.

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.

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:

I’ve just checked in a fix for the Wrapped PST sample that should allow it to work with Outlook 2013. Let me know if you find any problems with the sample. I haven’t tested the other samples yet as they don’t appear to get as much attention as the wrapped PST.