BLOG ������

Windows Server 2012 - IIS Application Request Routing

Introduction

Publishing Exchange services such as Outlook Web App (OWA), ActiveSync (EAS) and Outlook Anywhere out to the Internet has always been something that administrators usually get stuck with because of its security implications to an organization’s network. Explaining to the Security team how exactly everything works and how secure it is, or not, is a crucial step in order to get their approval as this team can often block this deployment from happening.

Microsoft Internet Security and Acceleration (ISA) Server and then Microsoft Forefront Threat Management Gateway (TMG) have been the main technologies used to publish these services for the past decade or so. However, with ISA long gone and TMG now discontinued, what should organizations use? Forefront Unified Access Gateway (UAG) is probably the best option as it allows administrators to securely publish these services, and it is what Microsoft will recommend you to use. However, UAG is very complex and hard to set up, and it is too expensive for most organizations, especially when used only for Exchange when it can do so, so much more.

Third party portals and load balancers are starting to become an option as some of these now offer the option of publishing OWA. However, not everyone is happy with creating firewall rules directly to these devices and there is still the problem of how to publish EAS, Outlook Anywhere, etc.

Since the release of Windows Server 2008, it is possible to add an optional component called IIS Application Request Routing (ARR) to the Internet Information Services (IIS) server role. ARR is a proxy-based routing module that forwards HTTP requests to content servers based on HTTP headers, server variables and load balance algorithms. ARR relies on the URL Rewrite module to inspect incoming HTTP requests in order to make routing decisions.

ARR includes the following key features:

• HTTP-based routing decisions: ARR makes routing decisions at the application level (Layer 7), enabling the creation of powerful routing rules that are based on HTTP headers and server variables;
• Load balance algorithms enables administrators to apply a user-selected load balance algorithm to determine which content server is most appropriate to service HTTP requests;
• Health monitoring provides both live traffic and specific URL tests to determine the health of content servers;
• Client affinity allows ARR, by the use of cookies, to affinitize all requests from a client to a content server. ARR differentiates the clients behind NAT, so each client is treated independently;
• Management and monitoring: IIS Manager can be used to manage and view all configuration settings and aggregated runtime statistics for ARR;
• Failed request tracing rules: specific traces can been created to troubleshoot and diagnose ARR.

Another advantage of ARR is that it is supported across a multitude of Microsoft Operating Systems. These are: Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012; Windows Vista, Windows 7 and Windows 8.

In this article series, we will see how to configure ARR version 2.5 installed on Windows Server 2012 Datacenter Edition to publish Exchange 2013 OWA. This article assumes the reader has some basic knowledge of how IIS works

Application Request Routing 3

The beta version of ARR v3.0 has recently been released. WebSocket support and retries of URL health checks are the main highlights for this release. Apart from these, it also includes a few bug-fixes.

WebSockets support: Windows Server 2012 added support for WebSockets in IIS 8.0, allowing administrators to deploy WebSocket applications on IIS server, opening doors for many other applications. Some organizations use ARR in conjunction with IIS for its L7 aware routing and software load balancing capabilities. WebSockets require special handling by L7 proxies and that is why ARR v2.5 is not capable of routing WebSocket requests. In this new release, ARR can distinguish WebSocket requests from normal HTTP requests and can handle them adequately.

Retries for URL Health Monitoring: ARR provides a URL health test for monitoring health of backend servers. ARR periodically checks for health test URL and marks servers unhealthy when the URL test fails. It also stops sending further traffic to a server while it is unhealthy. While this is a very useful feature, it can be problematic in case the server is experiencing a transient failure. Previous versions of ARR did not provide a retry mechanism for health checks. ARR v3 retries the URL health test 3 times by default before marking servers unhealthy (this retry count value is configurable). The URL health monitoring feature is described in more detail in the second part of this article, in the Configuring Application Request Routing v2.5 section.

Installing Application Request Routing

