| Description of Issue:
In an environment with the following on-premises elements installed, a single user kept experiencing getting dropped from SFB Online Meetings immediately after joining with audio.
- Windows 2012 R2 Active Directory
- Enterprise SFB 2015 Front End Pool
- Enterprise SFB 2015 Edge Pool
- SFB 2015 Persistent Chat Server
- Office Web Apps Server
- Windows 2012 R2 Web Application Proxy
- Windows 2016 IIS ARR
The user began to experience this issue following a perimeter firewall upgrade and laptop rebuild. Ergo, there were several potential culprits as a root cause.
Root Cause Analysis & Resolution:
Since the firewall was recently upgraded, the initial thinking was the inbound access policies could be misconfigured and causing the user to be dropped. The peculiar thing was that other remote users did not experience the same issue. The assumption was that all users should be experiencing the same behavior if the firewall was the issue. Nonetheless, we configured a packet sniffer on the firewall and captured traces from the user with the issue and other users without the issue to compare the traffic flow. All traces showed the clients connecting to the SIP Access, Web Conferencing, and A/V Conferencing Edge interfaces as expected. We did notice that the user with the error was sending TCP rst and ICMP requests to the A/V Conferencing Edge interface right before being disconnected. Ruled the firewall out since it was accepting all the inbound traffic.
Analyzed the PC of the user with the issue beginning with adding exceptions to Windows Defender for the Lync.exe application. Disabled the firewall and real-time protection on the PC. Still the user experienced the issue. Had the user join another organization's SFB online meeting and the user did not experience the disconnect behavior. Looked at the SFB Edge Pool configuration and noticed that there is a SSL certificate assigned that was issued by an internal Certificate Authority (CA) Server. Exported the internal CA Server's root certificate and imported it into the Trusted Root Certificate Authorities store on the user's PC. VOILA! That solved the issue (importing the internal CA's root certificate). |