Tools and resources for troubleshooting EWS applications for Exchange

Exchange

Find resources to help you troubleshoot your EWS Managed API or EWS application.

Last modified: September 25, 2014

Applies to: EWS Managed API | Exchange Online | Exchange Server 2013 | Office 365

In this article
Examine the SOAP requests and responses
Examine error codes
Verify versions
Verify access
Try another EWS client
Examine IIS logs
Next steps
Additional resources

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.

Note Note

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.

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?

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

ExchangeServiceBase.RequestedServerVersion property

RequestServerVersion element

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

ExchangeServiceBase.ServerInfo property

ServerVersionInfo element

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.

Not applicable

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.

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.

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.

IIS provides two different logging methods: IIS logging and failed requests tracing. To work with IIS logs, you can use Log Parser Studio, which includes a number of built-in EWS queries.

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:

Show:
© 2015 Microsoft