ARR can be deployed in a variety of different configurations, with the one illustrated below being the most common one. In this scenario, ARR is deployed in the perimeter network (DMZ) and it is not joined to the Active Directory domain. It is usually configured with two network cards: one in the internal network (LAN) and the other in the DMZ. ARR must be able to receive requests from the Internet and route them to your Exchange servers. Ensure that its default gateway is in the perimeter network and that it is able to browse the Internet. For name resolution, it is recommended to use the server’s HOSTS file.

The following diagram is just an example and assumes the firewall is not already redirecting HTTP requests to HTTPS:

Figure 1.1: Application Request Routing Example Diagram

Using the Add Roles and Features Wizard of Windows Server 2012, install the .NET Framework 3.5 Features and IIS itself including the Tracing feature:

Figure 1.2: Add Roles and Features Wizard

Next, ensure that your public certificate is installed on the server. Add an HTTPS binding on the Default Web Site in IIS with the certificate your Exchange servers use. This certificate must have a private key associated with it. If you have an internal PKI, install your internal root certificate on this server as well.

Figure 1.3: IIS Site Bindings

In this scenario, the Default Web Site contains the IP address I plan to listen on. If you ever worked with TMG, this is very similar to the concept of a TMG listener. Here, you also have the same limitation in terms of certificates and the number of IPs in IIS as you do in TMG. For example, if you have two certificates you want to use with ARR, you will need to bind two IPs to your IIS server and create two websites.

Before installing AAR, open a command prompt with administrator user rights and stop the Windows Process Activation Service (which will also force the World Wide Web Publishing Service to stop) by entering the following command:

net stop was /y

Next, install the Microsoft Web Platform Installer (Web PI). This is a free tool that helps administrators get the latest components of the Microsoft Web Platform, including IIS, SQL Server Express, .NET Framework and Visual Web Developer. Once installed, do a search for routing, select Application Request Routing 2.5 with KB2589179, click Add and then click Install to start the installation of ARR as shown below:

Figure 1.4: Installing ARR through Web Platform Installer

On the Prerequisites pane, review the prerequisites that will be installed (these include the URL Rewrite module) and then click I Accept:

Figure 1.5: Application Request Routing Prerequisites

The Install pane will show the progress of the installation process:

Figure 1.6: Application Request Routing Installation Progress

Once everything is installed, the wizard will go straight to the Finish pane. Verify that everything was installed successfully and click Finish to close the ARR installation wizard:

Figure 1.7: Application Request Routing Installation Completed

Verify that the Windows Process Activation Service and World Wide Web Publishing Service are running. If not, run the following commands to start them:

net start was

net start w3svc

The following two steps are optional, but recommended.

Change Application Pool Process Model

In our scenario, all HTTP requests and responses for OWA will be going through ARR. As such, we want the worker process for the Default Web Site on ARR to always run, regardless of whether the worker processes for some of the other sites (if any) are running or not. So, we disable the Idle Time-Out under the application pool process model for the Default Web Site:

1. Launch IIS Manager;
2. Select Application Pools:

Figure 1.8: Select IIS Application Pools

3. By default, DefaultAppPool is the corresponding application pool for the Default Web Site. Right-click on DefaultAppPool in the right-hand side and then click on Advanced Settings…:

Figure 1.9: Select Advanced Settings...

4. Change the Idle Time-out (minutes) value from 20 to 0 (zero) to disable the setting and then click OK to save the changes:

Figure 1.10: Update Idle Time-Out Value to 0

Change Application Pool Recycling Settings

Similarly, you should disable the application pool recycle setting so that the application pool does not recycle unexpectedly for ARR:

1. Launch IIS Manager;
2. Select Application Pools:

Figure 1.11: Select IIS Application Pools

3. By default, DefaultAppPool is the corresponding application pool for the Default Web Site. Right-click on DefaultAppPool in the right-hand side and then click on Recycling…:

Figure 1.12: Select Recycling...

4. Clear the Regular time intervals (in minutes) checkbox so that it is blank:

Figure 1.13: Edit Application Pool Recycling Settings Window

5. Click Next and then Finish to save the changes.

Achieving High Availability and Scalability

