If you would like to read the other parts in this article series please go to:
- IIS Application Request Routing (Part 2)
- IIS Application Request Routing (Part 3)
- IIS Application Request Routing (Part 4)
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:
- Launch IIS Manager;
- Select Application Pools:
Figure 1.8: Select IIS Application Pools
- 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…
- 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:
- Launch IIS Manager;
- Select Application Pools:
Figure 1.11: Select IIS Application Pools
- 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…
- Clear the Regular time intervals (in minutes) checkbox so that it is blank:
Figure 1.13: Edit Application Pool Recycling Settings Window
- Click Next and then Finish to save the changes.
Conclusion
In the first part of this article series, we looked at what IIS Application Request Routing is, how it works, and went through its installation steps. In the next article we will start configuring it to work with our Exchange environment.
If you would like to read the other parts in this article series please go to:
