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:
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.
You don't want to be failmilar with this topic... it's a glitchy as h** don't use it if you send a file attachment and the email takes more than a minnute to send it will loop and contune to send the email hundreds of times and if you use hotmail you will get blocked out of you're own account. So please spare us people some pain and just use something that works, without SEVERE PROBLEMS.
I give - I don't see what your comment has to do with this post. If you're having issues with Exchange, you can take them to a forum more likely to provide assistance with Exchange administration, like the Ehlo blog: http://msexchangeteam.com/ or, even better, an Exchange newsgroup such as microsoft.public.exchange.admin.
Hello, thanks for that posting, because it describes exacly my problem :-) i use CDO and VBScript to access public folders and checked the infostore instances to find the public folder root. with Outlook 2007 CDO or on a Exchange 2007 Server (with Exchange Server CDO installed), i can only see the "Mailbox".
Unfortunaly i'm not sure, if i can call "HrDispatchNotifications" from VBScript.
Any idea to access the PF with CDO and VBScript ? or is thit the last signal to switch to webservices ? (which are not availible with Exchange 2003 and older).
So any hint how to do the "Step 3, call HrDispatchNotifications" from VBScript ?.
Frank
I think you'll need to implement it yourself - so the question comes down to how to implement a message pump in vbscript. I won't be much help there. :)
Hello, thanks for the post. I was just wondering, is the algorithm you prescribe Outlook MAPI specific or is a good idea in general? Should I be using this algorithm for Exchange MAPI as well?
I'm having a somewhat different issue where I get the E_FAIL instead of the EDK_E_NOT_FOUND so I'm guessing something else is the problem, but I'm thinking this algorithm would be a good prevention to add to my app anyhow. Thoughts? Thanks.
I don't think this applies to Exchange's version of MAPI. The function's still there, but I think Exchange adds the PF every time, like Outlook used to do.
We are able to work around the issue by implementing “Exercise for the reader 2” as mentioned in the above blog. But it’s bit ambiguous as we need not to use profile name but use third parameter as “False” so it uses the current shared MAPI session.
objSession2.LogOn , "", False, False, , True, SERVER & Chr(10) & Mailbox
For detail have look @http://blogs.msdn.com/brijs/archive/2009/11/13/issue-accessing-public-folder-store-using-cdo-1-2-1-for-outlook-2007.aspx
@brijs
The only problem with logging onto a session by specifying "False" as the third paramerter is that it needs the Outlook to be opened. If the Outlook is not running you will still not be able to access the public folder.