Part 2: Reverse Proxy for Exchange Server 2013 using IIS ARR

In my previous article we saw that how easy it was to implement IIS ARR as a Reverse Proxy and Load Balancing solution for Exchange 2013. However that option is not the best if you are looking to achieve true high availability for your client connectivity. Read on and it’ll Arrrr! become clear.

In this post we’re going to cover another way of implementing IIS ARR (I’m calling this Option 2) for Exchange 2013. However just before that we need to understand the limitations of the previous posted solution (which we shall refer to as Option 1) so that you can see what we need to fix.

Problem

With the Option1 implementation, we are only performing health checks against OWA and AutoDiscover Virtual Directories (vdir’s). There were no explicit checks to make sure that Outlook Anywhere (OA), Exchange Web Services (EWS), Offline Address Book (OAB) and others were actually up and running. As these explicit checks didn’t happen, the Reverse Proxy could continue to forward other protocol requests to the CAS server, even when those services/protocols are down.

Let me explain this with an illustration.

Scenario A

Let’s assume that the CAS has some issues with the EWS and OAB virtual directories. Since the Health Check configured in Option 1 is being conducted only against the OWA virtual directory (…./OWA/HealthCheck.htm), the server continues to be marked as Healthy. Thus EWS and OAB queries will continue to be sent to the server, even though the EWS and OAB endpoints are down. This would result in a bad experience for end users.

Scenario B

Let’s assume this time that the OWA virtual directory on CAS1 is down for some reason. Since the Health Check is only against the OWA vdir, the whole CAS1 server would be marked as unhealthy. Due to this all requests would now be directed to CAS2. So what we can see is, just because of the failure of one protocol all other requests are being directed to the second server, which is a loss of server resources.

Solution

To overcome the above mentioned scenarios, you would create individual Server Farms and URL Rewrite rules for each individual protocol. This way, there would be individual Health Checks being performed against each protocol, thus providing you with a true Reverse Proxy and Load Balancing configuration.

Below is how IIS ARR would be able to achieve per-protocol health check:

Attaining this configuration (what we call Option 2) is what we will cover next.

Option 2

STEP1: In this option we are going to implement individual Server Farms and URL Rewrite rules. However before you go ahead implementing this solution you need to make sure that you have published all the individual protocols with their own unique namespaces. (And you would of course require a certificate with all of these individual names on it) You would thus end up with something similar to the below.

Get-OWAVirtualDirectory | FL Server, InternalURL, ExternalURL
Server      : TS-E2013-CA-01
InternalUrl : https://mail.tailspintoys.com/OWA
ExternalUrl : https://mail.tailspintoys.com/OWA

Server      : TS-E2013-CA-02
InternalUrl : https://mail.tailspintoys.com/OWA
ExternalUrl : https://mail.tailspintoys.com/OWA 

Get-ECPVirtualDirectory | Fl Server, InternalURL, ExternalURL
Server      : TS-E2013-CA-01
InternalUrl : https://ecp.tailspintoys.com/ECP
ExternalUrl : https://ecp.tailspintoys.com/ECP

Server      : TS-E2013-CA-02
InternalUrl : https://ecp.tailspintoys.com/ECP
ExternalUrl : https://ecp.tailspintoys.com/ECP

Get-WebServicesVirtualDirectory | fl Server, InternalURL, ExternalURL
Server      : TS-E2013-CA-01
InternalUrl : https://ews.tailspintoys.com/EWS/Exchange.asmx
ExternalUrl : https://ews.tailspintoys.com/EWS/Exchange.asmx

Server      : TS-E2013-CA-02
InternalUrl : https://ews.tailspintoys.com/EWS/Exchange.asmx
ExternalUrl : https://ews.tailspintoys.com/EWS/Exchange.asmx

Get-ActiveSyncVirtualDirectory | fl server, InternalURL, ExternalURL
Server      : TS-E2013-CA-01
InternalUrl : https://eas.tailspintoys.com/Microsoft-Server-ActiveSync
ExternalUrl : https://eas.tailspintoys.com/Microsoft-Server-ActiveSync

Server      : TS-E2013-CA-02
InternalUrl : https://eas.tailspintoys.com/Microsoft-Server-ActiveSync
ExternalUrl : https://eas.tailspintoys.com/Microsoft-Server-ActiveSync

Get-OABVirtualDirectory | fl server, InternalURL, ExternalURL
Server      : TS-E2013-CA-01
InternalUrl : https://oab.tailspintoys.com/OAB
ExternalUrl : https://oab.tailspintoys.com/OAB

Server      : TS-E2013-CA-02
InternalUrl : https://oab.tailspintoys.com/OAB
ExternalUrl : https://oab.tailspintoys.com/OAB

Get-OutlookAnywhere | fl server, *hostname*
Server           : TS-E2013-CA-01
ExternalHostname : oa.tailspintoys.com
InternalHostname : oa.tailspintoys.com

Server           : TS-E2013-CA-02
ExternalHostname : oa.tailspintoys.com
InternalHostname : oa.tailspintoys.com

STEP2: Then follow the same steps as earlier (from Option1), but create additional Server Farms and URL Rewrite rules as shown below i.e.: you would create a server farm and the corresponding Rewrite rule for each protocol.

Also, when you are creating a Server Farm for each protocol, change the Health Test URL for each farm to be similar to the below table. Make sure that the Health Test URL’s match your environment accordingly.

The Health Test URL is in the format of https://FQDN/ProtocolName/HealthCheck.htm

That is all you have to do!!!...Now you have set up IIS ARR to validate the state of each protocol on the CAS server and only if a protocol is Healthy on a CAS server would IIS ARR forward the corresponding request and load balance accordingly.

Slight Variation on a Theme

Of course, rather than put all these names on the certificate, you could also just use a wild card certificate.

If you do choose to use a wildcard certificate, you should also make sure that you change the EXPR Outlook Provider, so that Outlook Anywhere clients can successfully connect to the Exchange Server (this behavior can be a particular issue if you have Windows XP clients). If you do not make this change then end users may continue to receive a prompt for a certificate mismatch.

Since in Exchange 2013 we make use of Outlook Anywhere both internally and externally, we have a new Outlook Provider called EXHTTP. The EXHTTP Outlook Provider cannot be configured manually, but gets constructed by AutoDiscover based on the information within the EXCH (internal settings) and EXPR (external settings) Outlook Providers. So you need to make sure that you edit both EXCH and EXPR Outlook Providers as necessary.

Examples of how to change the relevant Outlook Providers are provided below:

Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:*.tailspintoys.com

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.tailspintoys.com

Note: This change is not required if your end-users are running Windows Vista SP1 or later and only the internal, or the external may need to be set depending on how your certificates are deployed.

Testing if this all really works?

To simulate the failure of the OWA protocol on a server, we have stopped only the MSExchangeOWAAppPool on CAS1. Since we now have individual Health Test for each protocol, the server is marked Unhealthy only for the OWA protocol (ie: mail.tailspintoys.com). However the EWS and OAB protocols on the same server (TS-E2013-CA-01) continue to be marked as Healthy.

Requests for mail.tailspintoys.com:

Requests for Exchange Web Services:

Requests for Offline Address Book:

Thus, by implementing individual farms and rewrite rules for each protocol, your organization would able to achieve true Load Balancing and Reverse Proxy functionality using IIS ARR.

Comparison of the two options

Looking at the two options, we can highlight the advantages and disadvantages of implementing each individual solution. This table will help each of you evaluate which option would be the best suited for your Exchange 2013 environment.

Considerations for coexistence with Exchange 2007 and/or Exchange 2010

Since most of you would be migrating to Exchange 2013 from either Exchange 2007 or Exchange 2010 (or both at the same time), it is important to understand how each of these coexistence scenarios might work and plan how we need to implement IIS ARR in that particular situation. Let’s break it down into individual coexistence scenarios and understand how things would work...

(These scenarios take into assumption that you have set up coexistence such that the Exchange 2013 CAS servers are internet facing and are publishing the client protocols (Outlook anywhere, OWA, ECP etc))

Exchange 2010 + Exchange 2013

In this scenario all client protocol requests are proxied to the Exchange 2010 CAS servers by the Exchange 2013 CAS servers, hence no change is required on the IIS ARR server. The steps mentioned previously in the article are sufficient. Co-existing Exchange 2010 and 2013 is pretty easy no matter how you publish Exchange to the Internet.

Exchange 2007 + Exchange 2013

In this scenario you need to remember that all protocol requests to Exchange 2007 are proxied by Exchange 2013 except for OWA and EWS. OWA requests would be redirected to Exchange 2007, and EWS requests must reach a 2007 EWS endpoint (AutoDiscover takes care of providing the correct version of URL to Outlook clients). This is achieved by using the legacy namespace (legacy.tailspintoys.com), which is just the same as when you migrated from Exchange 2003/2007 to Exchange 2010, if you ever did that.

For OWA and EWS to work correctly we need to do a few things in IIS ARR.

1. Create a new Web Farm for legacy.tailspintoys.com that contains the Exchange 2007 CAS servers. We are again making use of the Load balancing capabilities of IIS ARR and thus only need the Exchange 2007 servers as members of the Web Farm. When you do this you will by now understand that this Web Farm would accept request for both legacy OWA and legacy EWS requests.

   However, if you also want to achieve per protocol availability for the legacy OWA and legacy EWS url’s, as discussed for 2013 earlier, then go ahead and create two Web Farms, one for each protocol i.e.: legacyOWA.tailspintoys.com and legacyEWS.tailspintoys.com respectively. Don’t forget that if you create two web farms then you need to add these additional namespaces to your certificate and update the Legacy URL’s for OWA and EWS on Exchange 2007 to match the namespaces you have selected.

   

2. Modify the Health Test for the above created Web Farm (note, there is no Health Check URL in previous versions of Exchange).

   

3. On the properties of the above created Web Farm continue to follow the earlier mentioned settings for Caching, Load Balance, Proxy, Routing Rules and Server Affinity.

4. Edit the corresponding URL Rewrite Rule to match the below.

   

Exchange 2007 + Exchange 2010 + Exchange 2013

This is exactly a mix of the above two scenarios. All the requests for Exchange 2010 mailboxes are going to be proxied by Exchange 2013 and all requests for Exchange 2007 mailboxes are also going to be proxied by Exchange 2013, except for OWA and EWS. So you have to follow the exact same steps as above (specifically, the steps from the scenario Exchange 2007 + Exchange 2010), to allow redirection of OWA requests to the Exchange 2007 servers.

In summary, we have seen that IIS ARR is a very flexible Reverse Proxy Solution for Exchange 2013 and allows you to choose the appropriate implementation option to suit your business needs. Also it can be controlled more granularly by choosing what you want to publish externally. So for example, if your organization does not provide OWA to users on the internet then you don’t have to perform the configuration steps for OWA. Hopefully these articles have given you an idea of you can successfully implement IIS ARR for your Exchange 2013 environment.

I would like to whole heartedly thank Greg Taylor (Principal PM Lead) for his help in reviewing these article.

Part 1 | Part 3

B. Roop Sankar
Premier Field Engineer, UK