locked
Lync 2013 client can't connect externally to edge server RRS feed

  • Question

  • So I have my edge server set up in the DMZ. 3 ips bound to an interface for external connectivity.

    sip.domain.org (A record)
    webconf.domain.org (A record)
    av.domain.org (A record)

    _sip.tls.domain.org:443 pointing to the same IP as sip.domain.org
    External Lync Clients should be using this srv record to auto-connect, correct?

    I have purchased a thawte ssl cert and bound it correctly to the external interface.  Internal interface is a PKI internal CA cert. Sometimes when doing a testconnectivity from MS, it comes up stating " The certificate couldn't be validated because SSL negotiation wasn't successful", when other times I run the test and it states that it validates the cert correctly, analyzing the cert - no problems found, etc, all looks good and then fails at "couldn't sign in Error Unknown (0x80131500)  Error type: TLSFailureException.

    Not sure where to start looking or why it shows the cert is good sometimes and others not.

    Also when I launch the Lync Server Admin Console, Under Topology,  my edge server is showing Replication with a red X.  Don't know what to look for either.


    • Edited by jackal2001 Tuesday, November 4, 2014 4:05 PM
    Tuesday, November 4, 2014 3:42 PM

Answers

  • Hi jackl2001,

    By default, no policies are configured to support external user access, including remote user access, federated user access, even if you have already enabled external user access support for your organization. To control the use of external user access, you must configure one or more policies, specifying the type of external user access supported for each policy.

    Click on the link below for more details.

    Managing federation and external access to Lync Server 2013

    http://technet.microsoft.com/en-us/library/gg520966.aspx

    Best regards,

    Eric
    • Edited by Eric.YK Wednesday, November 5, 2014 8:26 AM
    • Marked as answer by Eason Huang Thursday, November 13, 2014 2:15 AM
    Wednesday, November 5, 2014 7:42 AM

