編輯

共用方式為

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.

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.

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:

Verify versions

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.

Verify access

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.

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.

Next steps

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:

See also

See the following articles:

Download the following: