Application Request Routing for Microsoft Exchange Server

Article
1/17/2024

^{download e-book}

Exchange Server and Reverse Proxy

"Do I really need a reverse proxy server for my Exchange environment?" the simplest answer would be "No!" Yes, you really do not need a reverse proxy. Before going ahead, let’s look a bit over the Exchange Server client handling.

Basically, you can say Exchange Client Access Server (CAS) is an intermediary that allows ‘things to work’ between clients; mail applications, mobile devices, browser etc. and your Exchange Server(s) that holds the Mailbox Databases. Exchange Server 2007 Client Access role was filled with jobs; authenticating connections, proxy and redirecting as well as data rendering to Exchange web service protocols. Where as in Exchange 2010, MAPI data rendering was added on top of it.

Exchange Server 2013 and above has redefined how Microsoft handled its client services in its predecessor versions 2007 and 2010. The Client Access Server no longer performs Data Rendering. So, what does it do? It acts as a proxy itself. It will perform authentication against the clients (NTLM, Basic, negotiate etc.) and admits the request, then proxy OR redirect the connection to the Mailbox Database OR Client Access Server where the specific user’s mailbox is Actively located in OR can be found in. Why Actively? Well, in Exchange we can have multiple database copies enabled with a Database Available Group (DAG) with Active and Passive Mailbox Database copies.

So yes, as shown in the above diagram, we don’t need a Reverse Proxy. But why we implement one, is mainly due to security reasons. The way someone could interpret that the above scenario could pose a direct threat to the internal network. Well, we could all agree to that. Why? If a connection is compromised, anyone sitting outside of the organization now clearly have access to one of the internal servers. Therefore, it not only poses a threat to the Client Access Server itself, but to the entire internal network.

And that’s where the concept of a perimeter network comes into play. In definition, a perimeter network acts as a logical network that separates an internal network of an organization to an external network where it’s the internet. By adding this logical network boundary, the organization can publish their internet facing web services with an additional protection layer, thus an attacker even if being able to compromise will still be isolated without breaching into the internal network.

For Exchange Server Client Access Services, we achieve that through deploying a reverse proxy. However, a functionality of a reverse proxy could be achieved in multiple ways; via firewall or 3^rd party open source provides such as squid.

Moving ahead with Microsoft’s approach to cater the functionality, a component named ARR can be integrated with its built-in IIS Web Server features.

Network Setup

Setting up your network topology right is the key to getting your traffic flowing right. The IIS ARR server will be deployed outside of your Exchange environment, typically together with an Edge server. IIS ARR can be deployed as a single standalone server, or with multiple servers configured with load balancing for business-critical environments that need high availability.

Because the IIS ARR server is setup in the perimeter network or the DMZ, it will have network interfaces that are connected to multiple network segments. In this guide, we will look into a 2 NIC scenario. The two adapters will be facing the internet facing firewall which we will call ‘External Adapter’ and the other, "Internal Adapter" facing the internal firewall segment. However, there is a way to configure your networking using a single Network adapter and based on your perimeter environment, security guidelines and best practices you can chose your setup.

When you are configuring your network setup, please keep in mind that it is quite essential that you setup the gateway, DNS and static routes in a correct manner. Now let’s look into each of the components one by one.

Setting up your NIC’s

Well, you have two NICs to configure now. Each connecting to the Internet/External and Internal facing network segments. The environment that we will discuss will consider following topology.

Configure Internal Network Adapter

1. - Click　Start, click　Control Panel, click　Network and Internet, click　Network and Sharing Center　and then click　Change Adapter Settings.
  - Right-click the connection which is connecting to the Internal network segment, rename it to "Internal".
  - Right click the Internal adapter and then click　Properties.
  - Double-click　Internet Protocol Version 4 (TCP/IP/IPv4).
  - Click　Use the following IP address
  - Enter　IP address, Subnet mask, as shown in the table. Keep the Default gateway and DNS server addresses address space empty.
  - Click OK.
  - On the Internal Properties window, click OK to save the changes.