All replies

  • There are several things that you need to look at, In Lync server 2013, Lync client look for the "Lyncdiscover.domain.com" first for the automatic sign in process. and then the "sip.domain.com" and the SRV record.

    Verify that you have port 80 opened for CRL verification to the the access edge interface. If the port is not opened, you will have issues with the cert validation

    As for the replication, check if you have 4443 enabled to the Edge's internal interface from the FE server. There are some other factors that preventing edge from replicating. Another culprit will be the CRL missing on the certificate that installed in the internal interface. Check the event viewer on the FE server as well as the Edge server and see if there's any pointers that would explain what might be the problem


    http://thamaraw.com

    • Proposed as answer by Eric.YK Wednesday, November 5, 2014 7:18 AM
    Tuesday, November 4, 2014 5:04 PM
  • Yes I'm getting the CRL couldn't be downloaded from the internal interface edge cert.  I'm not sure how to fix that as I don't control our PKI environment.

    For 4443 on the edge server internal interface I followed this document:
    http://lyncme.co.uk/microsoft-lync-server-2013/quicktips-edge-server-replication-port-4443-is-open-but-replication-is-false/
    I can get to that website from https://edgepool.domain.com:4443/replicationwebservice

    Lyncdiscover.domain.com is pointing to our Proxy server and shouldn't be needed for a fat client on a pc.  Our mobile client on a cell phone works fine.

    EDIT:

    I decided to follow the rest of the above document and added the registry value of:
    HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL = 2
    I then rebooted my Edge server and ran the PS script to invoke replication.

    when I run a get-csmanagementstorereplicationstatus it now shows my edge server as uptodate:true.

    I can now log in with my fat client externally.

    • Edited by jackal2001 Tuesday, November 4, 2014 6:38 PM
    Tuesday, November 4, 2014 6:15 PM
  • as for the CRL of the internal cert, have the CA certificate downloaded in .p7b format which has all the components in it and upload it to the Edge.

    Lyncdiscover.domain.com will obviously talk to the reverse proxy but, that is the path that the client will take to look for the registrar server. If that's not there, then it will be sip.domain.com record

    try setting the external server address on the client as sip.domain.com:443 and see is that finds the server. If not, try running the Remote connectivity Analyser tool to see where it'a failing.


    http://thamaraw.com

    Tuesday, November 4, 2014 7:36 PM
  • remote connectivity analyzer shows successful now and everything running on 443.
    Tuesday, November 4, 2014 7:42 PM
  • so then it should connect now. Have you tried manually specifying the external server FQDN as i mentioned above? Apart from that, you can check the sign in logs when the client tries to sign in.

    http://thamaraw.com

    Tuesday, November 4, 2014 7:47 PM
  • I stated above that the fat client can now connect. All looks good at least for this one part.
    Tuesday, November 4, 2014 7:49 PM
  • any other issues that you're having? Try the auto discovery and see if that works as well.


    http://thamaraw.com

    Tuesday, November 4, 2014 7:50 PM
  • the only other thing I need to try is to federate with someone. not really sure if I need to do anything other than enable it in the admin console.  I don't know if I need to specify allow/block domains. Back in my OCS2007 days, we had open federation enabled so as long as we had another users email address it would work.

    I would like to test with you if I don't need to do anything else.  I think I just need your email address, correct?

    Tuesday, November 4, 2014 7:54 PM
  • yes.. and port 5061 need to be opened in to the access edge and as you said, you probably have _sipfederationtls._tcp.domain.com pointing in to sip.domain.com (Access edge). You can add me on thamaraw@uctechie.com and see if that works. I'm on line now.


    http://thamaraw.com

    Tuesday, November 4, 2014 7:58 PM
  • Yes I have that srv record pointing to my access edge on 5061 and it should be opened though the firewall but it isn't working. Arrgghh
    Tuesday, November 4, 2014 8:03 PM
  • can i know the FQDN of the access edge? and the domain name. Can you telnet to 5061 from outside of the domain (Internet) to that fqdn (sip.domain.com) ?


    http://thamaraw.com

    Tuesday, November 4, 2014 8:05 PM
  • sip.lvhn.org is our access edge fqdn. lvh.com is our domain.

    yes I can telnet to sip.lvhn.org 5061 externally.

    • Edited by jackal2001 Tuesday, November 4, 2014 8:07 PM
    Tuesday, November 4, 2014 8:07 PM
  • email address or SIP ID? 

    http://thamaraw.com

    Tuesday, November 4, 2014 8:08 PM
  • Tuesday, November 4, 2014 8:09 PM
  • Content-type: application/sdp;call-type=im

    v=0

    o=- 0 0 IN IP4 172.31.250.64

    s=session

    c=IN IP4 172.31.250.64

    t=0 0

    m=message 5060 sip null

    a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/x-ms-ink application/ms-imdn+xml text/x-msmsgsinvite

     

    Response Data:

    504  Server time-out

    ms-diagnostics:  1063;reason="Cannot route to blocked IM Service Provider";domain="uctechie.com";fqdn1="sipfed.online.lync.com:5061";source="sip.lvhn.org";OriginalPresenceState="0";CurrentPresenceState="0";MeInsideUser="No";ConversationInitiatedBy="6";SourceNetwork="5";RemotePartyCanDoIM="Yes"

    Resolution:

    If this error continues to occur, please contact your network administrator. The network administrator can use a tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit in order to interpret any error codes listed above

    Tuesday, November 4, 2014 8:12 PM
  • can you telnet sip.uctechie.com over 5061 from the PC that you trying to do the federation? 


    http://thamaraw.com

    Tuesday, November 4, 2014 8:16 PM
  • seems so, just get a blinking cursor when I run c:> telnet sip.uctechie.com 5061

    Not sure why it is logging "="Cannot route to blocked IM Service Provider";domain="uctechie.com"

    Do I need to allow that domain in my admin console or should it work without specifying it?

    Tuesday, November 4, 2014 8:18 PM
  • I am leaving work for the day. I will check back with you tomorrow. Please let me know if I need to do anything else. 
    Tuesday, November 4, 2014 8:29 PM
  • I am on O365 and that should not prevent you from adding me. I can try specifying your domain as an allowed domain and see if that helps. Any chance that you have added lync online in to the block list?


    http://thamaraw.com


    Tuesday, November 4, 2014 8:30 PM
  • I don't think I have lync online enabled as a federated partner in the admin console.

    Also one other question.  I'm not sure where to point sip.domain.com in INTERNAL dns to.  On my ocs 2007 env I had it pointing to my edge server.  In my lync 2013 env I have sip.domain.com pointing to my FE Pool, for internal DNS.  Is that correct?

    Tuesday, November 4, 2014 9:01 PM
  • sip.domain.com goes in to the FE server pool FQDN. Not the edge server. Try adding @uctechie.com domain as an allowed domain and see if you can reach me. 


    http://thamaraw.com

    Tuesday, November 4, 2014 9:09 PM
  • Hi jackl2001,

    By default, no policies are configured to support external user access, including remote user access, federated user access, even if you have already enabled external user access support for your organization. To control the use of external user access, you must configure one or more policies, specifying the type of external user access supported for each policy.

    Click on the link below for more details.

    Managing federation and external access to Lync Server 2013

    http://technet.microsoft.com/en-us/library/gg520966.aspx

    Best regards,

    Eric
    • Edited by Eric.YK Wednesday, November 5, 2014 8:26 AM
    • Marked as answer by Eason Huang Thursday, November 13, 2014 2:15 AM
    Wednesday, November 5, 2014 7:42 AM