- #Skype for business connection troubleshooting manual
- #Skype for business connection troubleshooting windows
#Skype for business connection troubleshooting windows
We could also make use of windows Builtin tool Nslookup to check the DNS Resolution. |19:34:00.56 1064 ERROR ResolveHostNameUsingGetAddrInfo - getaddrinfo()|19:34:00.567 1064 ERROR :: ResolveHostNameUsingGetAddrInfo - getaddrinfo()|19:34:00.567 1064 ERROR :: ResolveHostNameUsingGetAddrInfo - getaddrinfo() If we have Logging Enabled on the client, we can open client Side Log ‘Lync-UccApi.Uccapilog’ present in Location “C:\Users\Mouli\AppData\Local\Microsoft\Office\1X.0\Lync\Tracing” using a notepad or any editor, below are sample log where client queries DNS for Since we know from above step that automatic sign in is failing, we can look at client logs to see what all DNS Queries it made and whether it’s able to resolve DNS records or not.
#Skype for business connection troubleshooting manual
If manual sign in worked, we know that Client is able to sign in when its connecting directly to Server/Pool using Manual settings, it’s just the Automatic sign in that is not functional, basically client is not able to determine where to connect to sign in.įor Automatic sign in to work, there are certain DNS Records ( refer to Server Discovery step in previous article) that needs to be configured so that client can make DNS Query and get the Pool Info. Internal Server Name : Front End Pool name & PortĮxternal Server Name : External Access Edge FQDN & Port Skype for Business Client Settings -> Tools -> Personal -> Advancedįor Manual Sign in, provide the Skype for Business Pool name or Server name and the Port number manually in Internal or External Server name Box (depending on whether we are testing internal Sign in or External Remote Connectivity)
To do that, we can edit the Advanced settings and manually provide Skype for Business Server/Pool name like below: Simpler way to identify if DNS Records are the problem is by testing Manual Sign in vs Automatic Sign in method. Typical sign in issue would be that users not being able to sign in and getting one of below errors:Īnd many other errors, depending on what’s causing the issue:ĭepending on the Error, issue cause could be in one of below:īelow approach could help us isolate the issue cause in a systematic manner.ġ : Verify if Server discovery is succeeding or not: Its time to jump to the troubleshooting phase, where we are going to discuss on step by step approach, Collecting required logs and Using different tools that could help in identifying the issue cause. We verified these and even ascertained via telnet that we could connect to the SQL server on the default port 1433.In my Previous Article we discussed about the detailed call flow when a Skype for Business Desktop Client tries to sign in. The first attempts towards resolving this is always to ensure that the installation account has the “SysAdmin” privilege and is a local admin on the SQL server.
From the error message, it sounded as though the installation account didn’t have the required privilege to create the database on the SQL Server/instance, or the account cannot perform remote Database connection or creation.
Scenario and Symptoms: The picture below shows the attempt to deploy the Persistent Chat database from the topology builder with no success. However, because Always ON is still not supported for Persistent Chat, the customer provided another SQL server for the Persistent chat store. Issue: Skype for Business Database installation fails with insufficient privilege error.īackground: My customer had just completed the deployment of Skype for Business 2015 Pool with SQL 2014 for the Pool Back End Store.