Configure Internal Network Adapter

1. - Click　Start, click　Control Panel, click　Network and Internet, click　Network and Sharing Center　and then click　Change Adapter Settings.
  - Right-click the connection which is connecting to the External network segment, rename it to "External".
  - Right click the External adapter and then click　Properties.
  - Double-click　Internet Protocol Version 4 (TCP/IP/IPv4).
  - Click　Use the following IP address
  - In　IP address, Subnet mask, and　Default gateway, type the IP address, subnet mask, and default gateway addresses.
  - Click OK.
  - On the Internal Properties window, click OK to save the changes.

Configure Static Routes

Since we have two network segments, each with different network ranges, we need to point out which traffic is to go through which network adapter. As for the External network adapter, we have already configured this via adding the Default gateway entry. However, as our internal servers will be connecting through the Internal network adapter, we need to manually setup routing to tell the server to route all traffic bound to the internal IP range, via the internal network adapter. In our case, all traffic to the IP range 192.168.8.0/24 needs to be routed to the next hop 192.168.8.1

1. - Open Command Prompt as Administrator.
  - Enter below command;

"route ADD <network> mask <subnet mask> <next hop ip>"

Verify Routing Configuration

1. - To verify external routing,
    1. - use the below command.
        
        "tracert <external/internet ip>"
      - Verify external gateway IP is displayed in the results.
    　
  - To verify internal routing,

1. 1. - use the below command.
      
      "tracert <internal ip>"
    - Verify internal gateway/next hop IP is displayed in the results.

Setting up your DNS

Because IIS ARR server is in the perimeter network, we will not make it a member of the internal domain structure. Therefore, we need to manually configure the server’s DNS suffix. To setup the DNS Suffix, please do the following;

1. - Open Control Panel, and then choose　System Properties.
  - Choose the　Computer Name　tab.
  - Choose　Change.
  - On the　Computer Name Changes　page, click　More.
  - In　Primary DNS suffix of this computer, type the primary DNS suffix.
  - To prevent the primary DNS suffix from changing when the computer moves to another Active　Directory domain, clear the　Change primary DNS suffix when domain membership changes　check box
  - Click OK to save your settings.
  - Restart your server.

There are two ways to configure the interface that is connected to the internal network segment (where your Exchange servers reside) to lookup for DNS for the internal servers and Exchange service URLs;

- Configure to use a DNS server: If you have a DNS server placed in the perimeter network, you can manually add resource entries for related servers and URLs in a forward lookup zone and configure it on the internal network adapter of the IIS ARR server

- Modify Host File: If you have no DNS servers inside your perimeter network, you can edit the Hosts file on the IIS ARR server to include the Host records for the Mailbox servers and URLs

Let’s proceed with Modify Host File option;

1. - Open Notepad in Administrator mode.
  - Click File, Open and navigate to "\Systemroot%\System32\Drivers\Etc"
  - Open hosts file
  - Add your Exchange Server and Virtual Directory URL IP and Host names mapping entries.
  - Save the hosts file.

Setup IIS Server

ARR is a service that relies on Microsoft IIS services. First things first, let’s get started with the IIS.

1. - Mount your Windows Server 2012 R2 installation media.
  - Open Windows PowerShell.
  - Run the following command to install the required Windows components.
    
    Install-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-WCF-Services45,NET-Non-HTTP-Activ,NET-HTTP-Activation, Web-Server -source D:\sources\sxs
  - Wait for the installation to complete.
  - Close PowerShell console

Certificate Setup

The next step we import the SSL Certificate that’s been used by Exchange IIS services. First, go through the below steps to export the Exchange Certificate;

1. - Open the EAC and navigate to　Servers,　Certificates.
  - In the　Select server　list, select the Exchange Client Access server.
  - Select the proper Exchange certificate and click　**More options　**, and select　Export Exchange certificate.
  - On the　Export Exchange certificate　page that opens, enter the following information:
    - - File to export to　　　
      - Password　　
  - When you are finished, click　OK.

If you are using an internal Certificate Authority generated certificate, you need to export the Domain Root Certificate. Do the following to export and import the Root Certificate;

1. - On the Domain Controller or Exchange Server, open the browser
  - Logon into Root Certification Authority Web Enrollment Site via http://<root_CA_ip>/certsrv
  - Click the Download a CA certificate, certificate chain, or CRL link.
  - Click on Download CA certificate link.
  - Save the file "RootCA.cer".

Now that we have exported the Root CA, let’s import it on the Reverse Proxy Server.

1. - On the Reverse Proxy server, click　Start, type　mmc, and then press ENTER.
  - On the　File　menu, click　Add/Remove Snap-in.
  - Under　Available snap-ins, double click　Certificates.
  - On the　This snap-in will always manage certificates for window, click　Computer account, and then click**　Next.**
  - Click　Local computer, and click　Finish.
  - Click　OK.
  - In the console tree, double-click　Certificates.
  - Right-click the　Trusted Root Certification Authorities　store.
  - Click　Import　to import the certificates and follow the steps in the Certificate Import Wizard and provide the above imported Root certificate(RootCA.cer).

Now that we have imported the Root Certificate Authority, let’s go through the steps to import your Exchange Certificate on the Reverse Proxy Server;

On the Reverse Proxy server, open Internet Information Services (IIS) Manager.
Select the Server name from the Connections pane.
From the window, double click Server Certificate under IIS.
In the Server Certificates window, click Import from the Actions pane.
On the Import Certificate wizard, Provide the Certificate path, Password values and ensure the Select Certificate Store is selected as Personal. Click OK.
Verify that the Certificate is listed.
To assign the certificate to HTTPS bindings, on the IIS Manager Connections pane, expand Server Name, Sites and select Default Web Site.
Click on Bindings from the Action pane.
On the Site Bindings window, click Add.
From the Add Site Binding window, select https as Type.
From the SSL certificate drop down list, select the Exchange certificate that you just imported.
Click OK.
Click Close.

Setup Application Request Routing

So again, if you are not familiar with IIS or ARR, in a nutshell, we can use ARR features to handle our Exchange Server Web Service request through proxy’ing.

Some of the key features of ARR that we will be looking at includes, but not limited to;

- HTTP based routing decisions built using rules that examine HTTP request information
- Sophisticated load balancing algorithms to determine appropriate servers to service the HTTP requests
- Health monitoring for live traffic and specific URLs to determine the health of servers
- Management of multiple server farms
- Management and monitoring of all configuration settings and aggregated runtime statistics through IIS Manager interface.

The following steps will guide you through installation of ARR component for IIS;

Download and run Application Request Routing 3.0 Stand-alone package 64-bit version from here.
Click Yes to proceed
Click Yes on the License Agreement page and proceed with the installation to complete.
Re-open IIS Manager, Expand the server and verify that Server Farms module is present.

Now we need to perform some tweaking at the IIS Request Filtering level.
Go to IIS Manager, select your server and double click Request Filtering from the Features view.
From the Actions pane, click on Edit Feature Settings…
Change the value of Maximum allowed content length to 2147483648.
Click OK.

Configure Server Farms

Setting up ARR means we will be configuring the Exchange Server virtual directory URLs and enabling high availability, proxying etc. In order to do so, we create server farm(s) to each of the service URL(s). For this scenario, we will be configuring two server farms; mail.fabrikam.com and autodiscover.fabrikam.com.

Setup Default Service URL (mail.fabrikam.com)

- Open IIS Manager.
- In the　Connections　pane, expand the server node.
- Under the server node, right-click　Server Farms, and then select　Create Server Farm….
- In the　Create Server Farm　dialog box, on the　Specify Server Farm Name　page, type the name for your server farm. Click　Next.
- On the　Add Server　page, enter the server addresses/FQDNs of your Exchange Client Access Servers that you want to add. Once all servers are added, click　Finish.
- On the Rewrite Rules window, Click Yes.

