none
Edge server ignored on external connectivity test, tried to go to internal lync server.... how to fix? RRS feed

  • Question

  • Not that simple.

    I try to configure a test installation of lync for our domain (lets just say test.com).

    The internal lync serve is lync.test.local, edge at edge.test.local. Edge is also ion theinternet at edge.test.com

    When tying to connect externally all fails. Using https://www.testocsconnectivity.com/ for somename@test.com, with autodiscovery, I get:

    Testing the Remote Connectivity of user somename@test.com
      Specified Remote Connectivity test(s) failed. Please examine below details of specific reason for failure.
     Test Steps
       Attempting to Resolve the host name lync.test.com in DNS.
      The Host could not be resolved.
       Tell me more about this issue and how to resolve it
     
     Additional Details
      Host lync.test.com could not be resolved in DNS Exception Details: Message: No such host is known Type: System.Net.Sockets.SocketException Stack Trace: at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostAddresses(String hostNameOrAddress) at TestOCSConnectivity.Tests.ResolveHostTest.PerformTestReally()  
     

    This leaves me baffling - how would this domain even KNOW how the internal lync server is named? Obviously by checking my srv records (only place), but why is it looking at my srv records, i only see _sipinternaltls._tcp pointing to this name, and this one should not be used by an externl test side, or?

    * Whatsrv records are used now?

    * How do I get this to work?

    It works internally, but I need to demonstrate external connectivity.

    Sunday, January 16, 2011 8:34 AM

Answers

  • Hello Tom,

    The https://www.testocsconnectivity.com/ website actually uses automatic configuration unless you supply other information. If you are seeing different server names come up, you more than likely have an issue with DNS configuration. Below is the excerpt from the Lync 2010 documentation for DNS autoconfiguration, that can be found here:

     

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9720c3f1-ddd4-426b-b98a-f1205561ce00

     

    How Lync 2010 Clients Locate Services

    During DNS lookup, SRV records are queried in parallel and returned in the following order to the client:

    _sipinternaltls._tcp.<domain> - for internal TLS connections

    _sipinternal._tcp. <domain> - for internal TCP connections (performed only if TCP is allowed)

    _sip._tls. <domain> - for external TLS connections

    Where <domain> is the SIP domain used by your internal clients. The last two queries are for clients that are connecting from outside your internal network. When creating SRV records, it is important to remember that they must point to a DNS A record in the same domain in which the DNS SRV record is created. For example, if the SRV record is in contoso.com, the A record it points to cannot be in fabrikam.com, it has to also be in contoso.com.

    The first time you sign in, the Lync client attempts to connect to a Front End pool using each of the three SRV records in order, regardless of whether you are signing in from inside our outside your network. After the Lync client makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the Lync client cannot use the cached value, it queries DNS for the SRV records again and repopulates its cache. For example, this process is followed if you have signed in to the internal network during the day and then take your laptop home and sign in externally.

    After the SRV record is returned, a query is performed for the DNS A record (by FQDN) of the server or Front End pool associated with the SRV record. If no records are found during the DNS SRV query, the Lync client performs an explicit lookup of sipinternal.<domain>. If the explicit lookup does not produce results, the Lync client performs a lookup for sip.<domain>.

     


    Richard McGiboney, Support Escalation Engineer, Microsoft
    • Marked as answer by Ben-Shun Zhu Wednesday, January 26, 2011 10:54 AM
    Tuesday, January 25, 2011 12:34 AM
    Moderator

