Outlook 2007, Public Folders, MAPI and You

  • Article

This was discussed a while back in one of the newsgroups . I figured I'd document it a little more permanently here.

Outlook 2007's version of the Exchange provider, emsmdb32, doesn't automatically add the Public Folder store to the message store table of a new profile. Instead, it waits until a successful connection has been made to the Exchange server. If it then detects that the public folders are available, it updates the profile and sends a table notification indicating the availability of Public Folders. This is a change from previous versions of Outlook and from Exchange's version of the provider. We made this change to better support Exchange 2007's Public Folder-less environments.

This mechanism of using a table notification has caused some confusion though. Many have observed that the table doesn't appear to be updated at all, yet if they log off the profile and log back on, Public Folders are now suddenly listed. The problem is that for notifications to be processed, messages have to be pumped, and a lot of console or service based MAPI applications don't pump messages. This is where HrDispatchNotifications comes in.

Most MAPI developers probably aren't familiar with this function, but they should be. It does exactly what it says it's going to do: it makes sure all pending notifications have been dispatched. It does this by grabbing the internal table of pending notifications, then pumping messages until the table is empty. As the documentation for the function notes, you could implement this yourself using PeekMessage and DispatchMessage, but not nearly as efficiently.

Here's the general algorithm for logging on to Public Folders using Outlook 2007's version of MAPI:

  1. Check the message store table for a row with PR_MDB_PROVIDER matching pbExchangeProviderPublicGuid. If you find it, use it.
  2. Else, look for PR_MDB_PROVIDER matching pbExchangeProviderPrimaryUserGuid. (If it's not there, this isn't an Exchange profile at all!) Open this provider. (You can Release it if you're not planning on using it.)
  3. Call HrDispatchNotifications.
  4. Scan the message store table again for pbExchangeProviderPublicGuid. If it's still not there, then this environment doesn't have Public Folders. This is NOT an error, so plan for and handle this case gracefully!
  5. If it is there, open it up.

Exercise for the reader 1: Keeping the above in mind, what happens when you use a dynamic profile in CDO?

Exercise for the reader 2: Suppose you create a dynamic profile with CDO, then before closing, it, you Logon again, using the name of the first profile as the first parameter to the second Logon? Hint: remember that deleted profiles aren't really deleted.