In the two previous posts in this series (see Part I and Part II), we saw the two different options by which we could effectively use IIS Application Request Routing (ARR) as a reverse proxy solution for Exchange 2013. However wouldn’t it be great to know if your implementation of IIS ARR was actually working as intended, or if you knew where to look if you had issues? In this final post of the series, we'll take a look at troubleshooting ARR.
Luckily IIS ARR has its own tracing component which is very helpful for administrators to understand what’s happening under the covers and to further troubleshoot any issues.
Tracing and Logging
Turn on tracing by following the steps mentioned in Using Failed Request Tracing Rules to Troubleshoot Application Request Routing (ARR). Tracing provides very detailed information of how each URL Rewrite rule is being evaluated and if unwanted URL’s are being blocked or not. The snap shots shown below of how the rules were being evaluated were obtained by enabling the tracing feature.
Since this is IIS, you can still look at the IIS logs that are located in the default location (%SystemDrive%\inetpub\Logs\W3SVC1). However, the data from tracing should be more than sufficient.
Verifying if the above rules are working as expected
Example 1: The user tries to connect to http://mail.tailspintoys.com/OWA
Result: This should fail as the correct URL is https://mail.tailspintoys.com/OWA
In the Tracing we can see the below. As the URL entered by the user was HTTP (non-SSL). This was evaluated against the two rules and failed.
Example 2: The user connects to the correct URL i.e.: https://mail.tailspintoys.com/OWA
As you can see the URL is evaluated against each Rewrite rule and only once it passes does the user get access to the requested web page, application, etc.
Example 3: User is travelling and tries to connect to his mailbox using Outlook Anywhere.
We know that the Outlook Anywhere is made up of two streams, RPC_IN_DATA and RPC_OUT_DATA streams and we can see that below.
Example 4: The above user then tries to set his Out of Office by clicking on “Automatic Replies” in Outlook.
This would initiate a call to the Exchange Web Services as shown below.
These examples show you how detailed the logging is, and if you can correlate what you see here with what you would expect to see. It should help you narrow down any failures you might be having.
One More Recommendation
In the very first article we covered the basic best practices and recommendations when you are implementing IIS ARR. If you have however implemented Option 2, or built you own solution, then we recommend that you consider making the following change.
If you have multiple URL Rewrite Rules then make sure that the most frequently used URL is on top of the list.
First let us try and understand the reason for this recommendation.
Let’s say the client (Outlook) is trying to retrieve the AutoDiscover URL and our corresponding URL Rewrite Rule is at the bottom of the rule list (as shown below).
If we look at the trace we can see that the requested URL is being evaluated against each Rewrite Rule, which just slows the whole thing down.
Now we move the rewrite rule to the top of the list.
And by looking at the trace output we can see that since the Rewrite Rule was at the top of the list it was evaluated right away and no further processing/verification of the Rewrite rules took place.
AutoDiscover is used heavily by clients, if we were to recommend the order of your rules it would be something like this;
Of course, if you are heavy OWA users, and less Outlook Anywhere, you would want to switch those around. But I’m sure you get the idea. It’s not super critical, this ordering, but it certainly is an optimization of which you can take advantage.
This is fascinating, I want to read more
If you have read so far then clearly you are really interested in IIS ARR. So for the really interested and keen amongst you there is a question that sometimes gets asked – “Can we “harden” IIS ARR further…?”
Yes, you can. Let’s say that you have chosen to implement Option2 and your Security Admin says that you need to further tighten/control the requests that are being sent to the Exchange 2013 CAS servers.
So…Yes, we can further control the requests that are being forwarded to the CAS servers.
Let’s take the example of Exchange Web Services (EWS). As we all know, the request comes in the form of https://EWS.tailspintoys.com/EWS/Exchange.asmx.
IIS ARR breaks it down this request into the following…
- HTTPS = on
- HTTPS_HOST = EWS.tailspintoys.com
- URL string = EWS/Exchange.asmx – this is where the “Pattern” match happens within the URL Rewrite rule.
So keeping the above in mind let’s see how we can achieve strict pattern matches.
When we previously set the pattern match to *, then we are allowing all URL strings, including EWS/Exchange.asmx. This might be a concern for some admins as we are only verifying the HTTP_HOST section and not verifying the URL string part of the request that is coming through.
To remind you, this is how we originally had set it up…
In order to lock down the requests that are being forwarded to the CAS servers and to pacify your security admins, we can implement the pattern check below.
When you change the Pattern to the below then you only allow a request where the URL string starts with EWS*.IIS ARR checks to see if all the below three conditions are fulfilled and only then forwards the request to CAS.
- URL string = does it start with EWS*
- HTTPS = is the request SSL
- HTTP_HOST = the request is for EWS.tailspintoys.com
It now looks something like this:
To extend this idea to our entire configuration, you would modify all your URL Rewrite rules to look something similar to this:
In summary, hopefully these articles have given you a good understanding of how you can use IIS ARR as an effective Reverse Proxy solution (with Load Balancing capabilities) for your Exchange environment. Once you have understood the different ways in which you can implement IIS ARR, you can see that it is a very flexible solution and can be modified to suite each of your custom needs.
One last time, I would like to thank Greg Taylor (Principal PM) for his help in reviewing these article.
Premier Field Engineer, UK
Microsoft
