My fellow colleague had this customer who was using Exchange Web Services to update body of an appointment item.
He created a new appointment from Outlook with some body text, attachments in the body to the position where he wanted, subject & location. Appointment was saved as it should and life was good. This is how the appointment looked like.
Then he decided to update the body using Exchange web services and see how it messed up everything
I tried to repro it with my code but was not able to repro it and my code was updating it just fine. So I serialized the request in XML for both codes and compared them. The culprit was the Body's format and this line of code was responsible for it
bodyValueInItem.Body.BodyType1 = BodyTypeType.Text;
Instead of BodyTypeType.Text we used BodyTypeType.HTML and it resolved the issue. Although attachments were not at the same location as they all moved to the end of the body, but they were al least placed in a way that is readable.
The problem was with auto content conversion, when you set the body format to text and do not specify the HTML body. Exchange will generate a HTML copy of it automatically. This HTML generated copy does no render properly on the screen and attachment positions get changed which is rendered horribly in Outlook.
I thought it was just the last month full of bugs and fixes. This month also started with a Exchange Web Services bug.. or better Exchange Bug as Exchange Web Service is just a victim :(
If you add an attachment to a single occurrence of a recurring CalendarItem, and then call GetItem with AllProperties set to retrieve that occurrence, the attachment is returned but HasAttachments property is set to false. Not only that you cannot see the attachment in the OWA, but Outlook has no problem in showing that attachment.
You can reproduce the error this way...
1. Create recurring meeting from OWA 2007 , I created “Daily Recurrence” for 3 days
2. I worked on the first instance and checked that its same with all instances
3. Add an attachment from EWS
4. GetItem the first occurrence , HasAttachment = false but it is visible in OWA, Attachment can still be downloaded, if I ignore the has attachment flag and proceed towards attachments array
5. Added another attachment from EWS
6. GetItem the first occurrence , HasAttachment = true, both attachments can be downloaded fine using GetAttachment
7. Deleted second attachment from EWS
8. GetItem the first occurrence , HasAttachment = true, first Attachment can still be downloaded fine using GetAttachment
9. Deleted first attachment from EWS, attachment table is empty now
10. GetItem the first occurrence , HasAttachment = false
11. Added a new attachment from EWS
12. GetItem the first occurrence , HasAttachment = false but this time it’s not visible in OWA, first Attachment can still be downloaded, if I ignore the has attachment flag and proceed towards attachments array
13. Added another attachment from EWS
14. GetItem the first occurrence , HasAttachment = true, both attachments are visible now in OWA as well
Root cause is unknown at this time, but I have found a workaound. Product group is already working on a fix for this but it could take some time.
I have found a pattern by that you can workaround this problem.
Add two attachments instead of one, and delete the later one which will turn the first one visible. Funny logic but works!
Please ping me if you have the same problem.
Another bug, this month quite bugged me :) it was not only bad throat and viral fever which made me frustrated... but few product bugs in Exchange and Outlook. Well lets start with this one I found while working with one of the customer.
He was customizing Ribbon using VSTO SE for Outlook 2007. We noticed a strange behavior while sending emails from Word or Excel. The new mail inspector kept open even after the mail is sent, looks weird.
The problem is a simple VSTO add-in can use the GetVisibleCallback function to get notified when the RibbonX tab gets displayed. This callback function can be used to add/modify custom ribbon elements. If the callback function is implemented, and an outlook inspector will be opened outside of outlook (e.g. by sending a word document as email), the inspector remains open and does not close.
A hotfix is available for this but not publically, you need to call PSS and get a fix for this if this is bothering you. Hopefully this hotfix will be part of next Service Pack release of Outlook 2007
Please find the public KB for this bug. You can download the FIX from here : http://support.microsoft.com/kb/957692
Are you having hard time in adding WinHTTP.dll into Outlook 2007 VBA references on your Vista machine, so let me tell you that we are aware of it. The problem is shown below..
Look at the location part, which is for sure invalid path.
The root cause is the installation of this DLL into the registry.
Windows XP registry:
When we try to load winhttp on vista, we end up looking in c:\users\<username>\documents\%systemroot%\system32\winhttp.dll
Apparently VBA doesn’t understand this type of path.
Resolution: Change the path and the DLL loads.
Another option could be instead of adding a reference to Outlook use late binding and do a CreateObject call to WinHTTP.dll
You can also fix this with regsvr32 WinHTTP.DLL. The DLL registers the proper path - the bad path is actually part of Vista's install. :(
Incidentally - I think VS works around this issue by trying to expand the registry key even though it's not a REG_EXPAND_SZ. Didn't test it though.
Another fine day and some great timings. I was discussing this bug with product group hoping that it is not faced by anyone outside Microsoft and then the phone rings.... I am getting the following error while trying to do a FindFolder call on to Public Folders
Exception Type - System.InvalidOperationException Exception Message - Instance validation error: 'ErrorNoPublicFolderServerAvailable' is not a valid value for ResponseCodeType.
He had Exchange 2003 and Exchange 2007 running in Mixed mode in production environment where he was facing this error, though back on his test machine he could not reproduce his error message as the environment had only Exchange 2007.
He found a resolution himself by just shutting down the exchange 2003 machine for instance and it no longer throw the error message. So I came back to product group, asking for reasons. And it happened to be a bug in the product - Exchange 2007 SP1
They had migrated public folders from Exchange 2003 to Exchange 2007 Sp1, which actually caused the bug in message.xsd to trigger.
The error is possibly caused as there isn't a replica of the public folder content you're attempting to access on an Exchange 2007 server. So it's a configuration problem somewhere in your topology.
Product group may or may not hot-fix this issue in the next service pack release, they have already fixed this issue in next release of Exchange Server. I've got a workaround for you that I'd like you to try, if you can. It should get you around this problem. It has a big caveat, though, so please read through whole before you do anything.
The best way to work around this is:
If this solution can't work for you for some reason, please let me know.
Now, the caveat:
If you ever want to regenerate your proxy classes for any reason in the future (like a server upgrade, or for some other reason), you might have to make this same modification again. Note that I said "might." The reason for that is because if we deal with this issue server-side, that new response code may already exist in the new messages.xsd, or the returned response code from the server may change to ErrorNoPublicFolderReplicaAvailable instead of ErrorNoPublicFolderServerAvailable.