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 HTML message, which is correct. 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 10 hours 50 minutes ago