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.
Read more at source: http://blogs.technet.com/b/exchange/archive/2013/08/05/part-3-reverse-proxy-for-exchange-server-2013-using-iis-arr.aspx