Configure Server Farm properties

- On the IIS Connections pane, under Server Farms expand the newly created server farm entry. Double click Caching from the main window.
- Un-select Enable disk cache option.
- Click Apply to save settings.
- Go back to the Server Farms window and double click on Health Check.
  
  The Health Check feature enables you to generate events based on the service availability for a particular URL. So basically, we provide an URL and IIS will probe the URL at a given interval and based on the retrieved HTTP Access Code it will mark a server as healthy or not.
  
  In the case of Exchange Server, we need to probe for the Web URLs; OWA, ECP, EWS, OAB, AutoDiscover etc.)
  
  Now in this scenario, there’s a catch. Mainly because of how we can publish Exchange Server URLs.
  
  Option 1, Consolidate all the URLs into a single namespace. In this scenario, all services will be assigned with a single namespace. mail.fabrikam.com for an example. If you have chosen this method for publishing your URLs, then you have an option of using a health check probe point of either one of the protocols. However, the downside of this would be, in a scenario where the OWA service is down, and all other services are running, ARR will notice the OWA status as unhealthy and put the server to unhealthy status as well. While the other services are still up and running. Leaving us to say that this will not provide true High Availability proxy’ing.
  
  Option 2: To get rid of the problem above, we can have multiple namespaces in the Exchange CAS. Where for each virtual directory, there would be a unique access URL. Which means for us when configuring ARR, we could create a separate unique server farm for each of the services, thus providing a separate health probe point. This will mitigate the limitation where if one service goes down, other service access proxy’ing will not be affected.
  
  The Health Check URL for Exchange 2013 and above will be in the following format.
  
  https://<External FQDN>/<protocol>/healthcheck.htm
  
  If the protocol is working properly, you will be getting a response like below.
  
  200 OK
  
  <ServerName>.<Domain>.COM (ex: 13ml-01.fabrikam.com)
  
  　
  
  For the guide below, we are considering Option 1.
- On the properties window under the URL Test: enter the below information;
  1. URL – URL that will be used to ping for checking if its accessible.
  2. Interval – Interval the test should run
  3. Acceptable status code – The status code returned by the Exchange server that will be considered as the server to be in a healthy state.
- Click Verify URL Test to check the health status, ensure the output is Pass.
  
  If you are receiving Fail as the status, probably means there is an accessibility issue to the provided URL. What you might want to do is, go to your browser from the Reverse Proxy server and type it in. Ensure that you can visit a page with the server information. DNS resolution (host file or DMZ DNS server) can be a point of cause if you are unable to resolve.
- Click Close and click Apply to save settings.
- Go back to the server farm properties page and double click Routing Rules.
- On the Routing Rules page, uncheck the Enable SSL offloading setting and click Apply.

Let’s see why and what we are trying to achieve here;

We know that Exchange Server and the client communication is encrypted. When the client tries to communicate with the Server, information will be encrypted and decrypted at the Exchange Server it-self. Here, apart from the typical Exchange services, there will be additional CPU utilization for this purpose. This is usually calculated when you do the server capacity planning.

When we put up a secondary server such as a Reverse Proxy, we have two options;

- - SSL Offloading: Here, the Client to Server connection will be interrupted by the reverse proxy server. Client to Reverse Proxy SSL connection will be terminated at the Reverse proxy and the reverse proxy to Exchange server will be via plain text. This means that the Encryption and Decryption CPU load will be borne by the Reverse Proxy and Exchange Server will have a reduced CPU load. If you are planning for this method, ensure that you do the server sizing right.
  - Pass-through SSL connection: In this situation, the reverse proxy will not perform any encryption/decryption. Rather it will be straight away passed to the Exchange Server. In this section, we are focusing on this method.

