locked
IE web app external access RRS feed

  • Question

  • Skype for Business Server 2015

    Single servers used:

    During topology setup, internal FQDN are used using internal (.local) – cannot seem to use public without some issue.

     -Standard Edition FE (skype.domain.local; AD joined) –external web services (skype.domain.com)

     -Edge pool (edge.domain.local; not AD joined –external service (sip.domain.com) single IP, ports – 5061, 444, 443

    testconnectivity.microsoft.com passes autodiscover web service.  It fails on the testing remote connectivity due to SSL certificate; as I am currently using an in-house AD based.

    Internal and external, I can use Skype 2016 client and everything works.

    The issue that I have found is that the internal FQDNs are being used during external access for the web app.  At the Skype for Business Web App login screen, prior to installing the plug-in, I can hover the mouse over the Terms and Conditions link and it shows the internal FE server name.  The internal name for the Edge server is also being used in some reference link.

    I can get external access to work if I modify the Windows ‘hosts’ file.

    External IP of meet.domain.com to skype.domain.local

    External IP of sip.domain.com to edge.domain.local

    Any ideas on why this is happening?  Where can I look?

    Thanks in advance.

    Monday, March 6, 2017 4:22 PM

Answers

  • Thanks for all of these thoughts.  After more review of my setup, I believe I found the answer to the initial issue of the internal names being used.  Basically the internal link (443) was being used instead of the external (4443) for the proxy (IIS ARR).  Using telnet and netstat to test for proper ports is how I found this.  Now that I have resolved that portion, I have another issue that is still blocking access.  I am receiving a 401 - Authentication error via the web browser.  I have verified the settings for IIS on the proxy and only anonymous is enabled.

    I do have the required SRV and DNS records set externally.

     
    • Proposed as answer by Jayakumar K Monday, March 13, 2017 6:12 AM
    • Marked as answer by david_wilson500 Monday, March 13, 2017 11:35 AM
    Friday, March 10, 2017 1:45 AM
  • Ok, finally have this resolved.  The 401 error was due to an ARR URL rewrite mistake.  I had http instead of https for the Action URL part of the rule for the External web services FQDN defined in the topology.  Thanks again to everyone.
    • Proposed as answer by jim-xu Monday, March 13, 2017 12:48 AM
    • Marked as answer by david_wilson500 Monday, March 13, 2017 11:35 AM
    Friday, March 10, 2017 1:33 PM

All replies

  • Hi David,

    Did this issue occur when you use another browser?
    Did you internal FQDN show when you schedule a SFB meeting?
    What is the meeting URL you have typed when user access meeting in external organization?

    To troubleshoot this issue, please post the snapshot to us for troubleshooting. Skype for business DNS records could be recorded by the following link: https://technet.microsoft.com/en-us/library/dn951397.aspx


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, March 7, 2017 8:40 AM
  • Hi Jim,

    Same issue using a different browser.  When I start a meeting now, it does use meet.(sip domain) which is for external use.  link is like https://meet.domain.com/user/*****.  If you want domain specific, can I send direct to you?  Thanks.

    Tuesday, March 7, 2017 6:22 PM
  • You should verify the DNS entries created in external DNS. You should not publish internal URLs and pools and server FQDNS on public.If it is available in public only it will look for it.Verify SRV records and Lyncdiscover and lyncdiscoverinternal records.

    Jayakumar K

    Thursday, March 9, 2017 11:44 AM
  • the external DNS records for Access edge, Webconf and A/V ---> Are you using three different public ip address or Private IP address with NAT ?

    On your edge server > The external interface > Are they pointing to External IP address (Published in Public DNS) for the three defined edge services?

    Have you published SRV records in public DNS _sip.tls.contoso.com sip.contoso.com 443

    Have you created a firewall rule that would route traffic from Public IP address to Edge server's External NIC > Then to internal Interface > Then to FE server 


    MCSA Office 365 | MCSA Exchange server 2010 | Red Hat Certified Engineer


    • Edited by Akabe Thursday, March 9, 2017 9:42 PM
    Thursday, March 9, 2017 9:24 PM
  • Thanks for all of these thoughts.  After more review of my setup, I believe I found the answer to the initial issue of the internal names being used.  Basically the internal link (443) was being used instead of the external (4443) for the proxy (IIS ARR).  Using telnet and netstat to test for proper ports is how I found this.  Now that I have resolved that portion, I have another issue that is still blocking access.  I am receiving a 401 - Authentication error via the web browser.  I have verified the settings for IIS on the proxy and only anonymous is enabled.

    I do have the required SRV and DNS records set externally.

     
    • Proposed as answer by Jayakumar K Monday, March 13, 2017 6:12 AM
    • Marked as answer by david_wilson500 Monday, March 13, 2017 11:35 AM
    Friday, March 10, 2017 1:45 AM
  • Ok, finally have this resolved.  The 401 error was due to an ARR URL rewrite mistake.  I had http instead of https for the Action URL part of the rule for the External web services FQDN defined in the topology.  Thanks again to everyone.
    • Proposed as answer by jim-xu Monday, March 13, 2017 12:48 AM
    • Marked as answer by david_wilson500 Monday, March 13, 2017 11:35 AM
    Friday, March 10, 2017 1:33 PM
  • Ok, finally have this resolved.  The 401 error was due to an ARR URL rewrite mistake.  I had http instead of https for the Action URL part of the rule for the External web services FQDN defined in the topology.  Thanks again to everyone.

    Hi David,

    Thanks for your back and share your solution, would you mark your solution as answer so that someone who has similar issues could find this reply in this thread as soon as possible?

    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, March 13, 2017 1:01 AM