EWS with oAuth "An internal server error occurred. The operation failed."

[MichaelDenmark]

Hi...

Since yesterday, my synchronization application starts throwing exceptions with the following error

"An internal server error occurred. The operation failed."

It only happen for mailboxes when I authenticatate with oAuth (CreateWithApplicationOptions).

Has anyone experienced the same and found a solution?

Tracing the call:

<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>
<faultcode xmlns:a="http://schemas.microsoft.com/exchange/services/2006/types">a:ErrorInternalServerError</faultcode>
<faultstring xml:lang="en-US">An internal server error occurred. The operation failed.</faultstring>
<detail>
<e:ResponseCode xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorInternalServerError</e:ResponseCode>
<e:Message xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">An internal server error occurred. The operation failed.</e:Message>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

[#2]

I've found out that the problem can be solved by added a header after setting ImpersonalteUserId

service.HttpHeaders.Add("X-AnchorMailbox", mailbox.Mailbox);

[#3]

Thanks for sharing. This solved our issue as well

[#4]

This also resolved it for us.
The error message is extremely unhelpful and why is it needed is a mystery, but al least it's solved.

[#5]

Same here, thanks so much for posting. I wish there were another way to access the Exchange Online public folders programmatically ...

[#6]

We have similar problem these days. Getting back the same error which tell nothing.

However, we already use the header "X-AnchorMailbox". Strange is that the error is not permanent but occurs occasionally (these days quite often).  Retry after few minutes usually passes.

[#7]

We also already use `X-AnchorMailbox` and still get the same errors.

[#8]

Also using the x-anchorMailbox, and still getting the same problem.  It is erroring on the finditems call.  

</Trace>
2022-08-26 09:29:45.399 [(T06) VSLLC:RestoreArchive:AsProcess08:Schedule(10):Exch] - [TraceFlags.EwsResponse]
<Trace Tag="EwsResponse" Tid="6" Time="2022-08-26 14:29:45Z" Version="15.00.0913.015">
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15" MinorVersion="20" MajorBuildNumber="5588" MinorBuildNumber="3" 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:FindItemResponse 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:FindItemResponseMessage ResponseClass="Error">
<m:MessageText>The mailbox operation failed.</m:MessageText>
<m:ResponseCode>ErrorInternalServerError</m:ResponseCode>
<m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
</m:FindItemResponseMessage>
</m:ResponseMessages>
</m:FindItemResponse>
</s:Body>
</s:Envelope>
</Trace>

[#9]

Same here, we are already using:

ewsClient.HttpHeaders.Add("X-AnchorMailbox", "{emailAddress}")

We've been getting this error for a few days now:

"Microsoft.Exchange.WebServices.Data.ServiceResponseException: An internal server error occurred. The operation failed."

It happens when calling the function:

ewsClient.ResolveName(searchStr, ResolveNameSearchLocation.DirectoryOnly, True)

The console application is running from an Azure VM.

The strange thing is, when I run the same application from my laptop locally, it works. No error.

@MichaelDenmark 

[#10]

Same error here, but only intermittently. Odd that it cropped up seemingly just this week.

[#11]

i am getting same error as well. I already include the header for the impersonated mailbox. 

It is intermittent but often enough that it is a serious problem. 

please post back if you find a solution.  

[#12]

Switching to Basic Auth with Application Impersonation is a temporary workaround for us.

[#13]

@MichaelDenmark 
We are experiencing the same. Logs in our product show that this error had a surge over the past week. Seems like a problem with MS.

[#14]

We have the same error-rates in our product:

[#15]

Our QA team has noticed this problem happening recently as well (started reporting Aug 29, 2022 but it probably started earlier than that).  The issue is still ongoing for us.  

[#16]

Same thing here. We have multiple customers reporting this and we have experienced it ourselves. One customer elected to go back to UserID/Password, but that will only work until 10/1. We need an answer/update from Microsoft....

[#17]

I have the same issue.
And I discovered null prefix in token string in trace of EwsRequest:

...wsse:Security soap:mustUnderstand='1'> nulleyJ0eXAiOiJK...

[#18]

This error has stopped happening for us this week.  QA has verified that it is no longer occurring over multiple days.  We made no change on our side, so it was definitely a change on the Microsoft side which caused it and resolved it.  

[#19]

@MikeCoop   I am alos getting the same error. Its working locally and getting this issue on server randomly.  I will suggest you to open a ticket on microsoft.

[#20]

@MichaelDenmark

We have fixed this problem:

1. Get token with scope - `https://outlook.office365.com/EWS.AccessAsUser.All` 

2. Add the token to headers:

var service = new ExchangeService(ExchangeVersion.Exchange2010_SP2);
service.setUrl(URI.create("https://outlook.office365.com/ews/exchange.asmx"));
service.getHttpHeaders().put("Authorization", "Bearer " + token);