How to use the same profile to connect to both Exchange 2013 and legacy versions of Exchange Server

As promised in my previous post, here is an post which walks you through the creation of a profile which can be used to connect to both an Exchange 2013 Server as well as a legacy version of Exchange Server (2007, 2010).  The reason why this is needed is because their is an explicit block in place that prevents profiles configured to use RPC over HTTP to interact with legacy versions of Exchange Server.  Therefore, the standard mechanism of profile creation won't work.  To get this working you will need to utilize a registry value named RpcHttpProxyMap.  You can read more about this registry value and it's various settings in the MAPI guidance document published with the latest version of the MAPI/CDO download.  The steps below will walk you through creating a profile that uses this value in addition to the properties configured in the profile.  Although not a prerequisite, it may be helpful to review my previous posts about profile creation with MFCMAPI before walking through this one.

• How to use MFCMAPI to create a MAPI profile to connect to Exchange 2013
• How to use MFCMAPI to create a MAPI profile to connect to Exchange 2010

These steps require that the version of MAPI/CDO is at least 6.5.8309 and the latest version of MFCMAPI. These steps will not work with any version of Microsoft Outlook.

Important This section contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following Microsoft TechNet article: Backing Up and Restoring the Registry

1. Make sure that you have Exchange 2013 properly configured.  The best way to do this is confirm that Microsoft Outlook can connect successfully.
2. Create a REG_SZ value named RpcHttpProxyMap_MFCMAPI in the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\Current Version\Windows Messaging Subsystem
3. Populate this key with the domain suffix of the personalized server id (the domain part that is right of the '@' symbol, e.g. F5FA...5591@contoso.com) then an equal sign followed by the FQDN of the Rpc Proxy Server, followed by a comma then the proxy server settings in the format RpcHttpAuthenticationMethod, RpcAuthenticationMethod, and then indicate what the subsystem should do when an invalid certificate is encountered.  A value of 'true' indicates that invalid certificates should be ignored.  For example, contoso.com=mail.contoso.com,ntlm,ntlm,false
4. Open up MFCMAPI, go to Profile > Show Profiles
5. Click Actions > Create Profile
6. Give the new profile a name and click OK.
7. Select the new profile
8. Right-Click and choose Services > Add Service...
9. Enter MSEMS for the service name
10. Uncheck the box which says 'Display Service UI'
11. Click OK
12. Double-click the newly created profile
13. Double-click the MSEMS service
14. Find the Global Profile Section.  It's the provider with the PROVIDER_UID that is 13DBB0C8AA05101A9BB000AA002FC45A and single click it.
15. Go to Property > Additional Properties
16. Click Add and add the following properties PR_PROFILE_UNRESOLVED_NAME, PR_PROFILE_UNRESOLVED_SERVER
17. Click OK
18. Configure each property using the guidance below.

    Property: PR_PROFILE_UNRESOLVED_NAME

    Value: mailbox alias

    The alias for the target mailbox. For example, Administrator

    Property: PR_PROFILE_UNRESOLVED_SERVER

    Value: The personalized server id

    This is the value retrieved from Autodiscover. It will be in the format guid@domain. For example, F5FA2827-5978-43cd-8FA8-E07BC3BB5591@contoso.com

    Property: PR_PROFILE_CONNECT_FLAGS

    Value: CONNECT_USE_SEPARATE_CONNECTION (0x4) | CONNECT_IGNORE_NO_PF (0x8000)

    Tells the subsystem to use a separate connection and still connect if no public folders are in the organization

19. Select Session > Logon and display store, and select the profile is not already selected.

The steps above will connect you to a mailbox residing on an Exchange 2013 Server.  From there you can use MDB > Open other mailboxes >  From GAL... to connect to a mailbox residing on a legacy version of Exchange Server.  If you want to connect first to the mailbox on the legacy version of Exchange Server use the same steps but in step 17, use the target server's name for PR_PROFILE_UNRESOLVED_SERVER instead of the personalized server id.  Additionally, you may need to specify PR_PROFILE_UI_STATE if RPC encryption is enabled on the target legacy Exchange Server.  This is the default in Exchange 2010.  Please see my previous post on profile creation for Exchange 2010 for setting the value of that property.

The personalized server id is the server name returned from Autodiscover. You can find this in a variety of ways. If you are using the SOAP based Autodiscover the property you are looking for is InternalRpcClientServer. If you are using the Plain Old XML (POX) based Autodiscover the property you are looking for is of type EXHTTP in the protocol node. The node name is Server. You can use Outlook to make an Autodiscover request on your behalf by right clicking the Outlook icon in the System Tray while holding down the CTRL button and choosing 'Test E-Mail Autoconfiguration'.

It is recommended that you add a suffix to the RpcHttpProxyMap which is unique. This avoids conflicts with other MAPI applications that may be running on the machine.  I added "_MFCMAPI" to the value's name for this purpose.

The RpcHttpProxyMap value's data is case sensitive if using version 6.5.8309.  Therefore, "contoso.com=mail.contoso.com,ntlm,ntlm,false" is not the same as "Contoso.com=mail.contoso.com",ntlm,ntlm,false.  This was changed in 6.5.8320 and is no longer case sensitive.

Properties configured in the profile will always override the registry key.  Therefore, when the properties in the profile are in conflict to the properties in the registry MAPI will use the properties in the profile.

