Exchange Request Tracing
I came across a very strange Exchange behavior the other day while troubleshooting a full access permission that was not working as expected.
Although a user had been granted the full mailbox permission on a shared mailbox, when he tried to open it using OWA, he got an HTTP Error 500 message and the request failed.
We'll start troubleshooting with investigating the front end IIS log files. After all, that is the first step of the request processing.
Using the user's UserPrincipalName, I've managed to find the error in the log:
As you can see, the HTML error code is "500" that indicates an internal server error similar to the one that the user encountered. This file however does not provide much information about the cause of the error so we'll take a look on the backend as well.
After each request reaches the front end Exchange layer, it is proxied to the back end but the destination server may be other that the front end server that receivced it. To find out to which back end server the request was sent, we are going to search the HttpProxy log. Those files are stored in the "HttpProxy" folder in the Exchange Logging directory and there is a seperate folder for each protocol (OWA, EAS, etc.).
Copy the request id from the front end log and search the logs:
As you can see, the request failed because there are multiple objects configured with the same email address.
If the request had been proxied successfully to another server's back end, we would know the name of the server from the HttpProxy log and thus we would be able to investigate the backend IIS logs with the request id for further information.
Although a user had been granted the full mailbox permission on a shared mailbox, when he tried to open it using OWA, he got an HTTP Error 500 message and the request failed.
We'll start troubleshooting with investigating the front end IIS log files. After all, that is the first step of the request processing.
Using the user's UserPrincipalName, I've managed to find the error in the log:
As you can see, the HTML error code is "500" that indicates an internal server error similar to the one that the user encountered. This file however does not provide much information about the cause of the error so we'll take a look on the backend as well.
After each request reaches the front end Exchange layer, it is proxied to the back end but the destination server may be other that the front end server that receivced it. To find out to which back end server the request was sent, we are going to search the HttpProxy log. Those files are stored in the "HttpProxy" folder in the Exchange Logging directory and there is a seperate folder for each protocol (OWA, EAS, etc.).
Copy the request id from the front end log and search the logs:
As you can see, the request failed because there are multiple objects configured with the same email address.
If the request had been proxied successfully to another server's back end, we would know the name of the server from the HttpProxy log and thus we would be able to investigate the backend IIS logs with the request id for further information.
