OfficeDev
ExchangeService.FindFolders with WellKnownFolderName.PublicFoldersRoot fails
Starting at 12th of April around 6:16pm AEST, calling FindFolders using a WellKnownFolderName.PublicFoldersRoot fails with a "Name cannot begin with the '<' character, hexadecimal value 0x3C. Line 1, position 1775." message. The xml body that we are sending looks like
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> soap:Header <t:RequestServerVersion Version="Exchange2013_SP1" /> <t:DateTimePrecision>Milliseconds</t:DateTimePrecision> <t:ExchangeImpersonation> <t:ConnectingSID> <t:SmtpAddress>[email protected]</t:SmtpAddress> </t:ConnectingSID> </t:ExchangeImpersonation> </soap:Header> soap:Body <m:FindFolder Traversal="Shallow"> <m:FolderShape> <t:BaseShape>IdOnly</t:BaseShape> <t:AdditionalProperties> <t:FieldURI FieldURI="folder:DisplayName" /> </t:AdditionalProperties> </m:FolderShape> <m:IndexedPageFolderView MaxEntriesReturned="100" Offset="0" BasePoint="Beginning" /> <m:ParentFolderIds> <t:DistinguishedFolderId Id="publicfoldersroot" /> </m:ParentFolderIds> </m:FindFolder> </soap:Body> </soap:Envelope>
Using fiddler to examine the response shows something like
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15" MinorVersion="20" MajorBuildNumber="6298"
MinorBuildNumber="30" Version="V2018_01_08"
xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />
</s:Header>
<s:Body>
<m:FindFolderResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:FindFolderResponseMessage ResponseClass="Success">
<m:ResponseCode>NoError</m:ResponseCode>
<m:RootFolder IndexedPagingOffset="1" TotalItemsInView="4" IncludesLastItemInRange="false">
<t:Folders>
<t:Folder>
<t:FolderId Id="<s:Envelope xmlns:s=" http:// schemas.xmlsoap.org/ soap/ envelope/"><s:Header><Action s:mustUnderstand=" 1" xmlns=" http:// schemas.microsoft.com/ ws/ 2005/ 05/ addressing/ none">*</Action></s:Header><s:Body><s:Fault>
This obviously isn't valid xml.
We haven't changed anything for this to start happening. It's been running multiple times a day for months without failure.
This is surely a problem with the https://outlook.office365.com/EWS/Exchange.asmx endpoint, but I thought I'd mention it here in case anyone can help!
Interestingly enough, this failed 27 times in a row and then we started seeing this issue. If we swap to using a different impersonated user (using oauthcredentials), we go back to getting the "Name cannot begin with the '<' character, hexadecimal value 0x3C. Line 1, position 1775." message. I'm not game enough to try enough times to get this user to hit the concurrency limit.
Yes, we've noticed exactly the same thing, including the subsequent "exceeded the available concurrent connections for your account" message after this problem has occurred enough times. This started on 6th April for us and 11th April at a client site. Tried updating our project using the EWS Managed API to the latest versions of Microsoft.Identity.Client and Microsoft.IdentityModel.Abstractions but this has made no difference.
It appears to read the list of folders and an error occurs on/after the last entry. When the error occurs it just whacks it in the XML in an invalid format causing the error we've identified. It looks to me like that error happens because on the server it has continued past 'EOF' - it's found the last identified folder in the list but tried to carry on doing things after that.
I face the same problem. Do we have a feedback from MS ?
One of our clients has raised a ticket with Msft but has not received a helpful reply yet.
Thought I'd try restricting the number of items returned by FindFolders using a FolderView with a PageSize of 1. Wondered if this would return the first item before encountering the error, but it just causes the error to occur on the first item. Also tried restricting the PropertySet to IdOnly but same problem.
Seeing this same error, started 4/12 around 7am EST. We have opened a ticket with MS as well.
I have posted about this on the Microsoft Q&A forum, as some googling suggested this may help get it spotted by the appropriate team. https://learn.microsoft.com/en-us/answers/questions/1229639/exchange-web-services-ews-findfolders-produces-a-5
We have the exact same issue as well. Is anyone at MS even responding to this?
MS knows about this issue and is investigating. Look at the response in code and strip the appended html page from the response as a temporary work around while they are working on the issue.
We are experiencing the same issue for the past week, trying to retrieve mails from public folders. It started with one tenant and is now also occurring on others.
Might be the same issue: https://admin.microsoft.com/Adminportal/Home#/servicehealth/:/alerts/EX540990
They are working on a fix for issues with OWA and EWS accessing public folders. One issue is with html/xml being in the response body of an EWS call against public folder. Another is with the EWSMaxConcurrency error being thrown when it should not be. They are working to a fix pushed out. It may take one to a few days before they have the fix pushed out. Check your portals late tonight for updates. Issues with mail delivery may be a different from what's happening in this event.
It looks like this started working again for us shortly after 16/04/2023 11:30PM AEST! Should I mark this as closed?
We also see resolution on one tenant at 15 April 1200 CST and another tenant at 16 April 1100
It's working for us now internally. Tried at a client site and immediately ran straight into the "Microsoft.Exchange.WebServices.Data.ServiceResponseException: You have exceeded the available concurrent connections for your account." error unfortunately! Still, the XML problem seems to be fixed at least!
Looked further into the client site still not working and realised this still has the original XML error. Originally at the client site it took an additional 5 days for the original problem to occur, so guess this related to how quickly the changes roll out to the various Office 365 tenants.