MAPI and Exchange 2013 Public Folders
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:
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>TestPFMailbox@tailspintoys.com</EMailAddress>
<AcceptableResponseSchema>https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
</Request>
</Autodiscover>
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” | |
| PR_PROFILE_USER | PR_PROFILE_USER | This is the value of PR_PROFILE_USER from the Exchange Profile Section |
| PR_PROFILE_ALTERNATE_STORE_TYPE | "Public" | Hardcoded value |
| PR_EMSMDB_SECTION_UID | User’s emsmdbUID | This is the GUID of the Exchange Profile Section |
| PR_PROFILE_SERVER | Server from the EXCH node in the Autodiscover response | Truncate this value at the first ‘.’ in the Server value. For instance, if Server is “1234…5678@tailspintoys.com”, this value would be “1234…5678@tailspintoys” |
| PR_PROFILE_SERVER_DN | ServerDN from the EXCH node in the Autodiscover response | |
| PR_PROFILE_SERVER_FQDN | Server from the EXCH node in the Autodiscover response | |
| PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W | SMTPAddress from the PublicFolderInformation node in the Autodiscover response | |
| PR_PROFILE_AUTH_PACKAGE | Mapped from AuthPackage from the EXCH node in the Autodiscover response | For instance, a value of kerb would translate to RPC_C_AUTHN_GSS_KERBEROS. Special cases include: Anonymous maps to 0x8000F001 |
| PR_ROH_FLAGS | ROHFLAGS_USE_ROH | ROHFLAGS_SSL_ONLY | If ServerExclusiveConnect is on, include ROHFLAGS_HTTP_FIRST_ON_FAST | ROHFLAGS_HTTP_FIRST_ON_SLOW if CertPrincipalName is not none, include ROHFLAGS_MUTUAL_AUTH |
| PR_ROH_PROXY_SERVER_W | Server from the EXPR node in the Autodiscover response | |
| PR_ROH_PROXY_AUTH_SCHEME | Mapped from AuthPackage from the EXPR node in the Autodiscover response | For instance, a value of Basic would translate to ROHAUTH_BASIC |
| PR_ROH_PROXY_PRINCIPAL_NAME | CertPrincipalName from the EXPR node in the Autodiscover response |
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).
For more information on the Autodiscover process, see [MS-OXDSCLI]: Autodiscover Publishing and Lookup Protocol. Enjoy!
Comments
Anonymous
August 29, 2013
Hi Steve, thanks for the information. We've applied this to profiles we're using with downloadable MAPI and it works very nicely for on-premise Exchange but the same set of properties doesn't work for an Exchange Online mailbox - when we log in we get the mailbox but no public folders. Do you expect that to work? Thanks, OliverAnonymous
August 30, 2013
As I noted, I probably missed a few cases here. I'd suggest letting Outlook configure a profile for that scenario and then take a look at the settings to see how they compared to what you tried to set and to what's in the Autodiscover response. That'll most likely highlight what I missed. If you find out what it is, lemme know and I'll update the article.Anonymous
October 10, 2013
Hi Steve, I see that ServerExclusiveConnect is On in EXPR & EXHTTP nodes and Off in EXCH node. I believe the one from EXPR node only should be considered??Anonymous
October 13, 2013
Hi Steve, Our team has been trying to use MAPI to access public folder mailbox in a RDB for a long time. But nothing works. Could you please let us know if it's possible at all to use MAPI(e.g. MFCMAPI) to access the public folder mailbox in a RDB? If it's possible, how? Thanks a lot!!! SimonAnonymous
December 03, 2013
I am not able to find the define for PR_PROFILE_ALTERNATE_STORE_TYPE, could you point me to where that is defined or provide the value?Anonymous
December 03, 2013
#define PR_PROFILE_ALTERNATE_STORE_TYPE_W PROP_TAG(PT_UNICODE,0x65D0)Anonymous
December 03, 2013
Thanks Steve, I also cannot find the value for PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W.Anonymous
December 03, 2013
The last one I had trouble finding is PR_PROFILE_SERVER_FQDN, if this the same as PR_PROFILE_HOME_SERVER_FQDN PROP_TAG(PT_LONG, 0x662A)Anonymous
December 03, 2013
#define PR_PROFILE_USER_SMTP_EMAIL_ADDRESS_W PROP_TAG(PT_UNICODE,0x6641) #define PR_PROFILE_SERVER_FQDN PROP_TAG(PT_UNICODE,0x662B)Anonymous
December 05, 2013
Steve, I have the same question as supcxc. If I manually create a profile to access Exchange 2013 Public Folders, can I use MAPI to access it?Anonymous
December 09, 2013
I have validated that I have all the propTags and values set correctly. They are the same as the ones set by Outlook when it successfully creates the Public Folders provider. When I call CreateProvider I always get back a MAPI_E_NOT_FOUND (0x8004010f) error and the provider is not created. Any suggestions on what I should check. Am I passing the wrong value to the lpszProvider param? I have tried various values there both unicode and ansi.Anonymous
December 17, 2013
@supcxc / calonzo Have you ever solved it?Anonymous
April 19, 2017
Steve, do you know the "People I Know" folder at the root container of a mailbox in MFCMAPI viewer? We have several user mailboxes who cannot open their mailboxes in Exchange 2016 owa (note OWA loght version is working fine). and their reminders are not working at all. We use MFXMAPI to open the mailbox and found out there are several duplicated folders on root containers of the mailbox such as:"People I know""People I know1""People I know2"......"People I know9"RemindersReminders1Reminders2...Reminders9it seems 9 is the max number of folders. We tried to delete these folders from MFXMAPI and run Outlook /resetfolders, both of folders comes back with one entry. that's perfect. so OWA login is working fine after that, however reminders are still not working.next day, OWA is not working again, so we use MFCMAPI login again, see both folders comes back with 10 folders as previously.this time we just delete one "People I Know9" folder, OWA is working again, later on once the "People I Know9" folder comes back, OWA login failed again. Any idea what cause the issue with these duplicated folders and why this causes OWA login not working. Thanks,Harry