locked
Web app anonymous access fails with error "There was an error while signing in. Please try again" RRS feed

  • Question

  • Hi,

    we are facing an issue were anonymous (external) users cannot join a meeting from the Skype for Business Web app.

    Download of the app works as expected, but when the user types his name and then clicks "Join", an error message "There was an error while signing in. Please try again" is displayed.

    When aynalyzing the issue I discovered the following:

    -On the serverside, the request from the Web App triggers a "400 Bad Request" error. This happens when the client opens the URL https://exrernalwebservicesname/WebTicket/WebTicketService.svc/Anon

    -When I connect internally to the external website like "https://ServerFQDN:4443/WebTicket/WebTicketService.svc/Anon" this triggers the same error - so the error is obviously not triggerd due to a firewall/reverseproxy

    -Joining the meeting from a Skype for Business Client works like a charm - so this is only happening with anonymous users

    The conferencinmg policy allows invitation of anonymous users.

    The WebServices Configuration also allows anonymous access.

    A CLS Logging of UCWA and WebRelay brought no data :-(

    So to be honest I'm a bit stuck here. Any help/hints/tips would be greatlly appreciated!

    Thanks

    Christian

    Wednesday, April 3, 2019 1:21 PM

Answers

  • We were able to fix the issue.

    In the end it was a non-functioning rule on the reverse proxy which mangled the answer from the webticket service.

    After we recreated the rule, everything started working.

    I used fiddler to compare the traffic from our environment to a functioning one. This way I discovered the mangled responses from SfB.

    I hope this gives others a hint where to look at in such a situation...

    Thanks

    Christian Schindler

    Thursday, April 11, 2019 10:48 AM

All replies

  • Hi,

     

    From your description, it seems that you want to access SFB external web service, if this is the case, please make sure you have properly configured Reverse proxy.

     

    We would suggest you check the certificate of RP and Edge of your environment. Also please verify that the internal private root certificate has been input to the RP/Edge server.

     

    Besides, did you have a check if there is any event error reported under the "Event Viewer" of Edge/RP?

     

    By the way, would you please run "Get-CsAccessEdgeConfiguration" as Admin in SFB Mgmt shell to check if the parameter of "AllowAnonymousUsers" has been set to true. Please post the returned info here for further investigation if possible.


    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, April 4, 2019 3:29 AM
  • Hello,

    obviously my description wasn't thorough enough...

    Yes, I'm trying to access a meeting externally.

    But I already checked all the components in between...

    So, Anonymous User Access is enabled on the Access Edge Server. Certificates are also correct. We use public certificates and there is no certificate error if I connect to the external Website of SfB nor when I connect via a SfB Client to a meeting.

    The error occurs in the front end - 400 Bad Request. I can see that in the IIS Logs.

    But I'm stuck in troubleshooting and don't know what to do next.

    In the meantime I tried Failed Request Tracing in IIS - with no success. Only 400 Bad Request is logged - but no the reason...

    Thanks

    Christian

    Thursday, April 4, 2019 6:32 AM
  • Hi,

     

    Please kindly note reverse proxy is required for external clients to access Skype Web App client. Please confirm the following points:

     

    1. Make sure you have added the following SANs entries on the public certificate (if you use SAN certificate) such as:

    lyncdiscover.sipdomain.com, extweb.sip.domain.com (extweb is the external web Service FQDN in topology), etc.

    2. Make sure you have set port redirect for port 443 to 4443, 80 to port 8080. (The front end listens on ports 4443 and 8080 not on 443 and 80.)

    3. On public DNS Server, add the DNS A record lyncdiscover, meet, dialin, extweb to the public IP of 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.

    • Proposed as answer by Calvin-Liu Monday, April 8, 2019 10:00 AM
    Monday, April 8, 2019 9:10 AM
  • Hello,

    thank you for your answer.

    I've done all that. As I said everything works perfectly for authenticated clients.

    Only anonymous users connecting via Web App have this issue.

    Any other ideas on how to troubleshoot the "400 Bad Request" error?

    Thanks

    Christian

    Monday, April 8, 2019 10:46 AM
  • Hi,

     

    You could find the link here for the detailed info of 400 -Bad request.

     

    By the way, could you please try to visit the following website connect internally?

    https://w2016.domain.com:4443/WebTicket/WebTicketService.svc

    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, April 11, 2019 10:08 AM
  • We were able to fix the issue.

    In the end it was a non-functioning rule on the reverse proxy which mangled the answer from the webticket service.

    After we recreated the rule, everything started working.

    I used fiddler to compare the traffic from our environment to a functioning one. This way I discovered the mangled responses from SfB.

    I hope this gives others a hint where to look at in such a situation...

    Thanks

    Christian Schindler

    Thursday, April 11, 2019 10:48 AM
  • Ahh, great, thanks for sharing!

    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.

    Friday, April 12, 2019 1:40 AM
  • Hello.
    Please tell me which parameter you changed in the reverse proxy server
    Friday, January 3, 2020 10:40 PM
  • Hi,

    any change I implemented didn't work.

    We recreated the rule.

    Cheer

    Christian

    Sunday, January 5, 2020 3:11 PM