On the IIS Manager, select the server from the Connections pane. On the Features View section, double-click URL Rewrite.
Select the appropriate entry that will include ARR_<server-farm-name>_loadbalance_SSL from the list and double click.
Expand the Conditions in the Edit Inbound Rule.
Click Add.
Fill in below on the Add Condition window and click OK.
1. Condition input: {HTTPS}
2. Check if input string: Matches the Pattern (Default)
3. Pattern: on
4. Ignore care: <keep checked>
Click Add again.
Fill in below on the Add Condition window and click OK.
1. Condition input: {HTTP_HOST}
2. Check if input string: Matches the Pattern (Default)
3. Pattern: mail.fabrikam.com
4. Ignore care: <keep checked>
On the Actions section, under Scheme, select https://
Click Apply to save settings.

Setup AutoDiscover

Now that we have setup the configurations for mail.fabrikam.com, let’s go ahead and configure autodiscover.fabrikam.com

Open IIS Manager.
In the　Connections　pane, expand the server node.
Under the server node, right-click　Server Farms, and then select　Create Server Farm….
In the　Create Server Farm　dialog box, on the　Specify Server Farm Name　page, type the name for your server farm. Click　Next.
On the　Add Server　page, enter the server addresses/FQDNs of your Exchange Client Access Servers that you want to add. Once all servers are added, click　Finish.
On the Rewrite Rules window, Click Yes.

Configure Server Farm properties

On the IIS Connections pane, under Server Farms expand the newly created server farm entry. Double click Caching from the main window.
Un-select Enable disk cache option.
Click Apply to save settings.
Go back to the Server Farms window and double click on Health Check.
On the properties window under the URL Test: enter the below information;
1. URL – URL that will be used to ping for checking if its accessible.
2. Interval – Interval the test should run
3. Acceptable status code – The status code returned by the Exchange server that will be considered as the server to be in a healthy state.
Click Verify URL Test to check the health status, ensure the output is Pass.

If you are receiving Fail as the status, probably means there is an accessibility issue to the provided URL. What you might want to do is, go to your browser from the Reverse Proxy server and type it in. Ensure that you can visit a page with the server information. DNS resolution (host file or DMZ DNS server) can be a point of cause if you are unable to resolve.
Click Close and click Apply to save settings.
Go back to the server farm properties page and double click Routing Rules.
On the Routing Rules page, uncheck the Enable SSL offloading setting and click Apply.

Let’s see why and what we are trying to achieve here;
On the IIS Manager, select the server from the Connections pane. On the Features View section, double-click URL Rewrite.
Select the appropriate entry that will include ARR_<server-farm-name>_loadbalance_SSL from the list and double click.
Expand the Conditions in the Edit Inbound Rule.
Click Add.
Fill in below on the Add Condition window and click OK.
1. Condition input: {HTTPS}
2. Check if input string: Matches the Pattern (Default)
3. Pattern: on
4. Ignore care: <keep checked>
Click Add again.
Fill in below on the Add Condition window and click OK.
1. Condition input: {HTTP_HOST}
2. Check if input string: Matches the Pattern (Default)
3. Pattern: mail.fabrikam.com
4. Ignore care: <keep checked>
On the Actions section, under Scheme, select https://
Click Apply to save settings.

Now your IIS ARR is ready to server Proxy Requests for your Exchange Server environment.

Before putting down your Reverse Proxy servers live, it’s highly recommended that you test things out for client connectivity. Because trust me, "Trying to Connect to Microsoft Exchange　Server." For 100’s and 100’s of users at the same time is not going to look pretty at all. So, set up a temporary Windows client machine, put it in the DMZ. Now we need to edit the hosts file and manually enter the mail.fabrikam.com and autodiscover.fabrikam.com to point out to the reverseproxy server. Install Outlook and try out all your publishing settings in every way to confirm that you are all good to go!

I hope that you will enjoy the book and its content will help you to grow your skills for a successful deployment.

If you have any queries, please feel free to drop in your thoughts, requests and suggestions over to wpjcp@hotmail.com

Share via

Application Request Routing for Microsoft Exchange Server

Exchange Server and Reverse Proxy

Network Setup

Additional resources