locked
Meeting web service url's not working RRS feed

  • Question

  • Hi all,

     

    Hope I can some guidance from you regarding an issue I am experiencing

     

    Environment

     

    - 2 pools with std edition server, each with its edge pool(1 server), reverse proxy and office online server. The network and windows infrastructure is maintained by the internal team, skype for business deployment is done by me. So all dns/firewall/certificat  changes etc are done by the company admin

     

    Background

     

    - One pool was set up last year and works well. I am setting up second pool, everything is set up and functional except Web services and PSTN

     

    Current issue

     

    - Unable to access dialin and meet web service urls. If I access it meet-uk.contoso.com from front end, I get certificate error first and on bypassing it

     

    HTTP Error 403.14 - Forbidden

     

    - Same when I access it from internal network from my laptop

     

    What I have done

     

    - Checked IIS server farm, all settings. Host file, static routes

     

    -Checked DNS  Internal DNS for meet/dial points to the front end server

     

    - Port 4443, 8080 from RP to FE is open- cHECKED

     

    - Had issues with mobility but that's sorted out- works externally. I have not test it internally yet

     

    Probable issue

     

    - When I ping meet-uk.contoso.com from reverse proxy, it goes to external public address which I think may be causing this. Should not it go to fe.. unsure about this?

     

    - Any other suggestions please?  spent a lot of time on this but no progress

     

    Akki


    • Edited by asahni2014 Friday, May 5, 2017 7:40 AM
    Friday, May 5, 2017 7:33 AM

All replies

  • Hi Akki,

    In internal DNS server, please double confirm there is an A record about meet-uk.contoso.com to point to FE server, then check meet-uk.contoso.com has been defined in Skype for business topology builder.

    Then make sure “about meet-uk.contoso.com” has been included in certificate, the re-run certificate wizard on FE to check if the issue persist.

    If the issue persist, check if there are any related errors in application log and post them for our troubleshooting.


    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.

    • Proposed as answer by jim-xu Tuesday, June 6, 2017 4:17 AM
    Monday, May 8, 2017 6:58 AM
  • Hi Jim,

    Thanks for pointing this out. Seems we are getting there

    - DNS entries are correct.

    - The certificate had SAN entries for the first pool ie.

    > meet.contoso.com, sip.contoso.com, dialin.constoso.com, fe.contoso.com and Lync discover ones

    - I created new certificate request and in advanced option, added

    > meet-uk.contoso.com, sip-lon.contoso.com, dialin-lon.constoso.com, fe-lon.contoso.com and Lync discover one along with others.

    Its still the same, I have seen application logs and Lync event logs, there is nothing pointing specifically to this.

    Any other pointers?

    Thanks

    Akki


    Akki

    Tuesday, May 9, 2017 1:31 AM
  • If I try to open the dial or meet link internally, this is the error I get

    HTTP Error 403.14 - Forbidden

    The Web server is configured to not list the contents of this directory.

    As per MS TechNet article I have tried 

    > Enable directory browsing using IIS Manager.  


    Akki

    Tuesday, May 9, 2017 7:11 AM
  • DNS records for internal services only should be created in internal DNS. There should not be any external url names resolved internally,Hope both webservices urls are configured with separate names.Reverse proxy should point to external web services urls of FE servers.Also the reverse proxy should hold the Certficate for the published name.

    FE servers also should have the certificate enabled for both external and internal.

    There should not be any manula settings on IIS.In that case run the deployment wizard to confirm the permission and configuration as per topology.


    Jayakumar K

    • Proposed as answer by jim-xu Wednesday, May 17, 2017 9:45 AM
    Tuesday, May 9, 2017 8:55 AM