App Impersonation is randomly failing

[vlw007]

App Impersonation has been working for the last few year. However, now we see random errors on several tenants. It will work ok for 100 mailboxes, than fail for the next. One hour later, it will work for the same mailbox which just failed.

It is effecting about 5% of our tenants and they have no management scopes defined.

This started happening on January 20.
Is anyone else seeing App Impersonation errors for mailboxes that were once working ?

[pkropachev]

Not sure that problem is in EWS API. Do you use Office 365? Have you contacted with Microsoft Support?

[alex3683]

I don't know if its the same issue, but I also experienced that for some customers (using o365) application impersonation does no longer work for some accounts. The server responds with a status code 500 and this body:

<Trace Tag="EwsResponse" Tid="29" Time="2019-05-27 07:07:55Z" Version="0.0.0.0">
  <?xml version="1.0" encoding="utf-8"?>
  <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
      <s:Fault>
        <faultcode xmlns:a="http://schemas.microsoft.com/exchange/services/2006/types">a:ErrorImpersonateUserDenied</faultcode>
        <faultstring xml:lang="en-US">The account does not have permission to impersonate the requested user.</faultstring>
        <detail>
          <e:ResponseCode xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">ErrorImpersonateUserDenied</e:ResponseCode>
          <e:Message xmlns:e="http://schemas.microsoft.com/exchange/services/2006/errors">The account does not have permission to impersonate the requested user.</e:Message>
        </detail>
      </s:Fault>
    </s:Body>
  </s:Envelope>
</Trace>

The user has the ApplicationImpersonation role without any management scopes. The strange thing is, the connectivity tester works using the same user accounts (requested mailbox and impersonating user). The only difference I could see in the requests is, that the connectivity tester sends a primary smtp address configuration as ConnectigSID (<t:PrimarySmtpAddress>...@...</t:PrimarySmtpAddress>), while EWS managed api doesn't even offer this type and hence sends a simple smtp address instead (<t:SmtpAddress>...@...</t:SmtpAddress>). I don't know if this would change something, but it's the only deviation I could find.

[alex3683]

Nevermind, my issue was resolved when setting the X-AnchorMailbox header for the according requests as mentioned here: https://blogs.msdn.microsoft.com/webdav_101/2015/05/11/best-practices-ews-authentication-and-access-issues/ Would be great to have the EWS API automatically do this when doing impersonation with an smtp address.