How to use CDO 1.2.1 to connect to Exchange 2013 using a dynamic profile

  • Article

NOTE: This article only applies to Exchange's MAPI \ CDO download. It doesn't apply to using CDO 1.2.1 with an Outlook 2007 client.

I was discussing an issue recently with a customer and I asked him to connect to the Exchange server using CDO 1.2.1.  Then I realized that I had never tried that myself.  To that end, I decided to set out to have CDO 1.2.1 create a dynamic profile and connect to Exchange 2013.

First, some things about dynamic profiles. CDO 1.2.1 has a concept of a dynamic profile.  This means that a profile is created on the fly by passing the server name and mailbox name as the last parameter to the Session::Logon() method.

This is different than using a static profile that you configured outside of CDO 1.2.1.

Session::Logon()

msdn.microsoft.com/en-us/library/ms526377(v=exchg.10).aspx

One gotcha that I ran into was that the server name and mailbox name need to be delimited by a line feed (character 10).  In Visual Basic 6 the line would look like this:

 objSession.Logon , , ,true, ,true, _ 

 "e9b5d6f1-89f1-4e02-93a1-7b3762cf2c59@contoso.com" & Chr(10) & "admin"

Of course, in Exchange 2013 the server name is the personalized server name of the target mailbox.  The mailbox name is just the alias of the user.  That's the easy part.  The hard part is configuring the registry to make this all work.  The RPCHttpProxyMap registry value is needed to get the dynamic profile created.  I discuss configuring this value in my omniprof article.  The other registry value that needs to be in place is the one which instructs CDO 1.2.1 to proceed even if Public Folders don't exist in the organization.  This setting is discussed in this blog post article by a former member of my team.  Once those are in place it should work.

The reason why these values are needed is that CDO 1.2.1 needs to know how to properly connect to Exchange.  Telling CDO 1.2.1 to "Ignore No PF" instructs it to pass the CONNECT_IGNORE_NO_PF flag when creating the underlying dynamic profile.  Creating the RPCHttpProxyMap registry value tells the underlying MAPI subsystem what RPC Proxy Server to connect to, what authentication to use, and what to do if a non-trusted certificate is encountered.

The two scenarios that I couldn't get working are targeting an Office 365 mailbox or an On-Premises mailbox where the RPC Proxy Server has been configured to accept Basic Authentication.  This is because the username and password must be configured on the profile for Exchange's MAPI to use it. You'll need to use a static profile for those scenarios.

Lastly, I wanted to point out that CDO 1.2.1 is not the recommended API for connecting to Exchange Server 2013.  However, I understand that some customers have existing applications that they may need to get working for Exchange 2013 before they upgrade. If you fall into this category this article may help you until you can migrate your application to a better API.