Tools and resources for troubleshooting EWS applications for Exchange
Find resources to help you troubleshoot your EWS Managed API or EWS application.
Things don't always go as planned. Sometimes EWS requests fail, or provide unexpected results. This can be frustrating, especially if the reason isn't obvious. Hopefully this never happens to you, but if it does, this article provides information about tools and resources that you can use to help troubleshoot your problem.
This article provides general troubleshooting advice and sources for troubleshooting information. Unfortunately it isn't possible to give detailed troubleshooting steps. For assistance troubleshooting your specific error, see Next steps.
Examine the SOAP requests and responses
When things aren't working correctly, it really helps to be able to see what's going on. The first line of inquiry when investigating a problem with EWS or the EWS Managed API is to examine the requests that your application is sending over the network and the responses that the server is sending back.
The EWS Managed API makes examining SOAP requests and responses easy with its built in tracing functionality. If you are using EWS, you might or might not have access to similar tracing functionality, depending on what platform or classes you use to send your requests. However, you can always use a network tracing tool like Network Monitor or Fiddler to examine the network traffic and view the request and response payloads.
Additionally, you can instrument your client requests to enhance the information available in requests and responses.
After you have the requests and responses, ask yourself the following: Do they look correct? Are the values that your application is sending expected? Do the responses make sense?
Examine error codes
Sometimes the error code can go a long way toward pinpointing the problem, even if at first glance it doesn't seem to make sense. Does the error indicate that your client is being throttled? Perhaps a call to Autodiscover to refresh configuration information is in order?
For more information about handling specific errors, see the following articles:
There are a number of different components involved in EWS operations, and the versions of those components can influence the results.
Table 1. Versioned components that can affect EWS processes
|Component||EWS Managed API||EWS||Notes|
|Requested server version
||This value controls which version of the EWS schema is used to process the EWS request. Make sure that the schema version specified here makes sense for the request you are sending. Some properties and operations are not available in earlier versions of the schema.
|The server version
||This value is returned by the server in EWS responses, and indicates the version of the server that processed the response. Make sure this value is what you expect. If possible, make sure that the Exchange server is running the most recent update for your major version of Exchange.
|The EWS Managed API version
||The Product version property of the Microsoft.Exchange.WebServices.dll file.
||If you're using the EWS Managed API, make sure that you are using the most recent version.
EWS is enabled by default, but defaults can be changed. Use the Get-OrganizationConfig cmdlet to make sure that EWS is enabled on the server, and the Get-CASMailbox cmdlet to make sure that EWS is enabled for the user's mailbox. Also check both cmdlet responses for an EWS allow or block list, and make sure that your application isn't blocked from using EWS.
You should also verify that the default authentication settings on the EWS virtual directory have not been modified.
Try another EWS client
Sometimes it is helpful to try the same request from another client and compare results. If another client gets different results, what is different? Figuring out what is different between a successful request and a failed request can help explain why a particular request is failing.
While you can certainly write another client to test with, you don't have to! EWSEditor is a sample client that uses the EWS Managed API and EWS. You can download the client (including the source code) and use it to try the same requests that are failing in your application.
Examine IIS logs
If you have access to the Exchange server, the logging functionality provided by Internet Information Services (IIS) on the Client Access servers can provide more information about failures. However, keep in mind that IIS logs will only be helpful if you are receiving an HTTP error.
Now that you've learned about the tools and resources that you can use to troubleshoot, you might need help understanding the information provided by those tools. The following are some options for getting help:
Exchange Server Development forum on MSDN — Ask a question of the MSDN Exchange Server development community.
StackOverflow — Ask a question of the StackOverflow community. Be sure to tag your post with "ews".
Microsoft Support — Contact a Microsoft support professional for assistance.
See the following articles:
Download the following: