IIS Application Request Routing (Part 3)

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

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 its initial configuration. In this article we will finish the configuration and look at how to manage servers in the Application Request Routing farm.

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

 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.

Conclusion

In this article we finished configuring Application Request Routing to publish Outlook Web App out to the Internet. In the next 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:

• IIS Application Request Routing (Part 1)
• IIS Application Request Routing (Part 2)

• IIS Application Request Routing (Part 4)