mstehle: The CDOs and CDONTS of Messaging Development : KB

KB: XML schema validation errors when Exchange Web Service requests and responses have invalid XML characters

mstehle — Fri, 13 Feb 2009 02:23:21 GMT

…I recently submitted the following KB article for publication but wanted to get the content out. I will update this post when the KB article is published…

SYMPTOMS

Scenario 1

When you submit an Exchange Web Services request to Microsoft Exchange Server 2007 that contains invalid XML characters, you may get the following ErrorSchemaValidation exception response:

“The request failed schema validation: [character], hexadecimal value [value], is an invalid character.”

Scenario 2

When you submit an Exchange Web Services request to Microsoft Exchange Server 2007 that returns item properties in the response containing invalid XML characters using the Visual Studio auto-generated proxy classes, you may get the following InvalidOperationException exception:

”There is an error in XML document”

“[character] hexadecimal value [value], is an invalid character.”

CAUSE

It is possible for Exchange item properties to have values that contain characters outside the valid range in the XML specification which is defined here:

http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-character

When an Exchange Web Services client makes a request to retrieve that item property, the Exchange server encodes the property values to ensure the response is transmittable. If this response is received by the client and subsequently validated against the XML schema, it will fail validation because of the invalid XML characters.

Conversely, if an Exchange Web Services client tries to send these characters in a request, even if they are encoded, the Exchange server will try and validate the request against the XML schema which will fail.

RESOLUTION

Scenario 1

There is no way to successfully post an Exchange Web Service request that contains invalid XML characters. If you are updating a property’s value that contains invalid characters you must decide whether to replace or omit these characters.

Scenario 2

In order to read Exchange Web Service responses from Microsoft Exchange Server 2007 that contain invalid XML characters, you should skip XML validation. If you are using the Visual Studio auto-generated proxy classes for Exchange Web Services then you can create a special partial class which overrides the GetReaderForMessage method of the ExchangeServiceBinding class which turns XML validation off:

public partial class MyExchangeServiceBinding: ExchangeServiceBinding
{
    protected overrideXmlReader GetReaderForMessage(
        SoapClientMessage message,
        int bufferSize)
    {
        XmlReader retval = base.GetReaderForMessage(
            message,
            bufferSize);

        XmlTextReader xrt = retval asXmlTextReader;

        if(null!= xrt)
        {
            xrt.Normalization = false;
        }

        returnretval;
    }
}

KB: Respond to Meeting Requests via the MeetingItem Interface in CDO 1.21

mstehle — Mon, 01 Oct 2007 17:17:00 GMT

...We'll be publishing a KB article to establish this support policy update on CDO 1.21. I'll update this post with KB number, in the meantime, here is the content of the article...

