This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 69%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
I have an application that connects to Exchange through EWS using Application Impersonation to access multiple mailboxes. This was working fine with Exchange 2016. I have added an Exchange 2019 server to the environment, and moved most mailboxes over. The application is now pointed to the 2019 server, and having some issues. Looking through the EWS and HTTPProxy logs, I see that the 2019 server is proxying some of the EWS traffic to the 2016 server, and that's when the application fails. I see "ErrorNoRespondingCASInDestinationSite" and "Exchange Web Services are not currently available for this request because none of the Client Access Servers in the destination site could process the request" in the EWS logs on the 2016 server.
Does anyone know why Exchange 2016 would be responding this way?
Is there a way to stop the Exchange 2019 server from proxying this traffic to the Exchange 2016 server?
Thank you
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 22%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKY%3C/text%3E%3C/svg%3E)
Hi, @JaseL
According to this blog: Best Practices - EWS Authentication and Access Issues
the X-AnchorMailbox header is necessary.
There is also a thread in the similar situation for your reference: EWS returning 500 error, "ErrorNoRespondingCASInDestinationSite"
(Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.)
Thanks, but unfortunately, I have no control over the header.
I still don't understand why Exchange 2019 proxies the traffic to the Exchange 2016 server, when the mailbox exists on the 2019 server.
I also don't understand why the Exchange 2016 server can't handle the request. Can EWS requests only be handled by the server that hosts the mailbox?
Thank you
Does the application use server name directly? Or does it use autodiscover to find the server?
Hi, @JaseL
I am writing here to confirm with you how thing going now?
Did the issue get resolved?
The application uses the server name directly.
I believe I have resolved the issue. The account used for impersonation did not have a mailbox. The original instructions for the application specifically stated not to create a mailbox for the account. I reviewed a newer revision of the instructions, and they now state that a mailbox may be needed for newer versions of Exchange. So, it seems that Exchange 2019 needs the impersonation account to have a mailbox. Since creating a mailbox, I have not seen any traffic proxied to the 2016 server, and the application is working fine.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(294.40000000000003, 84%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGS%3C/text%3E%3C/svg%3E)
Are you setting the X-AnchorMailbox header in your application (to the target mailbox) this is what generally has the most bearing of how EWS request will be routed
Thanks for that information. No, there is no way to set this in the application.
You probably need to go back the the application developer and ask them to add that, it should be a one line change in the code base. Not sure why it proxying but if the account your using to do the impersonation is also mailbox enabled and that Mailbox in sitting on the 2016 side that may explain it so moving that mailbox to 2019 might help (but I'm just guessing here)
The impersonation account is on the 2019 server, with the mailboxes it is accessing, so this is odd to me.