Displays the name or the IP address of the server.
Displays the status of the server, which can be Available, Unavailable, or Drain.
Displays the health status of the server, which can be either Healthy or Unhealthy. Requests are not routed to unhealthy servers.
Requests per Second
Displays the number of requests per second that are sent to the server.
Response Time (ms)
Displays the response time, in milliseconds, that it takes for a server to respond.
Displays the number of requests that are currently being sent to the server.
Displays the total number of requests that were sent to the server.
Displays the number of requests that failed, including requests that are a result of a connection error or a status code that matches a live traffic failure code.
Request Size (KB)
Displays the cumulative amount, in kilobytes, of the requests sent to the server.
Request Distribution (%)
Displays the percentage of requests that are distributed to the server based on the total number of requests.
Response Size (KB)
Displays the cumulative amount, in kilobytes, of the responses received from the server.
Load Balance Weight (%)
Displays the relative weights that have been configured for each server.
In the screen above, we can see that no requests are being forwarded to the second server in the farm as this server is in an Unhealthy state. We can also see, amongst other statistics, that there is currently one user connected to the first server and that this server has serviced 133 requests since the runtime statistics have last been cleared.
As with everything in the world of IT, unfortunately something eventually goes wrong. If this is the case and ARR is not working as you would expect it to, here are some things you can do or check:
- Ensure that you can reach your content servers, in this case Exchange OWA, from ARR. If the ARR server cannot reach OWA, then no request that goes through it will work;
- If you are having problems with certificates or SSL offloading, make sure ARR has the certificates used by Exchange, including your internal CA root certificate. As this server will probably not be domain-joined, you need to manually add it. Also check that the certificate(s) you use have all the right names added as a Subject Alternative Name;
- For troubleshooting, start by checking the IIS log on the ARR server (located by default in: %SystemDrive%\inetpub\logs\LogFiles\W3SVC1). In this log you should see all the requests that have passed through ARR:
Figure 4.2: Application Request Routing IIS Log
To see what ARR is doing under the hood we can configure Failed Request Tracing Rules. This feature creates XML trace files in the default folder of: %SystemDrive%\inetpub\logs\FailedReqLogFiles. This folder is empty by default:
Figure 4.3: Failed Request Tracing Rules Default Folder
Failed Request Tracing Rules is a powerful tool for troubleshooting request-processing failures in IIS. To configure it:
- Launch IIS Manager;
- Select the Default Web Site:
Figure 4.4: Select the Default Web Site
- In the Actions pane, under Configure, select Failed Request Tracing…:
Figure 4.5: Click on Failed Request Tracing…
- In the Edit Web Site Failed Request Tracing Settings dialog box, check the Enable checkbox and chose where you want to save the log files (the default folder is %SystemDrive%\inetpub\logs\FailedReqLogFiles):
Figure 4.6: Enable Failed Request Tracing
- Click OK to save the changes;
- Select the Default Web Site;
- Double-click Failed Request Tracing Rules:
Figure 4.7: IIS Failed Request Tracing Rules
- In the Actions pane, click Add… to create a new Failed Request Tracing Rule;
- Select All content (*) and then click Next:
Figure 4.8: Add Failed Request Tracing Rule – Content to Trace
- Next select the HTTP status codes you want to capture for analysis. In this scenario, I am capturing 200-399 for demonstration purposes:
Figure 4.9: Add Failed Request Tracing Rule – Trace Conditions
- Click Next. The above configuration creates a Failed Request Tracing Rule that writes traces when the status code falls between 200 and 399;
- Deselect ASP and ISAPI Extension. After selecting WWW Server, deselect everything under Areas with the exception of Rewrite and RequestRouting. Since ARR relies on the URL Rewrite module to inspect incoming requests, it is recommended that you enable the traces for both Application Request Routing (RequestRouting) and URL Rewrite module (Rewrite):
Figure 4.10: Add Failed Request Tracing Rule – Trace Providers
- Click Finish.
- In the main screen you will see the rule we just created:
Figure 4.11: Failed Request Tracing Rule Created
To view the Failed Request Tracing logs follow these instructions:
- Navigate to the directory where the Failed Request Tracing logs are written. By default the location is %SystemDrive%\inetpub\Logs\FailedReqLogFiles;
- Change directory to the folder that matches the Default Web Site. By default, this is W3SVC1;
- If there are any xml files, remove them;
- Send a request to Application Request Routing (in this case to Outlook Web App). If ARR is functioning correctly, it results in a 200 response, which falls within the 200 to 399 range that was specified previously (Figure 4.9). This should generate some logs in the location above;
- List the files in the directory to confirm that new xml files were created:
Figure 4.12: Failed Request Tracing Logs Folder
- Open an xml file:
Figure 4.13: Failed Request Tracing Log – Summary
- Click Request Details. Select Complete Request Trace and then click on Expand All if necessary. Below is an example of a Failed Request Tracing log for an OWA request:
Figure 4.14: Failed Request Tracing Log – Details
The following sections provide useful information:
- WebFarm: indicates the name of the server group to where the request is routed;
- Algorithm: indicates which load balance algorithm is used;
- RoutingReason: indicates the decision behind why the server is selected;
- Server: indicates the destination server to where the request is routed;
- State: availability of the destination server;
- TotalRequests: runtime statistic on how many requests have been sent to this server;
- FailedRequests: runtime statistic on how many failed requests have been sent to this server;
- CurrentRequests: runtime statistic on the concurrent number of HTTP requests to this server;
- BytesSent: runtime statistic on how much data in KB have been sent to this server;
- BytesReceived: runtime statistic on how much data in KB have been received from this server;
- ResponseTime: runtime statistic on the responsiveness in milliseconds of this server;
Under GENERAL_SET_REQUEST_HEADER we can see a few headers, including the X-Forwarded-For that we configured in the Proxy settings of the farm (Figure 2.15). Here we can see that the request came from the IP address 192.168.1.2 which is the IP of the client machine used.
We can also see some details regarding the certificate used under the X-ARR-SSL header name:
Figure 4.15: Failed Request Tracing Log – Details 2
If you are collecting the Failed Request Tracing logs on a Windows server core, you must copy the log files with the freb.xsl stylesheet to another computer where a browser is available.
In this article series, we explored the use of IIS Application Request Routing to publish Exchange services such as Outlook Web App out to the Internet. Although not yet supported in a production environment, Application Request Routing works great with Exchange, Lync and Office Web Apps Server for example.
If you would like to read the other parts in this article series please go to:
- IIS Application Request Routing (Part 1)
- IIS Application Request Routing (Part 2)
- IIS Application Request Routing (Part 3)