To find more about the authentification issue I had to digging into the logs on the Frontendpool resp Registrar Server. But unfortunately this will not tell me what’s going wrong under the hood. So now we can be sure that we had no network connectivity issues, the problem is related to authentification.
The whole sign-in process and why it’s quite normal to see some 401 Unauthrized messages you can read at the sites I will provide below.īut of course it’s not quite OK to see only 401 messages to our Register requests. The Client first tries to connect without an authentication header to gets in response the available authentification methods. It is quite OK depending on the three available authentification methods (NTLM, Kerberos or TLS-DSK), that you will see here some 401 Unauthorized messages first before seeing an SIP/2.0 200 OK. Open the file will show us that all our Register messages get an 401 Unauthorized message back.
SKYPE FOR BUSINESS APP LOGS OUT DOWNLOAD
You can download it from the internet or you will find it on your SFB Server Frontend Server under C:\Program Files\Skype for Business Server 201x\ClsAgent To inspect this file you can use any text editor but to focus on relevant sip messages better use Snooper. UccApilog files contain general client usage information and is our first choice for digging into. %LOCALAPPDATA%\Microsoft\Office\16.0\Lync\Tracing
SKYPE FOR BUSINESS APP LOGS OUT WINDOWS
On a Windows computer, the logs for a Skype for business desktop client will be located in the following directory: etl media log files will have names that look like this: Lync-UccApi-].UccApilog where ] should be replaced by a number 0-2. UccApilog files will have names that look like this: For bugs not related to Audio/Video, the. etl files contain media-specific log informationįor any bugs related to Audio/Video, please attach both log types if possible. UccApilog files contain general client usage information There are two types of logs available from the desktop client: So now the next step is to inspect the local log files from the desktop client. If the TCP 3-Way-Handshake to both services could be established with telnet, we can presume that network connectivity is not our problem. The lyncdiscover.tld points to the webservices IP resp your reverse proxy which publishes the webservices URLs. Trying to access the webservices from the internal frontendpool on port 443. Tcp port 5061 on edge access server is typically used for federation and not relevant for our sign-process. Trying to access the edge access server and tcp port 443 which uses desktop client for sign-in. The edge access server also had published tcp port 5061 for federation. Now we can test if we can establish a tcp connection to the webservices which listens on tcp port 443 and the edge access server also on tcp port 443 for sip signalling which is used by our external desktop clients for authentification. So the first thing was testing if DNS is working and I will get the correct IPs for the Webservices FQDN and the Edge Access Server FQDN.Įverything was fine and I got the correct IPs. Here you can see the sign-in attempt from external at the affected client.īecause of this error message the first thought was network connectivity issues. Internal the affected clients can sign-in without any issues. So this is always an ungrateful situation and costs a lot of time digging into it, especially since the skype for business sign-in process is very complex. Recently I had to deal with sign-in issues a few external sfb desktop clients on a non-regular basis experience.
0 kommentar(er)
