The ExecuteEwsProxy call
The ExecuteEwsProxy call servers as a means of sending through EWS requests from Mail Apps. The implementation of the ExecuteEwsProxy call can be reduced to six basic steps:
- The app post an ExecuteEwsProxy call to OWA (Frontend) (https://OWA_DNS_NAME:443/owa/service.svc?action=ExecuteEwsProxy)
- The Frontend proxies the request over to the Backend (https://BACKEND_FQDN:444/owa/service.svc?action=ExecuteEwsProxy)
- The Backend posts an EWS call to the Frontend (https://FRONTEND_FQDN:443/ews/Exchange.asmx)
- The Frontend proxies the request over to the Backend (https://BACKEND_FQDN:444/ews/Exchange.asmx)
- The Backend processes the request and sends through the response
- The Frontend posts the response to the Mail App (https://MAIL_APP_URL:443/owa/service.svc?action=ExecuteEwsProxy)
If any of these steps fail, the Mail App will not display a result or will return an error based on the implementation of the code calling makeEwsRequestAsync (this call results in the ExecuteEwsProxy call being sent).
What you need in order to troubleshoot the ExecuteEwsProxy failures
In order to troubleshoot any issues related to this call you will need to collect and analyse the following elements:
- An F12 (Developer Tools) network capture in IE or a Fiddler trace
- The W3SVC1 IIS logs on the Exchange 2013 Client Access server (C:\Inetpub\Logs\Logfiles\W3SVC1)
- The Ews and Owa HttpProxy logs on the Exchange 2013 Client Access server (C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy – Owa and Ews folders)
- The W3SVC2 IIS logs on the Exchange 2013 Mailbox server (C:\Inetpub\Logs\Logfiles\W3SVC2)
- The Ews logs on the target Exchange 2013 Mailbox server (C:\Program Files\Microsoft\Exchange Server\V15\Logging\Ews)
How to determine whether the call is failing
In order to determine whether an ExecuteEwsProxy call is successful you can use either the F12 Developer Tools network capture feature in Internet Explorer or a Fiddler trace.
If the call fails for any reason, you will see a Result code other than 200, or no result at all in the network capture.
To identify the cause of the failure, you can switch to the details tab in the F12 Network menu. A successful call will be similar to the one in the screenshot below. For a failed call you will see a different StatusCode (for example 401) and an error message in the Response body.
What to look for in the logs
To start tracing the call, look for an ExecuteEwsProxy request in the W3SVC1 IIS log of the Exchange 2013 Client Access server. This should be similar to:
Make a note of the cafeReqId as this is the request Id that we will be tracing all throughout the logs.
Tools you can use
You can use LogParserStudio to lookup the log entries with these simple queries:
SELECT * FROM ‘[LOGFILEPATH]’
WHERE cs-uri-query LIKE ‘%REQUEST_ID%’ – where REQUEST_ID is the cafeReqId corresponding to the ExecuteEwsProxy call that we are trying to trace.
HttpProxy and Ews logs:
SELECT * FROM ‘[LOGFILEPATH]’
WHERE RequestId LIKE ‘%REQUEST_ID%’ – where REQUEST_ID is the cafeReqId corresponding to the ExecuteEwsProxy call that we are trying to trace.
In my lab I’ve configured an Exchange 2013 Client Access server and an Exchange 2013 Mailbox server as follows:
|Information||Client Access Server||Mailbox Server|
Where mail.zone.lab is a cname record for zone-ex-01.zone.lab.
- Step 1: Client Access Server W3SVC1 IIS log
- Step 2: Client Access Server HttpProxy Owa log
- Step 3: Mailbox Server W3SVC2 IIS log
- Step 4: Client Access Server W3SVC1 IIS Log
- Step 5: Client Access Server HttpProxy Ews log
- Step 6: Mailbox Server Ews log
Please see the attached image for the actual log entries corresponding to the steps above.
What to do if you find problems with any of these calls
If you find that any of these calls fail based on the HTTP response codes or the information in the GenericInfo column, you can either try and figure it out yourself or you could raise a support case with Microsoft in order to perform a more advanced analysis of the problem.
Let us not forget name resolution
If you’ve specified a URL in the Mail App xml manifest, you need to make sure that that URL can be resolved by the backend. For example, in my lab I’ve set the following source location for the Mail App.
If mail.zone.lab can’t be resolved by the backend then I will get the following error: “Failed to make a request via HttpWebRequest. Exception: The remote name could not be resolved: ‘mail.zone.lab’”.
If the name can indeed be resolved but it’s for some reason not accessible from the backend (say it’s available from the Internet but not the Intranet)) then I will get the following error: “Failed to make a request via HttpWebRequest. Exception: Unable to connect to the remote server".
To conclude: You need to make sure that the source location that you’ve defined in your Mail App manifest is accessible from the backend server.