locked
sfb 2015 - Mobile app doesn't connect RRS feed

  • Question

  • Hi there,

    I have recently deployed and published skype for business 2015 and also configured external DNS. While my windows clients can sign in internally and externally, the ios and android devices can do this only internally.

    I have set a srv records that points to sip2.contoso.de (sip was already used by a different voip system) and forwarded 443 and 444 to the edge server, ports 5061 and all the other needed ports also (5269, 3478, 50000-59999). 

    srv point at:

    _sip2._tls.contoso.de - 5061
    _sipfederationtls._tcp.contoso.de - 443

    I also created an a-record sipexternal.contoso.de that points to the primary external ip - that was necessary because the windows clients couldn't sign in without it.

    Because the mobile clients couldld't sign in, I use a second public ip and forwarded 443 to 4443 and 80 to 8080 with a reverse proxy to the front end and used the a-record lyncdiscover pointing at this secondary ip

    Still the mobile clients can't sign in externally and obviously cannot autodiscover. 

    Microsoft Online Connectivitiy Analyzer says "autodiscovery is ok". It discovers lyncdiscover.contoso.de 

    The connectivity test tells me: The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server sip2.contoso.de on port 443.

    A manual run on port 5061 succeeds. When I do this with lyncdiccovery.contoso.de it also fails. I am a little bit confused, obviously there is a misconfiguration in my setup.

    Do I also have to NAT 5061, 5269, 3478, 50000-59999 for the secondary IP? Or should I better change the a record "lyncdiscover" to a cname that points to my primary a-record "sip2.contoso.de"?

    Thanks and regards

    Marcel

    • Edited by wameniak Saturday, February 16, 2019 1:24 PM
    Saturday, February 16, 2019 1:04 PM

All replies

  • Hi,

     

    Just confirming if you have add an A record for external web service FQDN pointing to RP public IP to ensure web service be configured well?

    Please check your DNS records and should be configured as following for Edge and reverse proxy:


    Besides, please check if Front End server is listening on ports 4443 and 8080 which is what the mobility client will look at instead of 443 and 80. When you hit the RP on 443 (or 80) it will publish back to the 4443 ports.

    And here is an article describes how to Deploy and Configure Mobility for Skype for Business Server could be as the reference: https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-and-configure-mobility

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Monday, February 18, 2019 7:45 AM
  • Hi Calvin,

    I followed your advice and rechecked my DNS ... there were indeed some a-records missing. 

    First of all, I use two external ips. The srv-records point to the first, as does sip, the access edge and conf. I used in some cases different hostnames, for example sip2.contoso.de (because sip was used by something else).

    Lyncdiscover, meet, dialin and external webservices go to the reverse proxy and are pointing at the second public ip and go 443 to 4443 for the front end server..

    My nat-rules for all those edge ports point at the first ip and are going to the edge server.

    Now the microsoft online connectivity analyzer tells me that autodiscover is ok (and that it detects lyncdiscover.contoso.de) but the connectivity analyzer tells me:

      

    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server sip2.contoso.de on port 443.
     The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate

    Additional Details

    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 381 ms.

    This is confusing me, because sip2.contoso.de points at the first ip and this one is nat'ed to the edge server. The edge server has all the necessary certificates configured.

    The mobile app can also still not sign in.

    Thanks again for assistance and regards

    Marcel

    Monday, February 18, 2019 5:49 PM
  • One more update - when I set the connectivity analyzer to "manually" and set it to port 5061 and enter "sip2.contoso.de" the connectivity analyzer is able to connect.

    Something must be wrong with the https nat but the port is open and published to the same internal edge ip as port 5061.

    I am slightly confused :(.

    • Proposed as answer by Calvin-Liu Thursday, March 7, 2019 3:01 PM
    Monday, February 18, 2019 6:00 PM
  • Update: The problem seems to be solved, although I wonder that the app informs me, that I am redirected to autodiscover.contoso.com, which is an URL for exchange. But nevertheless, the app connects.

    I guess my issue was caused by a missing a-record for the web services URL.

    Thanks again!

    • Proposed as answer by Calvin-Liu Tuesday, February 26, 2019 9:28 AM
    Wednesday, February 20, 2019 9:45 AM
  • Glad to hear the issue is resolved, thanks for sharing, wameniak!

    I would also suggest you refer to the post regarding port requirement for reverse proxy to have a full understand:

    https://docs.microsoft.com/en-us/lyncserver/lync-server-2013-port-summary-reverse-proxy

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, February 21, 2019 10:40 AM
  • Hi,

    Any update for this query? If the reply is helpful to you, please help mark it as an answer as this will assist users who have similar issues find the answer more efficiently in the community.

    Kind regards, 

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to shareexplore and talk to experts about Microsoft Teams.


    Wednesday, March 6, 2019 8:26 AM