As we saw in the first article of this series, IIS Application Request Routing (ARR) is a proxy-based routing module that forwards HTTP requests to content servers based on HTTP headers, server variables and load balance algorithms. A typical ARR deployment is illustrated in the diagram below:

Figure 2.1: Example of an ARR Deployment

While ARR provides high availability and scalability for the content servers, the overall deployment is not highly available or scalable because ARR is a single point of failure and the scalability of the content servers is limited by the maximum capacity of the ARR server used.

In order to overcome these challenges, you should consider using multiple ARR servers with load balancers. ARR can be deployed in active/passive mode to only achieve high availability or in active/active mode to achieve both high availability and scalability. Load balancers’ layer 3 and layer 4 functionality compliments ARR's strength in making routing decisions based on layer 7, such as HTTP headers and server variables. At the same time, ARR does not provide fault tolerant deployment features for itself and must rely on other technologies and solutions to achieve high availability for the ARR tier, as shown below:

Figure 2.2: Example of an ARR Deployment with Load Balancers

Configuring Application Request Routing v2.5

Now that ARR is installed, we can start configuring it to publish our Exchange services such as Outlook Web App (OWA).

The first step is to create a farm with all the Exchange 2013 CAS servers that will be responsible for serving OWA requests. To do so:

1. Launch IIS Manager;
2. Right-click on Server Farms and select Create Server Farm...:

Figure 2.3: Application Request Routing Server Farms

3. Give the server farm a friendly name and click Next:

Figure 2.4: Specify a Web Farm Name

4. Specify the servers’ addresses you want to add to the farm (you can also use the FQDN of the servers). Advanced settings lets you change the TCP ports that will be used as well as the weight each server has, which we do not need to configure in this scenario. You can also specify upfront if you want any of the servers to be added as offline. This can be useful when you are setting up ARR for servers that are not yet fully configured or operational.

Figure 2.5: Adding Servers to the Farm

5. Click Finish to complete the creation of the farm;
6. In the Rewrite Rules message box, click Yes. This will make ARR automatically create and configure the rewrite rules we will be using later on:

Figure 2.6: Rewrite Rules Automatic Creation

Once the farm has been created, it is time to configure it. If you click on Servers, you will get an overview of the status of all the servers in the farm:

Figure 2.7: Server Status

If you click on the name of the farm itself, in this case Exchange – OWA, you are presented with several options to configure and manage the farm. Let us go through all the available options:

Figure 2.8: Farm Configuration and Management Options

Caching

By default, everything that passes through ARR is cached in memory for 60 seconds (note that disk caching is also enabled by default). This means that if two users request the same resource within 60 seconds, ARR does not need to go back to the same resource provider to get it that second time.

Unselect the Enable disk cache option to disable the disk cache and click Apply:

Figure 2.9: Disabling Disk Cache

Health Test

In this page we can configure health settings and set the properties for URL testing and live traffic testing. The Live Traffic test leverages the live requests, allowing ARR to mark a server as unhealthy based on configurable conditions. However, we cannot use this test to determine if an unhealthy server has become healthy because ARR does not forward live requests to servers that are currently unhealthy.

URL Test tests a specified URL against one or more of the following conditions:

• A response was received within the configured timeout period;
• The HTTP status meets the configured acceptable status codes;
• The body of the response contains the specified text configured in the response match.

When load balancing requests across multiple servers, as we will see shortly, if any of these conditions fail for a server, that server is marked as unhealthy and is not used to serve user requests.

As this feature is limited to using a single URL, it is recommended to create a test page with the overall health of the server (this can come from Operations Manager for example) as ARR can be configured to look for specific words in that test page.

Alternatively, if the URL is set to the FQDN of the ARR server, the test is performed against all servers configured in the farm. As such, we can easily configure ARR to check the OWA webpage across all servers in the farm by using this method:

Figure 2.10: Application Request Routing - Health Tests

Response match is an optional test to make sure that the body of the response contains the expected string. If you customized your OWA logon page, for example, you can insert here a word that you expect to see every time a user successfully navigates to OWA.