Lastly, the version of MAPI/CDO was incorrectly stated on the download page as 8.3.8309 for 6.5.8309.

Comments

• Anonymous
  May 29, 2013
  The comment has been removed
• Anonymous
  May 29, 2013
  Hi Ryan, MAPI_E_FAILONEPROVIDER is a very generic error for the MAPI subsystem.  Here are some things I would try:

1. Look at the RCA Logs on the target Exchange Server around the time that the logon was attempted.  If the request made it to the server, then any error (e.g. Permission Errors) will be logged there
2. Obviously make sure your connection information is correct.  I ran into a bunch of issues with Proxy Servers in my environment.  I generally take the Proxy URL and try it in IE and make sure that I can successfully browse to it with IE.
3. Make sure that the Outlook Anywhere settings (e.g. Whether or not to use SSL) match what you specified in the profile
4. Ensure you have Full Mailbox Access to the target mailbox
5. Check whether it matters if the target server is 2013 or a legacy Exchange version. If all those fail then I would suggest opening a support case with Microsoft for assistance. Hope that helps, Dave

• Anonymous
  May 30, 2013
  Thanks for the tips Dave, I got it sorted out. Problem was Outlook anywhere settings. It wasn't set to use NTLM auth, but my profile code was. Once I synced these it worked. Thanks again.

• Anonymous
  June 04, 2013
  Why was it decided not to completely copy Outlook's MAPI here?

  • Anonymous
    February 05, 2016
    Sorry about the late reply. I just saw this today. Not sure why or how! Outlook and Exchange's MAPI are completely different. At one point they were the same code base but they diverged, thus some of the properties could be re-used, but some had to be created from scratch due to the differences in implementation.

• Anonymous
  July 14, 2013
  Is the property PR_PROFILE_UNRESOLVED_SERVER user specific or server specific or a dynamic value? Apart from autodiscover service is there an alternate way to retrieve this property from AD/Exchange?

• Anonymous
  July 17, 2013
  The property PR_PROFILE_UNRESOLVED_SERVER is a user specific value.  The recommended way to obtain this value is AutoDiscover.

• Anonymous
  September 16, 2014
  Hello Dave, Exchange 2013 give me below error: [MAPISIS ERROR] OpenMsgStore() failed  The information store could not be opened. Err:8000000080040111 MFCMAPI gives me below error: "Network problems are preventing connection to the Micrsosoft Exchange server computer. Contact system adminsitrator if this condition persisits." Please advise.

• Anonymous
  October 07, 2014
  Hi Dan, Sorry about the delay. I just found your comment.  To answer your question if you get the error above it means that you didn't properly configure the profile.  The address book could not contact the Address Book Server and therefore you could not logon. Dave

• Anonymous
  February 08, 2015
  Hi Dave, when I add PR_PROFILE_RPC_PROXY_SERVER directly to my MAPI profile to connect to a mailbox on Exchange 2013 I cannot use MDB > Open other mailbox from GAL to open a mailbox on an Exchange 2010 server. I get MAPI_E_FAILONEPROVIDER. When I leave out the proxy server properties and only specify the RpcHttpProxyMap registry entry I can connect to mailboxes of both servers. Is that expected behavior? I would prefer to have the proxy server in the profile. -- SvenC

• Anonymous
  March 12, 2015
  Yes this is expected.  If you want to create one profile that can connect to Exchange Server 2013 and a legacy Exchange Server (i.e. Exchange Server 2010, Exchange Server 2007) then you must use the registry map. Dave

• Anonymous
  March 18, 2015
  Hello - I'm pulling my hair out trying to get this to work since I have a MAPI-enabled antispam solution that I need to get working on an Exchange 2013 server. I've followed the instructions above, along with the instructions from your preceding article on linking MFCMAPI to Exchange 2013, and I keep getting a MAPI_E_LOGON_FAILED == 0x80040111 when I attempt to access the profile. I also notice several 0x8004010F MAPI_E_NOT_FOUND messages despite having installed the March 2014 update for MAPI CDO. I will note that, when I attempt to manually browse to mail.server.address/mapi in IE that it asks for a user name and a password; once I provide one, it then states that access is denied. I'm not sure if that's normal or not and am reluctant to fix that one way or another until I know for sure.

• Anonymous
  March 25, 2015
  Hello David, I am sorry to hear you are having problems. Here are a couple of things to try. First, let's say your server FQDN is mail.contoso.com.  Navigating to mail.contoso.com/mapi in a browser is not the correct test to perform.  If you are trying to connect to the endpoint that MAPI CDO is connecting to, it would be more like http://mail.contoso.com/rpc/rpcproxy.dll or https://mail.contoso.com/rpc/rpcproxy.dll  if using SSL.  Depending on your Outlook Anywhere settings you may get prompted. If you enter your credentials, and they are accepted, you would receive a blank page.  Seeing the blank page would indicate that you were successfully able to perform a HTTP GET against the target endpoint URI.  This would confirm that the client machine can "see" the server endpoint if the correct URI and credentials are used.  However, you may be getting "Logon Failed" for other reasons. Second, if you can't get past this, I would suggest opening a support case with Microsoft support.  They can help you walk through the profile creation process and may be able to figure it out quicker. Hope this helps and thanks for reading my blog! Dave [Edit: 3/30 - I neglected to include "rpcproxy.dll" as the resource being requested for the ROH endpoint and other corrections]