All replies

  • Hi,

    I presume you are using test.com as your SIP URI.

    This means you need to have different DNS Servers serving you internal and external network. Is it the case, or are you using a single DNS Server?

    Can you provide details about your DNS servers configuration? (internal and public)

    Regards, George


    George Varakis - MVP on Lync Server in Greece
    Sunday, January 16, 2011 9:29 AM
  • Dear tom,

     

    i think problem of ur topology ...did u build ur topology in proper way? and secondly check ur telnet  ur edge external card IP's through 443 ..thirdly try to resolve external DNS A record whcih u had record at ISP .

     

    and Externally check to telnet through DNS A record which u NAT on Public IP's through 443 if not working check ur ISP side port openning and DNS A record.

    Please check above.

     

    Best Regards


    madushka
    Sunday, January 16, 2011 4:24 PM
  • Hello Tom,

    The https://www.testocsconnectivity.com/ website actually uses automatic configuration unless you supply other information. If you are seeing different server names come up, you more than likely have an issue with DNS configuration. Below is the excerpt from the Lync 2010 documentation for DNS autoconfiguration, that can be found here:

     

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9720c3f1-ddd4-426b-b98a-f1205561ce00

     

    How Lync 2010 Clients Locate Services

    During DNS lookup, SRV records are queried in parallel and returned in the following order to the client:

    _sipinternaltls._tcp.<domain> - for internal TLS connections

    _sipinternal._tcp. <domain> - for internal TCP connections (performed only if TCP is allowed)

    _sip._tls. <domain> - for external TLS connections

    Where <domain> is the SIP domain used by your internal clients. The last two queries are for clients that are connecting from outside your internal network. When creating SRV records, it is important to remember that they must point to a DNS A record in the same domain in which the DNS SRV record is created. For example, if the SRV record is in contoso.com, the A record it points to cannot be in fabrikam.com, it has to also be in contoso.com.

    The first time you sign in, the Lync client attempts to connect to a Front End pool using each of the three SRV records in order, regardless of whether you are signing in from inside our outside your network. After the Lync client makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the Lync client cannot use the cached value, it queries DNS for the SRV records again and repopulates its cache. For example, this process is followed if you have signed in to the internal network during the day and then take your laptop home and sign in externally.

    After the SRV record is returned, a query is performed for the DNS A record (by FQDN) of the server or Front End pool associated with the SRV record. If no records are found during the DNS SRV query, the Lync client performs an explicit lookup of sipinternal.<domain>. If the explicit lookup does not produce results, the Lync client performs a lookup for sip.<domain>.

     


    Richard McGiboney, Support Escalation Engineer, Microsoft
    • Marked as answer by Ben-Shun Zhu Wednesday, January 26, 2011 10:54 AM
    Tuesday, January 25, 2011 12:34 AM
    Moderator
  • Hi!

    The same problem.

    Here is an example of our network settings and DNS.

    Edge.local

    Network adapters

    1) External
    46.146.225.130
    46.146.225.144
    46.146.225.153
    46.146.225.154

    2) Internal
    192.168.10.201

    Frontend.domain.local


    Network adapter

    192.168.10.200


    DNS-Records
    SRV: _sip._tls.domain.com access.domain.com   port:443
    SRV:_sipfederationtls._tcp.domain.com access.domain.com   port:5061
    A: access.domain.com   46.146.225.144
    A: webcon.domain.com   46.146.225.153
    A: av.domain.com   46.146.225.154
    A: meetings.domain.com   46.146.225.130
    A: dialin.domain.com   46.146.225.130
    A: meet.domain.com   46.146.225.130

    Using telnet, we can’t connect to access.domain.com 443 or 5061

    We checked connection with Microsoft Lync Server Remote Connectivity Test and get the result:
    The Host could not be resolved. The requested name is valid, but no data of the requested type was found Type: System.Net.Sockets.SocketException Stack Trace: at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostAddresses(String hostNameOrAddress) at TestOCSConnectivity.Tests.ResolveHostTest.PerformTestReally()  

    What may be thу reason and how we can resolve it? 

    Thursday, November 22, 2012 4:36 AM
  • We also had similar issue going on, this is with Lync 2013 in hybrid with Skype for Business with a new domain name. This issue was occurring only when Skype Online (O365 migrated user) was trying to whiteboard. Then we identified that webcon.domain.com and lyncext.domain.com which is on Edge server is not able to be accessed internally. As we created split DNS domains, the issue was resolved. So how Skype online establishes connectivity is by connecting through edge server as it is in cloud. And if from the desktop if the connection could not be established than connection was failing, it does not know internal URL's. That was the reason we were getting that error and so by updating this internal DNS records, we fixed the issue. Please let me know if you have any questions for the same.
    Tuesday, March 27, 2018 5:56 PM