The Minimum servers option specifies the minimum number of healthy servers that you must have to appropriately service the expected volume of traffic. When there are less healthy servers than the specified number of minimum servers, the health of the servers is ignored to continue to provide services to users.

Using Verify URL Test we can send a GET request using the value specified in the URL to all application servers defined in the server farm. In my scenario, only two servers were tested as the third was added as being offline, and the second server failed the test because it does not exist:

Figure 2.11: Verifying URL Test Results

Load Balance

Here we configure how to route user requests to the servers in the farm. The default option is Least current request, which is probably the most used one as normally administrators want to send requests to the server that currently has the least number of requests. You will see in the next section how ARR tracks the number of requests for each server.

Figure 2.12: Application Request Routing - Load Balancing Options

Monitoring and Management

In this section we can monitor and manage the servers in our farm. ARR provides useful statistics regarding servers such as their health status, how many requests each server has received and responded to, how many requests failed, etc. We can already see that, due to the health test we configured, the second server is marked as being Unhealthy, making ARR not sending any user requests to it.

We will come back to this section after we configure everything in order to check how everything is working.

Figure 2.13: Application Request Routing - Monitoring and Management

We can also take servers offline or simply configure them to not accept new connections (similar to draining a server in a cluster):

Figure 2.14: Options for Managing Servers

Both management and monitoring options are discussed in more detail in the next articles of this series.

Proxy

This section allows us to configure how packets are forwarded to the servers in the farm. For example, we can add the X-Forwarded-For information to requests to allow us to see who the actual client was (useful when troubleshooting):

Figure 2.15: Application Request Routing - Proxy Options

Here, change the time-out (seconds) value to 180 and the Response buffer threshold (KB) to 0. Setting the timeout to 180 should prevent clients from disconnecting and reconnecting unexpectedly. However, this setting needs to be tested for each deployment. This setting is particularly important if you are configuring ARR for Outlook clients with Exchange 2010.

Routing Rules

This is where we configure our server farm to use the URL Rewrite functionality (that we will see in the next article) as well as SSL offloading (enabled by default).

SSL offloading is often used to help maximize the resources on the application servers, since they do not have to spend cycles in encrypting and decrypting requests and responses. However, when this feature is enabled, all communication between the ARR server and the application servers are done in clear text, even for HTTPS requests from clients to the ARR server. For this scenario, we will not be using SSL offloading, so uncheck the Enable SSL offloading box and then click Apply to save the changes:

Figure 2.16: Application Request Routing - Routing Rules

Server Affinity

In this final section we can configure “sticky sessions”. If we want users to go to the same server they used on their first connection, we can enable Client affinity and ARR will put a cookie in their session to help it determine to which server the user should go to on subsequent connections/requests. As we are not interested in client affinity, leave this setting disabled.

Figure 2.17: Application Request Routing – Server Affinity 

If you are using ARR to publish RPC over HTTP (Outlook Anywhere) in Exchange 2007/2010, you should also make the following change:

1. Under the IIS root, open Request Filtering:

Figure 2.18: IIS Request Filtering

2. Under the Actions pane, click Edit Feature Settings...:

Figure 2.19: Edit Feature Settings

3. Increase the Maximum allowed content length to 2147483648 (2GB):

Figure 2.20: Redefine the Maximum Allowed Content Length 

Is ARR fully configured now? No, not just yet...

In this environment, I am using a URL of mail.letsexchange.com to access OWA and other services:

Figure 2.21: Exchange 2013 OWA Virtual Directory Settings

If I now update the DNS record for this URL and point it to ARR, some requests will fail such as HTTP requests which will be automatically rejected. To finish our configuration, we still need to configure the URL Rewrite feature of ARR so that all requests are properly routed to Exchange.

URL Rewrite

As we saw in the previous articles, Application Request Routing (ARR) relies on the IIS module URL Rewrite to inspect incoming HTTP request headers and server variables in order to make routing decisions. This allows administrators to write intelligent routing rules based on the application level information, such as:

