We're seeing a very irritating issue with EWS and Exchange when updating the message body on an Appointment. To head it off, it does not appear to be the bug detailed here:

http://blogs.msdn.com/b/dhruvkh/archive/2012/05/18/sending-appointments-from-ews-apps-where-did-my-html-go.aspx

It happens on both 2010 SP2 and SP3. We're creating Appointments with some HTML formatting the message body. Nothing fancy, just a few tables and a little bit of inline styling (since a css style header disappears into a black hole when you try to use it as part of the Appointment message body). We're able to make a nice-looking message body that goes out in the meeting requests. Well, with the exception of downlevel text at the top, but there doesn't seem to be much we can do about that short of a double-tap save.

The problem comes into play if we need to update the message body on the Appointment. All of this is automated, so the user cannot directly edit it. If we make any changes to the message body, it completely wrecks the HTML. It's still an HTML-formatted message, but much of the styling is lost and it looks awful. This happens without fail when we alter the message body of an Appointment with any considerable level of HTML formatting. BodyType is HTML, of course. I've done some digging on the best body algorithm and some of the MAPI properties related to it. Some interesting bits of note:

• When the Appointment is first saved, PidTagRtfInSync is true. PidTagNativeBody is 2, which indicates an RTF message. PidTagBody is present. PidTagRtfCompressed is present. However, PidTagBodyHtml is not present. After updating the Appointment with a message body edit, PidTagBodyHtml is present, but now PidTagRtfInSync is false and PidTagNativeBody is 3.
  
• If PidTagBodyHtml is set directly as an extended property instead of setting the message body via the EWS Appointment object, then the formatting is wrecked right out of the gate. At least it's consistent that way...
• Attempting to set PidTagNativeBody manually had no effect.
• When viewing the PR_BODY_HTML contents between a good and bad message, the good one will contain the transformed HTML. It doesn't look much like what we had initially handed to it, but gets changed in the conversion process. The bad one is much closer to what we wrote in actual HTML, but has still had much of the styling removed. It's as if creating the Appointment does the RTF conversion, but any subsequent changes use a completely different code path serverside and there does not appear to be any way around it short of even more guess and check with EWS and Exchange chewing up HTML. This is complicated by being unable to find any documentation that details how and what gets changed, discarded, etc in the process.
• This will always affect requests, but only seems to affect Appointments in the calendar of attendees if the body includes the downlevel text. Appointments without the downlevel text appear to survive updates with their formatting intact. Appointments with downlevel text get their formatting wrecked with updates.
  

Has anyone run into this before? It was painful enough when we found that our previously-used email HTML formatter wouldn't work with EWS and everything had to be inlined, but now it seems that there are even more inexplicable problems to get around. Is there a way to update the message body without this happening?

• Edited by Someone's Dev Account 15 hours 57 minutes ago

Just when you think you have it fixed...

I thought I had a way around this. Instead of setting the MessageBody in the EWS Appointment object, I directly set the PidTagBodyHtml extended property (tag 0x1013). This allowed me to use the full CSS header without losing it! I fired off a few tests. Sure enough, OWA showed all formatting with no issue! I was feeling pretty excited, thinking I finally had a solution to this problem. Then I checked it in the desktop client, which is Outlook 2013 in this case. Sorry, but no dice. Very basic format, just about everything lost. I exported the item with MFCMAPI to get the following:

• PR_BODY shows the usual basic formatting, which appears to be what I'm seeing in Outlook on the desktop. Bold characters are preserved. The tables are nothing but bold headers and badly-spaced tabs.
• PR_BODY_HTML shows exactly what was put into it. This seems accurate. This is what I'm seeing in OWA.
• PR_RTF_COMPRESSED shows the very same HTML, albeit wrapped up in all of the extra RTF formatting/tags.
• PR_RTF_IN_SYNC is false.
• The downlevel text is being inserted in the correct place. It is placed in the body and does not appear to be the cause of any of this. Still annoying that it cannot be disabled.
• MFCMAPI exports the "WrapCompressedRTFEx best body" function as well. This comes through with ulStreamFlags = 2 and szStreamFlags of MAPI_NATIVE_BODY_TYPE_HTML. It is identical to the PR_BODY_HTML.
  

Okay, so that's odd. All of that points to displaying proper HTML. However, if I look at the item directly in MFCMAPI, the table shows the following:

• PR_BODY - Not enough memory error. Opening the property shows the full body anyway.
• PR_RTF_COMPRESSED - Not enough memory error. Opening the property shows the full body anyway.
• PR_BODY_HTML - Comes through correctly as a binary property.
• PR_RTF_IN_SYNC is false

Looking at this, it seems that the initial request does NOT retrieve the PR_NATIVE_BODY_INFO, even though I can retrieve it with zero problems via EWS. Then it throws out of memory errors on both the RTF and plain text body properties, even though they still come through properly and even display in MFCMAPI. The size of the HTML body is just under 2k, the RTF is just over 2k, and the plain text body is just under 500 bytes. I would think an ROP response would have more than enough headroom for all of those. What the heck gives here? Is there a configuration or setting serverside that should be adjusted to deal with this?

• Edited by Someone's Dev Account 13 hours 47 minutes ago

I don't know the answer to your problem but have you had a read of the Best Body Retrieval Algorithm document http://msdn.microsoft.com/en-us/library/cc463905(v=exchg.80).aspx That should outline the rules that the server and client should follow when returning the body to a user. How each client then implements this is down to the client/developer eg OWA in 2013 use EWS etc but every clients different eg Outlook,OWA,ActiveSync,BES   

Cheers
Glen