none
The server returned a trust fault: 'The request scope is invalid or unsupported'. RRS feed

  • Question

  • Since three weeks people had issue's signing in to Lync using Automatic Configuration (manual configuration works). The error is shown as follows:

    .]]></Info>

            <Info><![CDATA[CLogonCredentialManager::GetProxyCredentials()Requesting credential user 0x108F7918 id=15 asking for credentials with ProxyChallengeDetails[authModes=0, firewallName=, realm=]]]></Info>

            <Info><![CDATA[Default Windows credential obtained for asyncContext=1A436E40.]]></Info>

            <ExecuteWithWindowsOrNoAuthInternal>

              <ExecutionDuration>0</ExecutionDuration>

              <SequenceID>1.1.1.1.4</SequenceID>

              <hr>0x3d0000</hr>

            </ExecuteWithWindowsOrNoAuthInternal>

            <ExecuteWithMetadataInternal>

              <ExecutionDuration>0</ExecutionDuration>

              <SequenceID>1.1.1.1.5</SequenceID>

              <hr>0x3d0000</hr>

            </ExecuteWithMetadataInternal>

            <Info><![CDATA[Executing wws method with windows auth auth, asyncContext=1A436E40,

     context: WebRequest context@ :442066040

      MethodType:4

      ExecutionComplete? :1

      Callback@ :0C5EAA14

      AsyncHResult:80f10041

      TargetUri:https://EUpool.eur.domain.lcl/WebTicket/WebTicketService.svc

      OperationName:http://tempuri.org/:IWebTicketService

     Error:

    The server returned a trust fault: 'The request scope is invalid or unsupported'.

    Have checked the DNS records over and over again, but they are all correctly configured. Have checked the certificates, and they seem to check out as well. Extensive troubleshooting pointed out three things which are totatlly irelevant to each other. 

    When we rename the old Windows profile and the user sign's in with a new windows profile, lync is able to sign in using automatic configuration.

    When we bypass the hardware loadbalancer (used for Lync webservices and LyncdiscoverInternal.sipdomain.com), automatic configuration works again for internal users. Vpn users are still effected with the same error code. 

    Not everyone is effected, yet a decent amount of people which are both using Windows10 and Windows7. We have deployed Office365 version 16.0.10730.20264 & 16.0.10730.20122, but people with the Lync 2013 basic client are also effected.

    Does anyone got a clue?

      


    Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.

    Monday, March 4, 2019 12:55 PM

Answers

  • Cracked the nut last week. And i must say it was a misconception i had about the "internal override FQDN". 

    I though the  "internal override FQDN" was used when you differntiate the External webservices url from the internal webservices url. This isn't the case, as we have a split-brain DNS. So the internal and external webservices url are the same. 

    Wel this was a misconception, because when you do not define the Internal Override FQDN. Lync will use the Front-end pool FQDN internally to access the webservices. Now this shouldn't provide any issues as the pool fqdn resolves to each front-end server individual, where the WebServices are actually running in the end (bypassing the hardware loadbalancer). 

    https://uclobby.com/2015/06/05/lync-sfb-how-to-configure-internal-web-services-override-fqdn/

    helped me to crack the nut, because the issue went away right after we pushed the internal override FQDN.

    Now, it has been driving me nuts, but cannot explain how the issue is related to the resolution. If you simple rely on DNS load balancing for your High availability, you woukld have the same supported configuration.   



    Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.


    • Edited by Killerbe Wednesday, March 13, 2019 2:43 PM typo's
    • Proposed as answer by Calvin-LiuModerator Friday, March 15, 2019 9:38 AM
    • Marked as answer by Killerbe Wednesday, March 27, 2019 9:44 AM
    Wednesday, March 13, 2019 2:41 PM

All replies

  • Hi,

     

    Please help confirm the following points to narrow down the issue:

     

    1. Did you make any changes before the issue occurred?
    2. Is there any event error reported in "Event viewer" of Edge server and Front end server?
    3. What is your load balancer working for, front end server or edge server? Have you verified the certificate of load balancing is valid?

    Reference: https://exchangequery.com/2016/10/03/load-balancing-edge-services-over-internet-for-skype-for-business/

    https://docs.microsoft.com/en-us/lyncserver/lync-server-2013-scaled-consolidated-edge-dns-load-balancing-with-private-ip-addresses-using-nat

     

    In addition, please check the following required DNS records to see if you have configured both internal and external properly.


    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.

    Tuesday, March 5, 2019 7:26 AM
    Moderator
    1. Did you make any changes before the issue occurred?

    Not to Lync, however we moved from Office2016 to Office365 Click to run.

    1. Is there any event error reported in "Event viewer" of Edge server and Front end server?

    We see event 41025 (No connectivity with any of Web Conferencing Edge Servers. External Lync clients cannot use Web Conferencing modality.) /41026 (Connection to the Web Conferencing Edge Server has succeeded) appearing on all three frontend servers in the pool, however this is nor related to the issue at hand. Besides, external people are able to join conferences. 

    1. What is your load balancer working for, front end server or edge server? Have you verified the certificate of load balancing is valid?

    The internal loadbalancer is only used for Lync webservices.

    1. lyncdiscoverinternal.sipdomain.com
    2. lyncdiscover.sipdomain.com
    3. ReverseProxyurls -> Internal Web Services/meet/Dialin/Admin

    The internal load balancer is configured in SSL passthrough mode, where the server's certificate is used (from enterprise CA). The external load balancer is configured in SSL offloading, wherefore our public certificate is used.

    No internal override FQDN is configured, wherefor the same webservices url is used internal as external.

    SRV records, we are an open federation, people are able to communicate with external parties at will. No issue reported on that end, so yes all proper records are in place. https://testconnectivity.microsoft.com/ completes all tests successfully. Our users are able to connect to Lync when they are outside, howeve fail to connect when the vpn client (split tunnel vpn) is anabled. We have tested DNS records when VPN is connected, and they all resolve to the internal records as they should. We even took packet traces, and saw that sometimes resets the connection. 

     


    Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.

    Tuesday, March 5, 2019 10:30 AM
  • Hi,

     

    Thanks for the detailed explanation.

    It seems that the issue only occurs to the internal users who connected with VPN during the sign in process.

     

    As we don't have such testing environment, it is a bit hard to drag deeper for the issue.

    But here I found two articles describing the related connection issues in the case of SFB and VPN, hope it could give you some reference:

    https://www.stevenjordan.net/2013/09/lync-client-and-vpn-connection-problems.html

    https://www.stevenjordan.net/2014/08/configure-lync-clients-on-split-tunnel.html

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

    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.


    Saturday, March 9, 2019 8:57 AM
    Moderator
  • Cracked the nut last week. And i must say it was a misconception i had about the "internal override FQDN". 

    I though the  "internal override FQDN" was used when you differntiate the External webservices url from the internal webservices url. This isn't the case, as we have a split-brain DNS. So the internal and external webservices url are the same. 

    Wel this was a misconception, because when you do not define the Internal Override FQDN. Lync will use the Front-end pool FQDN internally to access the webservices. Now this shouldn't provide any issues as the pool fqdn resolves to each front-end server individual, where the WebServices are actually running in the end (bypassing the hardware loadbalancer). 

    https://uclobby.com/2015/06/05/lync-sfb-how-to-configure-internal-web-services-override-fqdn/

    helped me to crack the nut, because the issue went away right after we pushed the internal override FQDN.

    Now, it has been driving me nuts, but cannot explain how the issue is related to the resolution. If you simple rely on DNS load balancing for your High availability, you woukld have the same supported configuration.   



    Answers provided are coming from personal experience, and come with no warranty of success. I as everybody else do make mistakes.


    • Edited by Killerbe Wednesday, March 13, 2019 2:43 PM typo's
    • Proposed as answer by Calvin-LiuModerator Friday, March 15, 2019 9:38 AM
    • Marked as answer by Killerbe Wednesday, March 27, 2019 9:44 AM
    Wednesday, March 13, 2019 2:41 PM
  • Oh, glad to hear the issue resolved, thanks for sharing, Killerbe!

    The internal web service FQDN is necessary for discovery process when signing in internally.

    Please help mark your reply as an answer since this will assist the users who will have similar issues to find resolution more efficiently. :)

    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, March 15, 2019 9:38 AM
    Moderator
  • Hi,

    Please help mark your reply as an answer, this will make answer searching in the forum easier and be beneficial to other community members as well. :)

    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.

    Wednesday, March 20, 2019 7:50 AM
    Moderator