Calling the Respond method to accept or decline a meeting request using CDO 1.21 is only supported through the MeetingItem interface (http://msdn2.microsoft.com/en-us/library/ms527208.aspx). It is not supported to call Respond to a meeting through the AppointmentItem interface (http://msdn2.microsoft.com/en-us/library/ms526385.aspx) or by calling Respond on an AppointmentItem retrieved from the GetAssociatedAppointment call of the meeting request.

...This has to do with the logic implemented in CDO 1.21 to accomodate changes in the calendaring logic of Exchange and Outlook described in the following article, http://msdn2.microsoft.com/en-us/library/aa363947.aspx.

KB: Automation Error 0x8007007f when Invoking Exchange 2007 Powershell Cmdlets

mstehle — Tue, 03 Jul 2007 21:18:00 GMT

...Here are the details of a new KB article I just submitted. I will update this post when it is published...

Symptoms

When using CDOEXM to manage Exchange 2003 and Powershell cmdlets to manage Exchange 2007 in the same application you may come across the following error:

"Retrieving the COM class factory for component with CLSID {08D1AA55-704E-4397-AB29-55D2A3972BCB} failed due to the following error: 8007007f.”

This would typically be seen when calling Invoke on a System.Management.Automation Pipeline when automating a cmdlet such as Move-Mailbox.

…To indentify this issue use a couple simple WinDbg commands to identify if CDOEXM is loaded in the process and see where CDOEXM, EXCHMEM, and other dependencies are loading from as well as their version numbers. Here are some of the commands I used and what the output was in the traces I saw. Simply snap a hang dump or attach WinDbg to your application’s process and run these commands…

lmf – This command lists all the loaded modules and the file path they are loaded from. Look for CDOEXM and EXCHMEM to see if they have been loaded yet and if so where they are loading from. For Exchange 2000/2003 the path to Exchange components should be “C:\Program Files\exchsvr\bin” for Exchange 2007 it will be “C:\Program Files\Microsoft\Exchange Server\bin”.

lmvm [module name] – This will gives verbose output about a particular loaded module. Use this to get the version number and path for a particular module like EXCHMEM. Exchange 2000 binaries’ version numbers are 6.0.*, Exchange 2003 binaries are 6.5.*, and Exchange 2007 binaries are 8.0.*. Be sure that Exchange system modules like ESE, EXCHMEM, PTTRACE, ADDRESS, and GLBLNAME match the version of Exchange you are testing…

Cause

This is caused when Exchange 2003 System Manager and Exchange 2007 Management Console are installed on the same application server for an application that is intended to manage Exchange 2003 and Exchange 2007. Calls to Exchange 2003’s management API, CDOEXM, load the Exchange 2003 version of libraries such as EXCHMEM.dll into the application process. When the Exchange 2007 cmdlets are used they end up using the already loaded Exchange 2003 library. This causes the Exchange 2007 cmdlet to fail.

Resolution

To avoid this conflict Exchange 2003 CDOEXM should not be loaded in the same process where Exchange 2007 cmdlets will loaded or automated.

More Information

Exchange 2007 cmdlets should not be used to create or edit objects such as mailboxes or storage groups on an Exchange 2003 server. CDOEXM and Exchange 2003 System Manager should be used to manage these servers. For more information on managing Exchange 2003 in a coexistence environment with Exchange 2007 see the following articles on TechNet:

Managing Exchange 2003 Settings in a Coexistence Environment

http://technet.microsoft.com/en-us/library/aa995972.aspx

Planning for Coexistence

http://technet.microsoft.com/en-us/library/aa998186.aspx

For more information about automating Exchange 2007 Powershell cmdlets see the following article on MSDN:

Using Exchange Management Shell Commands With Managed Code

http://msdn2.microsoft.com/en-us/library/bb332449.aspx

KB: New Outlook 2007 Development KB Articles...

mstehle — Mon, 08 Jan 2007 22:59:00 GMT

With new versions of the product come new KB articles, make sure to take a look at this as you begin Outlook 2007 development...

929592 Known issues with developing Office Outlook 2007 form regions
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929592

929593 The known issues with the Microsoft Office Outlook 2007 object model
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929593

Update 1-15-2007...

Here is another KB article related to Outlook 2007 development...

929591 Known issues in Office Outlook 2007 when you use custom forms that were created by using earlier versions of Outlook
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929591

Update 1-17-2007...

Here is another...

929590 Known issues with the Office Outlook 2007 development platform
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929590

KB: 919169, Access Denied or 403 Forbidden When Creating Appointments in WebDAV/CDOEX

mstehle — Wed, 22 Nov 2006 00:00:00 GMT

I saw another case on this issue and remembered that I hadn't put this on my blog yet. If you are getting 403's when trying to create an appointment in another user's calendar using WebDAV or an access denied in CDOEX after installing our Send As hotfix (895949) then check out this article...

919169 You cannot save an appointment to another user's calendar by using CDOEX in Exchange Server 2003 after you apply hotfix 895949
http://support.microsoft.com/default.aspx?scid=kb;EN-US;919169

...You will have to open a support incident to get this hotfix....

Note from the article, "In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question."

...In other words you should not be charged for this case if it is opened solely for the purpose of getting the hotfix, any additional troubleshooting or help may incur a cost...

KB: You receive an error message when you try to send an e-mail message by using the System.Web.Mail namespace in the .NET Framework

mstehle — Wed, 08 Nov 2006 00:25:00 GMT

We have an article published now which addresses my earlier post about the myths regarding SmtpServer.Insert...

922777 You receive an error message when you try to send an e-mail message by using the System.Web.Mail namespace in the .NET Framework 1.0
http://support.microsoft.com/default.aspx?scid=kb;EN-US;922777

KB: Frequently asked questions about custom forms and Outlook solutions

mstehle — Fri, 14 Apr 2006 15:46:00 GMT

Since joining the Messaging Developer Support team last year, my main focus has been on Exchange development, rather than custom forms and Outlook programming. There are many "gotchas" in Outlook development that one must keep track of. Only someone who works with Outlook Object Model day in and day out for years could know off the top of their head half of the considerations one must take when programming in Outlook. The following KB article goes a long way to answer some of frequently asked questions and provide links to other important KB articles to look over when starting Outlook development...

287530 Frequently asked questions about custom forms and Outlook solutions
http://support.microsoft.com/default.aspx?scid=kb;EN-US;287530

KB: Outlook Object Model Limitations

mstehle — Mon, 12 Dec 2005 19:28:00 GMT

...I added a new category for this post called "KB" which is for noting KB articles that are new or important...

The Outlook Object Model does not provide full access to all the features of the application. The following KB article details some of the limitations of the object model.

294869 Description of limitations in Outlook object model
http://support.microsoft.com/default.aspx?scid=kb;EN-US;294869

...This article was written for Outlook 2003's version of the object model. It also provides links to some of the earlier versions of Outlook as well. It is always important to research the limitations of any API you choice to implement a messaging solution. Some of the other office products give you an API which will essentially give you access to everything the UI will. Outlook is not one of them...

...Another point that is not noted in the article is that the Outlook Object Model is only supported for interactive use and not in background processes. This means that OOM code is not supported in server side script in web pages or within a Windows service or COM+ component. If you need to use OOM in a web application it would have to be in client side script and preferrably in an ActiveX Control...