MAPI Spooler Status returns STATUS_FAILURE

Jul 6, 2013 at 1:57 AM
After executing the "Session\Logon" command of MFCMAPI and supplying a correct password, I receive the correct table of MsgStore providers in the main screen. Then I execute the "Session\Advanced logon\View status table..." command. When I do so, the "MAPI 1.0 Spooler" returns a status code of 4, "STATUS_FAILURE". Outlook appears to be able to transfer mail with the profile, so I assume the spooler must somehow work. Have I missed some important configuration step? Thanks in advance for any help that you can provide.
Coordinator
Jul 8, 2013 at 2:05 PM
Just because you're able to find an error code somewhere by digging around doesn't mean something is wrong - is there something that's actually not working?
Jul 8, 2013 at 2:46 PM
I hardly think that I was "digging around". I executed the "logon" command followed by the "View status table" command. I wasn't suggesting that there was something wrong with your utility. Somehow, apparently erroneously, I had the idea that you understood MAPI internals, and Microsoft was providing some level of support for MAPI through you and your application. In that regard, I was hoping someone would either suggest reasons that the Spooler was in a failure state, or suggest an interface that I could query that would help me determine why it is in the failure state, or even suggest that I had missed a step before inspecting the status table.

As to what actually goes wrong--with the spooler in the failure state, MAPI doesn't seem to be transferring mail. When I query the folder contents, I don't see them update. I believe that my post detailed this. (You might want to reread it.) Although much of the MAPI documentation refers to MFCMAPI as a sample application, it unfortunately appears to little more than a function executor with a fancy response display interface. While this may help people that don't know how to write code, it doesn't really help much in addressing issues like the one that I have, where I need help understanding what is actually going on internally within MAPI. It also is not really a very good sample, as much of the higher level MAPI logic is omitted.
Coordinator
Jul 8, 2013 at 2:59 PM
Your original post only states that you see an error in the status table, and that Outlook seems to be working. Incidentally, I see the same error in my status table, and everything is working for me.

Perhaps you could start from the beginning, outlining the problem you're trying to solve, in more detail than you've provided so far.
Jul 8, 2013 at 4:32 PM
On a Windows 7 Professional 32-bit computer with Outlook 2010 installed (14.0.6129.5000 32-bit) I have a profile with an IMAP/SMTP e-mail account. There are two message stores, one for the e-mail address and one the "Outlook Data File". When I logon to the profile, hierarchical folder changes made to the imap e-mail message store are correctly reflected when I browse the message store hierarchy. However, when I attempt to retrieve the contents of one of the folders through the "Contents Table", nothing is returned. The table status command returns TBLSTAT_QCHANGED, which indicates MAPI probably understands that there should be data. My presumption, perhaps erroneous, is that the spooler may need to be involved in updating the content table for the folder--hence my concern over the STATUS_FAILURE returned via the status table. Although I must admit that the success of the hierarchy table suggests that I don't understand as much as I need to. I haven't determined how to further interrogate the cause of the spooler failure. I have another profile with two IMAP/SMTP e-mails plus the Outlook message store, and it exhibits the same behavior. Is this specific enough?
Jul 8, 2013 at 4:33 PM
I forgot to add, that when I invoke outlook and click on one of the folders, the contents are updated. Thanks, in advance, for any advice you can give.
Coordinator
Jul 8, 2013 at 5:19 PM
Are you writing or do you intend to write code here?

There is no spooler in Outlook's MAPI anymore. The code that synchronizes the local store with the IMAP server operates within Outlook, and not from external MAPI programs (like MFCMAPI). MFCMAPI just sees what's in the local store, in whatever sync state it's in.
Jul 8, 2013 at 5:46 PM
Yes, but it should be possible to trigger a synchronization from the MAPI interface. My understanding is that the spooler was moved from an external service to an internal thread. The documentation indicates that IMAPIStatus::FlushQueues() interacts with the spooler: http://msdn.microsoft.com/en-us/library/office/cc839804.aspx Is this documentation incorrect? Are you saying that a MAPI program can not trigger such a synchronization? If this is the case, than MAPI's usefulness is significantly diminished.
Coordinator
Jul 8, 2013 at 6:04 PM
The spooler was moved into Outlook, so you have to run Outlook to get spooler type operations. You might be able to get what you want using the Outlook Object Model.
Jul 8, 2013 at 6:21 PM
Then the Microsoft documentation linked above is incorrect?
Coordinator
Jul 8, 2013 at 6:38 PM
It still applies to Exchange's MAPI implementation.
Jul 8, 2013 at 7:08 PM
The documentation does not indicate that this only applies to Exchange, as in my browser it indicates that it applies to Outlook 2013. Apparently, then, MAPI has been reduced from a Messaging Interface to a localized folder interface. This explains the limited functionality of CFCMAPI, and the limitations that I have experienced coding to the current versions of MAPI. In the old days, it was a useful usable messaging interface. I suspect that the Exchange folder syncing functionality is still in MAPI, it is just implemented in hidden COM interfaces. This is disappointing on Microsoft's part. Of course, this defeats the purpose of COM, and Greg Whitten is probably rolling over in his grave (figuratively).
Coordinator
Jul 8, 2013 at 7:25 PM
The problems you're observing are a function of the implementation of the IMAP provider, not MAPI.
Jul 8, 2013 at 8:14 PM
I would agree that the problems appear to be with the IMAP provider, but presumed that Microsoft, or one of its vendors, had implemented the IMAP provider. The IMAP provider does propagate folder hierarchy changes, so it should be able to propagate folder content changes as well. Documentation of the IProxyStoreObject leads me to the conclusion that there is an undocumented COM interface that solves the "problem".
Jul 9, 2013 at 12:22 AM
Where is IMAPISync defined? Might this possibly help me. I found the IID_, but not the actual declaration of the interface.