With Forefront TMG discontinued and Forefront UAG not supported for all Lync scenarios (hint, hint: mobility), customers will be increasingly looking at deploying ARR to serve as their reverse proxy solution for Lync. The good news is that ARR is fully capable and supported for the reverse proxy role; the bad news is that ARR is still relatively new for this scenario and not all issues are well known or easy to uncover. While working on a Lync 2013 deployment with a customer I ran into an interesting ARR issue specific to mobility clients. All other mobile clients worked but when iOS users attempted to sign-in via their Lync 2013 mobile client they received a “We can’t connect to the server…” error and were unable to successfully sign-in.
To verify I didn’t have a mobility misconfiguration in the environment I used the Lync Connectivity Analyzer to test things out. The results from LCA showed that the minimum requirements passed, which should indicate the ability to utilize mobile devices:
Completed tests for the Mobility (MCX) service.
Your deployment meets the minimum requirements for Lync mobile apps.
Additionally, I was able to successfully browse to all the required external Lync URLs via Internet Explorer using an external PC so I knew that the ARR URL rewrite rules were successfully configured. Despite everything passing and appearing to be externally available, iOS users continued to be unable to sign-in via the Lync 2013 mobile client, so I had to dig a bit deeper.
My first additional examination was to look at the IIS logs on the ARR server to verify there were no unusual HTTP responses or errors during the client login sequence. When looking at the IIS logs I could see that requests were sometimes receiving an HTTP 502 response (Bad Gateway). Based on the user agent header in the ARR logs those 502 requests seemed to correspond with the iOS Lync 2013 client, so I went sleuthing on the Internet for some assistance. My Bing-Fu must have been strong that day because in my searching I was able to come across a TechNet post that closely matched the issue I was seeing. Even more helpful was that the post contained information for a hotfix for Server 2012 ARR – KB2732764:
Hotfix for Microsoft Application Request Routing Version 2.5 for IIS7 (KB2732764) (X64)
This hotfix addresses a problem in Application Request Routing Version 2.5. When ARR is installed on Windows Server 2012 it fails to proxy Windows authentication.
After downloading the hotfix and installing it on the Windows Server 2012 ARR server, iOS clients were able to connect successfully! Eventually this hotfix might be automatically downloaded and installed when you run through the ARR installer (via the IIS Web Platform installer), but for now make sure you include this particular hotfix in your ARR builds to avoid any issues with Lync 2013 mobility clients when using ARR for your reverse proxy.
