ExchangeImpersonation SOAP header must not exist for this type of OAuth token.

[wbrussell]

I started getting this error sporadically today. Code has been same for several years. I'm using basic auth and using impersonation to read resource mailbox schedules. I'm not using OAUTH for authentication.

``<Trace Tag="EwsResponse" Tid="37" Time="2018-10-30 17:00:18Z" Version="2.2.0.1">

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Body> <s:Fault> a:ErrorInvalidExchangeImpersonationHeaderData ExchangeImpersonation SOAP header must not exist for this type of OAuth token. <e:ResponseCode xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorInvalidExchangeImpersonationHeaderData</e:ResponseCode> <e:Message xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ExchangeImpersonation SOAP header must not exist for this type of OAuth token.</e:Message> </s:Fault> </s:Body> </s:Envelope> </Trace>

[pkropachev]

Looks like something wrong on Microsoft side. Check the recommendations by this link.

[XtremeOwnageDotCom]

This issue popped up for me over the weekend. Again, my code has not been changed in years. And nothing would have been changed at 1:30am Sat/Sun.

[davster]

This happens when a request lands on the incorrect server, typically when the service account is in a different forest than the target mailbox. In that case, EWS needs to proxy the request over to the correct forest to fulfill the request, but in doing so puts the request in a state where the destination server is unhappy with the format of the request. For cross-forest requests, EWS talks OAuth to the other server which is where the OAuth thing comes into play. We have a fix that we are rolling out now when we hit that condition, but to avoid getting into that condition in the first place, make sure your EWS client app uses the X-AnchorMailbox header so that the request gets routed to the correct backend server.

That is best practice for EWS anyways.

[wbrussell]

I believe I'm already setting the X-AnchorMailbox header, but I'll double-check.

[XtremeOwnageDotCom]

X-AnchorMailbox did resolve most of my issues a few days ago.

Now, If I can get this error (also new) ironed out, I will be doing good again.

The specified object was not found in the store., Can't connect to the mailbox of user Mailbox database guid: f22f50f7-01b4-4b6a-a477-82414f55a9dd because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently.

[vlw007]

We are still having this issue: Can't connect to the mailbox of user Mailbox database guid: f22f50f7-01b4-4b6a-a477-82414f55a9dd because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently.

[XtremeOwnageDotCom]

The issues "magically" self-resolved for me... for this issue "because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently."

[XtremeOwnageDotCom]

As an update on my end,

The issues "magically" came back over the weekend. I am reopening my ticket with Microsoft support.

Edit- Issue is also affected a few other o365 services, such as teams. I don't think this is an issue related to this library, but, instead, related to something inside of the o365 infrastructure.

[XtremeOwnageDotCom]

For the other error, the resolution is pretty simple. This is from Microsoft:

if (attendee.Id != null) { attendee.Id = null; }

Here is the explanation from the Microsoft support engineers:

"After further reviewing the Fiddler trace the Product Engineering team determined what is causing the issue.

The scenario is you are trying to copy properties from meetings that resides in mailbox A to the mailbox B. Mailbox A and Mailbox B are in different EXO forests, but same tenant. Mailbox A created meeting and added attendees, one of the attendees is contact from Mailbox A contacts folder and contains ID which points to Mailbox A folder.

When meeting invite is being copied over to Mailbox B, for that particular contact it tries to translate ID and does cross forest ConvertId call and tries to open store of Mailbox A. This call is failing as such request currently is not supported. Here is contact that was added from GAL to Mailbox A contact folder: "

[XtremeOwnageDotCom]

To summarize this entire issue (And provide resolutions for both exceptions)

Occasionally in office 365, mailboxes move between forests. This causes a lot of issues.

For the first exception "ExchangeImpersonation SOAP header must not exist for this type of OAuth token.", this is resolved by ensuring the "X-AnchorMailbox" header is implemented. This directs the services to look in the proper forest.

For the second issue, "Can't connect to the mailbox of user Mailbox database guid: f22f50f7-01b4-4b6a-a477-82414f55a9dd because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently."

This happens when you try to reference a contact, which is in another forest. That API call is unsupported between forests. To resolve this, when you are dealing with attendees on an appointment, set the Attendee Id to null. This forces the server side to resolve the object from the GAL, instead of attempting to access the contact (which resides in another forest).

Those were my understandings of the cause, and resolution of all of the issues in this thread.

Thanks to the Microsoft support engineers who assisted me with tracking down, and resolving these issues (Despite this being somebody else's issue)