• Host name (HTTP_HOST): to route traffic to different content servers based on the host name;
• Requested resource (URL): based on file extensions, determine whether the requested resources are for static content or dynamic content and route the requests accordingly;
• Client information (HTTP_USER_AGENT): based on the browser type and version, route the requests to appropriate content servers;
• Custom headers (set as a cookie by applications): route traffic based on cookie information set by applications, such as user preference or user ID.

To check the URL Rewrite rules already in place (created automatically when we created the farm), select your server and then click in URL Rewrite. Make sure you do not select Default Web Site as there is also a URL Rewrite option for it but that is not the one we want:

Figure 3.1: Select the Application Request Routing Server 

Figure 3.2: Select URL Rewrite

Here we are presented with the two default rules that ARR automatically created. The first one is for HTTPS requests, while the second one is for HTTP requests:

Figure 3.3: URL Rewrite Default Rules

You can think of these rules as “re-route rules”. Although they do not have all of the same features, these are very similar to the firewall rules you have in Microsoft Threat Management Gateway (TMG) and cover everything we need.

Let us go through these in more detail. By double-clicking on the first rule, we can further explore and configure it.

In the first section, Match URL, we determine what URLs will trigger this rule. For this scenario, the Outlook Web App (OWA) URL used in my environment is mail.letsexchange.com/owa. As such, if I want this rule to match an OWA address, I could set the Pattern field to *owa or even mail.* to match any Exchange URL.

As this ARR server is not going to have any other farms for other services, I will leave the pattern as *, meaning this rule will be triggered by any URL. If you are planning on having other services, such as Lync, published on the same ARR server, then you need to be specific with your rules so that Lync URLs do not get sent to Exchange servers or vice versa. The same applies if you want to separate OWA requests from ActiveSync requests, for example.

Under Using you also have the option to use Regular Expressions or Exact Match.

Figure 3.4: URL Rewrite Rule – Match URL Section

The Test pattern... option allows you to test exactly what your pattern will match. This is useful to ensure it only matches the URLs you want. Pay special attention to the {R:0} and {R:1} below as we will be needing these later on:

Figure 3.5: Testing URL Pattern Matching

The next section is Conditions, a set of inputs that are required in order to match this rule. By default, there is only one condition for this rule which specifies that this rule must match SSL requests only:

Figure 3.6: URL Rewrite Rule – Conditions Section

Just as an example, let us assume we are using the same ARR server for Office Web Apps Server (OWAS) as well. In this case, we would create a new farm with a new rule to match URLs only for OWAS. An example of such rule could be the following that only matches URLs destined to the host owas.letsexchange.com (OWAS server):

Figure 3.7: URL Rewrite Rule – Conditions Section 2

Important:
Remember that if you are using the same ARR server to publish multiple services, your rules must be very specific so they only match the URLs they should match! You should use a combination of the Pattern field in the Match URL section together with the {HTTP_HOST} condition to achieve this.

The last section is Action where we specify what to do with URLs that match this rule. Here, we need to ensure the correct server farm is specified and the requests are sent to the backend servers using HTTPS:

Figure 3.8: URL Rewrite Rule – Actions Section

Note that under Path we have /{R:0}. This {R:0} comes from what is matched by our pattern (Figure 3.5).

This was the first rule. However, by default, for each server farm, another rule is also created. This one is for HTTP requests:

Figure 3.9: URL Rewrite HTTP Rule

We can disable or delete this rule as we are only interested in HTTPS requests. However, to do this we need to also remove the {HTTPS} condition from the previous rule (Figure 3.6) so that first rule also includes HTTP requests.

Alternatively, we can simply update the HTTP rule and transform it into a redirect. Here, we have several options:

We can simply update the Scheme to https:// instead of http://

Figure 3.10: URL Rewrite HTTP Rule – Option 1

We can also change the Action type to a Redirect and put the URL we want the request to be redirected to under Redirect URL:

Figure 3.11: URL Rewrite HTTP Rule – Option 2

