IIS Application Request Routing (Part 4)

by [Published on 1 Oct. 2013 / Last Updated on 1 Oct. 2013]

In this final article, we will see how to monitor servers in the farm and how to troubleshoot Application Request Routing.

If you would like to read the other parts in this article series please go to:

Introduction

In this article series, the author is exploring the use of IIS Application Request Routing to publish Exchange 2013 services such as Outlook Web App out to the Internet. So far we saw what IIS Application Request Routing is, how it works, how to install it and went through configuring it to publish Outlook Web App out to the Internet. In this final article, we will see how to monitor servers in the farm and how to troubleshoot Application Request Routing.

Monitoring and Statistics

As we previously saw, we can use the Monitoring and Management page to view runtime statistics regarding all the servers in the Application Request Routing (ARR) farm:

Image
Figure 4.1: Application Request Routing - Monitoring and Management

In this page, ARR presents administrators with the following statistics for all the servers in the farm:

Element Name

Description

Server

Displays the name or the IP address of the server.

Availability

Displays the status of the server, which can be Available, Unavailable, or Drain.

Health Status

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.

Current Requests

Displays the number of requests that are currently being sent to the server.

Total Requests

Displays the total number of requests that were sent to the server.

Failed Requests

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.

Table 1

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.

Troubleshooting

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:

Image
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:

Image
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:

  1. Launch IIS Manager;
  2. Select the Default Web Site:

Image
Figure 4.4:
Select the Default Web Site

  1. In the Actions pane, under Configure, select Failed Request Tracing...:

Image
Figure 4.5:
Click on Failed Request Tracing...

  1. 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):

Image
Figure 4.6:
Enable Failed Request Tracing

  1. Click OK to save the changes;
  2. Select the Default Web Site;
  3. Double-click Failed Request Tracing Rules:

Image
Figure 4.7:
IIS Failed Request Tracing Rules

  1. In the Actions pane, click Add... to create a new Failed Request Tracing Rule;
  2. Select All content (*) and then click Next:

Image
Figure 4.8:
Add Failed Request Tracing Rule – Content to Trace

  1. Next select the HTTP status codes you want to capture for analysis. In this scenario, I am capturing 200-399 for demonstration purposes:

Image
Figure 4.9:
Add Failed Request Tracing Rule – Trace Conditions

  1. Click Next. The above configuration creates a Failed Request Tracing Rule that writes traces when the status code falls between 200 and 399;
  2. 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):

Image
Figure 4.10:
Add Failed Request Tracing Rule – Trace Providers

  1. Click Finish.
  2. In the main screen you will see the rule we just created:

Image
Figure 4.11:
Failed Request Tracing Rule Created

To view the Failed Request Tracing logs follow these instructions:

  1. Navigate to the directory where the Failed Request Tracing logs are written. By default the location is %SystemDrive%\inetpub\Logs\FailedReqLogFiles;
  2. Change directory to the folder that matches the Default Web Site. By default, this is W3SVC1;
  3. If there are any xml files, remove them;
  4. 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;
  5. List the files in the directory to confirm that new xml files were created:

Image
Figure 4.12:
Failed Request Tracing Logs Folder

  1. Open an xml file:

Image
Figure 4.13:
Failed Request Tracing Log - Summary

  1. 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:

Image
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:

Image
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.

Conclusion

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:

Advertisement

Featured Links