I had a case recently where the customer had built an application to help manage their Active Directory environment. Part of this application used CDOEXM to create new mailboxes for their new user accounts. This is a common use of CDOEXM - nothing wrong so far. What this particular application was doing though was that when it had new work to do, it would spawn a new thread. On that new thread, they would CoInitialize, do their CDOEXM work, then CoUninitialize. The customer was reporting that the process leaked memory. Sure enough, commenting out the call to CreateMailbox prevented the leak.
After debugging, I discovered that some of the functions in the CreateMailbox code path use static variables. Each time CDOEXM is loaded and the execution hits those static variables for the first time, they'll be created in the static heap. Since his application spawned a new thread that did this for each user, the memory would increase by this amount each time. So the leak wasn't really a leak as much as it was just the way static variables work and the way his application was structured simply used an increasing amount of memory.
By moving his loop inside the CoInitialize/CoUninitialize block, the memory usage remained static.
So it seems that CDOEXM is not going to work well in an architecture like this. Here are some ideas for how to architect your solution to not run into this problem:
Sorry for the duplication, I'm just rebranding an earlier post of mine because many people have never heard of SNP and may discount the post due to the title. If you are getting MAPI errors because of RPC connectivity problems, and you have SP2 installed for Windows Server 2003, this is probably what's affecting you, especially if you have a Broadcom NIC.
If you've developed a custom message store and you can't get Outlook to display RTF or HTML content, check the length of your EntryIDs. If your RTF content is really just wrapped HTML content or you are providing PR_HTML, and for some reason Outlook 2003 won't display your HTML content, it may be the length of your EntryIDs.
Outlook 2003 leverages IE (mshtml) to display it's HTML content. It does this by implementing a protocol handler for the outbind:// protocol. Outbind's format leverages the EntryID of the message when creating the URL. You can probably see where I'm going here. If your entryID is longer than the allowable limit for a URL, which for IE7 is 0x200 (512) characters, then mshtml fails the load of the HTMLDocument. When that happens, Outlook says "oh, well, RTF/HTML didn't work, let's just load PR_BODY and live with that.
If you've verified that your EntryID is sufficiently short enough (maybe only 100 or so characters) then you may want to look at the values you're returning in the GetProps or QueryRows call.
This could change from version to version, but in general, you just return MAPI_E_NOT_FOUND for properties you don't support, MAPI_E_NOT_ENOUGH_MEMORY that you support but don't want to return in this GetProps call necessarily. If you return the size error for PR_BODY, PR_HTML, and PR_RTF_COMPRESSED then the RTFSync property will determine the preference on whether we use HTML or RTF. Of course, you should always be returning the value (or MAPI_E_NOT_FOUND) if asked for the property directly (as in OpenProperty or HrGetOneProp).