Lync Mobile 2013 iOS Client and IIS ARR

photoSo a previous post of mine I detailed the installation and use of IIS ARR with Windows 2012 as an alternative to using Forefront TMG as your reverse proxy solution. Microsoft posted a NextHop article a few days later detailing the same information.

So if you have been using IIS ARR you most likely have found that everything was working great however you may have run into a small issue with iOS devices (see the screenshot to the right). The issue is due to how iOS does notifications and we are getting a timeout from the reverse proxy.

A little background:

In the previous mobile client for iOS and Windows Phone they leveraged the Office 365 for push notifications. In the Lync 2013 iOS mobile client they use a native iOS feature called VoIP Socket. What is happening under the hood is the Lync Client is sending a “hanging get” to the Lync Server and specifically to the UCWA application that was introduced in CU1. This hanging get last for at least 10 minutes and is refreshed so the server knows the client is still alive – essentially a presence registration is occurring in Lync. So what is happening is that the IIS timeout is causing issues with the hanging get. So if you are seeing the problem to the side, I would suggest changing your timeout from 180 or 200 seconds to 960 seconds (16 minutes). This will ensure your client doesn’t timeout on the “hanging get” that is associated with push notification.

Once I review the logs I’ll post the relevant parts of the logs showing where the timeout is happening.

Lastly, for completeness I should note that only the Windows Phone Mobile clients still use the Office 365 for push notifications. The new Android client runs in the background and does the notifications differently.

UPDATE: Here is the UCWA application creating the timeout values:

CEventChannelManager.cpp/270:Creating UCWA event channel request with Remote timeout=900, Local timeout=920

9 thoughts on “Lync Mobile 2013 iOS Client and IIS ARR

  • Pingback: Lync Mobile 2013 iOS Client and IIS ARR

  • Pingback: NeWay Technologies – Weekly Newsletter #40 – April 25, 2013NeWay | NeWay

  • May 15, 2013 at 5:55 am
    Permalink

    Also make sure that you have your clients going ALL the way to the outside interface of your RP/ARR box. Trying to shortcut around it with a hairpin nat to the internal interface will cause problems

    Reply
  • June 30, 2013 at 1:16 am
    Permalink

    Anyone seen issues with IIS ARR and iOS devices failing to login? All other clients and all modalities function without issue, just cant get any iOS device to login. I did ensure that it is not a cert issue on the iOS devices by installing the Comodo root and intermediate.

    Reply
  • August 12, 2013 at 5:03 am
    Permalink

    I met same problem on IOS device after ARR deployed.And I also changed time-out to 960s, but error notification still be there.
    Any suggestion,Thanks.

    Reply
    • August 12, 2013 at 9:22 am
      Permalink

      I got it after changing time-out to 960s on both two farms, lyncdiscover and lyncextweb.

      Thanks.

      Reply
      • May 7, 2014 at 4:33 pm
        Permalink

        Check phone logs for 502 error

        Reply
  • May 8, 2014 at 5:35 pm
    Permalink

    I get my external lync clients unable to logon. Lync connectivity Analyzer says reached Maximum Redirects 10.

    Ran your Lync validator and all was fine. Remote Connectivity Analyzer all green, I can go to URL and it prompts to open json file.

    Any ideas? lyncdiscover redirects to external web FQDN and begins loop there

    Reply
    • May 13, 2014 at 9:01 pm
      Permalink

      Never seen anything like that before. Does it also happen with the Windows 8 Store/MX client? If so, maybe a trace with Fiddler will help determine what is going on?

      Richard

      Reply

Leave a Reply to NeWay Technologies – Weekly Newsletter #40 – April 25, 2013NeWay | NeWay Cancel reply

Your email address will not be published. Required fields are marked *