Forum Discussion
Skype for Business hybrid - Issues between on-premise and Teams only users
ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";expected-fqdn="sfbedge.mydomain.com";certName="a-lgw-uswe-02.lgw.skype.com";cause="Possible server configuration issue";info="The peer certificate does not contain a matching FQDN";source="sipfed.online.lync.com";source-server="RD38563D7FA25E"
This indicates an issue with your certificates and the 30 seconds dropped calls usually indicates an issue with A/V certificate. So check your A/V certificate, remember a new certificate should be assigned using -roll as the already issued tokens are valid for up to 8 hours.
Also check if your firewall does any deep inspection on the A/V connections, this could also be an issue with the same symptoms.
/Kenneth ML
- mbalint987Nov 01, 2022Copper Contributor
KennethML In the meantime, I tried to continue the troubleshooting, and I found out the following:
It seems that the Skype for Business client disconnects the call because we don't get any answer for our OK mesage.
Let me show you these screenshots:
Do you have any ideas about why don't we get ACK for the 200 OK? I checked the network with no luck and I don't have any more ideas.
- KennethMLNov 02, 2022MCTInteresting. I haven't seen this behaviour previously and I don't see it at a customer site (yet).
It could still indicate a problem with setting up the media path as the ACK should be sent when media path is established (late media).- EduNic1800Nov 02, 2022Brass Contributor
Ye maybe the media path changed without documentation?!
I have already tried with "ANY-Port/Protocol" for incoming and outgoing for the EDGE-Part - same issue.Also i dont think its media (only) because we cannot see the peresence of the Teams users from onprem. But its working if i query an onprem user from Teams.
- EduNic1800Nov 01, 2022Brass Contributor
i can confirm the missing ACK:
https://data.dieseltechnic.com/public/file/M2sRV8-YY06s6YGtMDoIsw/2022-11-01%2023_08_38-Window.png
whats your CU on SFB19? Could
KB4470124
Version:2046.409
Date Published:10/4/2022
Be the cause of the issue?
- mbalint987Nov 01, 2022Copper Contributor
EduNic1800 Let me paste the output of the relevant cmdlets:
Before I ran into this issue we used an around 1.5 years old version of SfB 2019 but after that I installed the lastest updates on the Standard Edition and Edge.
- EduNic1800Nov 01, 2022Brass Contributor
There were no such changes on our site. What also makes me curious:
ms-diagnostics: 1010;reason="Certificate trust with another server could not be established";expected-fqdn="external.edgefqdn.com";certName="c-lgw-euno-02.lgw.skype.com";cause="Possible server configuration issue";info="The peer certificate does not contain a matching FQDN";source="sipfed.online.lync.com";source-server="RD38563D80164B"
expected-fqdn=is our external edge name but certName="c-lgw-euno-02.lgw.skype.com" is something on the MS side.
there we no changes on our site - except for 10/22 Windows Updates and the October SfB19 Update. The Updates were done on Wednesday last week - but the issue appeared today.
- KennethMLNov 01, 2022MCTIt is a bit strange, I agree, but I know there usually is an explaination.
The diagnostic string tells us following:
source="sipfed.online.lync.com" = This message is from external party
expected-fqdn="external.edgefqdn.com" = This is your Edge server external AV interface. Right??
Did you verify the AV cert or do you assume it is fine??
/Kenneth ML- EduNic1800Nov 01, 2022Brass ContributorYes - i checked the certificate - ist still valid till June 2023. Also tried to remove and to reapply it - still the same issue.
"expected-fqdn" equals to the EDGE "Access Edge service" FQDN - not the AV Edge Service.
I have also tried to connect to all three URLs (Edge Service, Web Conf and A/V) with openssl s_client - correct certificate is presented and valid till 06/23. Its a concolidated EDGE with 3 public IPs.
I have also run https://testconnectivity.microsoft.com/tests/OnPremisesSfB/input with A/V Test enabled - everything seems fine. The SSL/TLS for the same url as in "expected-fqdn" is validated fine for TLS 1.0, TLS 1.1 and TLS 1.2.