Or we can change the Action type to a Redirect and put in the Redirect URL field the URL of our Exchange farm using HTTPS (recommended):

Figure 3.12: URL Rewrite HTTP Rule – Option 3

Once this is done, HTTP requests will automatically be redirected to the correct address using HTTPS.

Managing Servers

As we saw in the previous article, we can use the Monitoring and Management page to manage servers in the ARR farm, including ARR specific actions described below.

Figure 3.13: Options for Managing Servers

Action	Description
Reset Runtime Statistics	Resets the runtime statistics immediately.
Make Server Available	Makes the selected server appear Available so that traffic can be routed to the server. This action is enabled only if the selected server is Unavailable or Drain.
Make Server Unavailable Gracefully	Makes the selected server appear Unavailable so that new traffic cannot be routed to the server. Pre-existing requests will complete successfully. This action is enabled only if the selected server is Available.
Make Server Unavailable Immediately	Makes the selected server appear Unavailable so that new traffic cannot be routed to the server. Pre-existing requests are terminated immediately. This action is enabled only if the selected server is Available.
Disallow New Connections	Makes the selected server refuse new connections to the server. Pre-existing requests will complete successfully. This action applies the host name affinity session and subsequent requests from the affinitized clients will continue to be routed to affinitized servers. This action is enabled only if the selected server is Available.

 Table 1

Similar to any cluster or load balancing technology, ARR allows administrators to “drain” a server, that is, prevent it from accepting new connections in order to perform maintenance on that server or some other task without affecting end user.

This is done in ARR generally by using the Make Server Unavailable Gracefully option. However, if you are using affinity, you can use the Disallow New Connections option instead. This option is more meaningful when the client affinity feature is in use, because ARR will honor the existing sessions when disallowing new connections. That is, when a client is affinitized to the server that is disallowing new connections, the client will continue to be routed to the same server and, therefore, there is no impact on the client. However, no new clients will be routed to the server that is disallowing new connections.

To use this option:

1. Select the server farm, Exchange – OWA in this scenario;
2. The following icons are shown:

Figure 3.14: Farm Configuration and Management Options

3. Double-click Monitoring and Management;
4. Right-click select the server you want to drain and click on Disallow New Connections:

Figure 3.15: Click on Disallow New Connections

5. In the confirmation dialog box, click Yes:

Figure 3.16: Click Yes to Confirm

You can now refresh the Monitoring and Management dashboard and check the runtime statistics to ensure new connections are not being routed to the server that is disallowing new connections.

If you are using affinity and want to verify this, remove the cookie set by ARR by closing and restarting the browser.

Send several requests to the ARR server and refresh the dashboard in IIS Manager. Verify that the runtime statistics are changing only for the servers that are Available. More specifically, verify that the runtime statistics for the server that is disallowing new connections have not changed. You may want to send additional requests and refresh the dashboard as needed.

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:

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:

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:

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

Figure 4.4: Select the Default Web Site

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

Figure 4.5: Click on Failed Request Tracing...

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

5. Click OK to save the changes;
6. Select the Default Web Site;
7. Double-click Failed Request Tracing Rules:

Figure 4.7: IIS Failed Request Tracing Rules

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

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

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

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

13. Click Finish.
14. 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:

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:

Figure 4.12: Failed Request Tracing Logs Folder

6. Open an xml file:

Figure 4.13: Failed Request Tracing Log - Summary

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

 

Relate Post : Windows Server 2012 - Converting from a Server Core to Server with GUI Windows Server - Configuring DFSR to a Static Port Windows Server 2016 – 新世代虛擬化平台 Hyper-V Windows Server 2012 - Rename AD Domain Name Windows Server - Revoking temporary RDS licenses Windows Server 2012 - RDWeb Feed Windows Server 2012 - Creating a Fine –Grained Password Policy Windows Server - Seizing An Operations Master with NTDSUTIL Windows 2008 / 2012 - KMS Server setup Windows 2008 - Clean up Winsxs after SP1 install
Comments :
No Comments

Post your comment:

Post your comment by Guest :

Verify Code :