Outlook behavior varying by Exchange 2010 update rollup level? RRS feed

  • Question

  • My COM add-in for Outlook (2003, 2007, 2010, and soon 2013) works by sinking the BeforeRead events (whether through an ECE or through the new OOM events added in 2010 -- which are great).  For certain messages, the add-in needs to replace the contents with a completely different message, one loaded from MIME using MIMEtoMAPI, like so:


    Once it has that brand new MAPI IMessage created, it proceeds to process the IMessage whether from MAPIOBJECT from the OOM (2010) or the IMessage passed in from the ECE (in 2003/2007, LPEXCHEXTCALLBACK::GetObject...).  What it does is that it deletes all of the necessary MAPI properties on the target object (the one being read from ECE/OOM event) and then copies from the MIMEtoMAPI provided message.  For example, PR_BODY_A, PR_BODY_W, PR_HTML, PR_RTF_COMPRESSED, PR_MESSAGE_FLAGS, and so on.  I explicitly DO NOT, repeat, DO NOT call SaveChanges at any point, however, because I want the changes to NOT persist.  (The data being displayed is confidential and derived from a sensitive source.)

    That all seemed to work really well for all versions of Outlook and Exchange.  However, I noticed after an update rollup to Exchange 2010 SP1 that this no longer worked as well as it did before.  Specifically, Outlook would always use the plain-text body, whereas the MIME loaded in was HTML.  The PR_RTF_COMPRESSED provided by the MIMEtoMAPI object is still the same as before, but a couple of interesting new behaviors happen on the target object:

    -Deleting PR_HTML, PR_BODY, PR_RTF_COMPRESSED seems to work, but the properties remain, but all are MAPI_E_NOT_FOUND when queried (a thousand thanks to OutlookSpy and being able to invoke it by creating it with CoCreateInstance).

    -PR_NATIVE_BODY_INFO shows up and seems to indicate that it is a plain text message.  The same is true of OOM BodyFormat.  This is after the message has finished opening and my add-in is through.

    -Using OutlookSpy after my add-in does its thing, I do see that PR_RTF_COMPRESSED and PR_HTML is set properly, just that Outlook seems to always want to display the plain-text.

    I have created a series of Excel spreadsheets that contain the differences between before and after the update rollup.  (Being able to export properties from OutlookSpy, awesome!)  I have been trying to analyze based on this and I have some ideas, but nothing solid yet.

    Finally, I need to say that this problem only happens when cached Exchange mode is disabled in the profile configuration and after Exchange Server SP1 update rollup 3 version 3 is installed.  I have a snapshot on the server I can roll back to and then roll forward to to test this.  Turning cached Exchange mode back on means that Outlook will stop preferring to use the plaintext and use the PR_RTF_COMPRESSED version.  (I have been playing around with RTFSync, but it does not seem to matter here.)

    I have tried reviewing the list of KB articles for each thing fixed in 2010SP1u3v3 (as I have taken to calling it), but I do not see anything that would indicate this change.

    Feel free to ask me questions, as I know there is a lot going on here.  I was rather surprised to see this behavior change myself.

    Wednesday, February 13, 2013 6:27 AM

All replies

  • Most likely your code confuses Outlook's best body logic- if PR_RTF_COMPRESSED is set last, it may not see the wrapped HTML.

    Try to reset the PR_HTML property.

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.4 is now available!

    Wednesday, February 13, 2013 1:23 PM
  • OK, but as I recall, I think the IMessage out of MIMEtoMAPI only contains a PR_RTF_COMPRESSED property.  Or do you mean reset as in delete it again?

    Wednesday, February 13, 2013 7:03 PM
  • No, I mean set the PR_HTML property. That will make Outlook think that HTML, and not RTF , is the best format.

    PR_HTML should be available after you save the message if the store natively supports HTML.

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.4 is now available!

    Wednesday, February 13, 2013 7:50 PM
  • OK, I will try that.  I have to remove the CCF_USE_RTF flag and MIMEtoMAPI starts producing an IMessage with PR_HTML.
    Thursday, February 14, 2013 6:47 PM
  • That did not really seem to help.  I have to create a stripped down example that illustrates the problem.  It does not really explain the problems; either why cached mode versus uncached mode does not work as well as installing an update rollup on Exchange breaks it.
    Friday, February 15, 2013 2:03 AM
  • So have you tried to reterieve PR_HTML and then immediately set it back?

    Dmitry Streblechenko (MVP)
    Redemption - what the Outlook
    Object Model should have been
    Version 5.4 is now available!

    Friday, February 15, 2013 5:28 PM
  • Yeah, it did not seem to help.  As I said, I had to tweak MIMEtoMAPI.  I am still confused as to why an update to Exchange would cause Outlook's body format decision technique to change.

    I am working on creating a simpler code snippet that can demonstrate the problem.  As I work on it I will try to try other things.

    Friday, February 15, 2013 9:45 PM
  • So here is what I have discovered.  In the process of writing my example code, I was working my way through loading the message via MIMEtoMAPI, and so on, and I get to the point where I am copying properties over, but not yet where I get to the point where I am copying attachments.  As it turns out, the problem is not actually in any of that code at all.  What happens is that when it comes time to copy attachments from the loaded message over to the target message, there is a problem there, where PR_NATIVE_BODY_INFO changes as well as PR_RTF_COMPRESSED.  I rolled my Exchange 2010 server back to SP1 and sure enough, copying the attachments over is fine in that case.

    I still need to write a bit more code before I have something that can demonstrate the problem for you (I had written a lot of convenience/wrapper classes that obscure the underlying code).  But I figured I should point out the problem seems to be down in processing the attachments table.

    Thursday, February 21, 2013 7:12 PM