Mar 06 2018 05:56 AM
We have 2 Logitech SRS systems that we are testing before a wider rollout (over 70 in total)
We have one kit working perfectly, but the other gives an error saying:
"We can't sign you in because the server couldn't be reached"
However, it does pick up the meeting info for anything the room account has been invited to
To me, both room accounts, hardware, network and build (1703/3.0.16.0) are identical so I can't see why this one device is failing?
I've tried using both the working room account and a normal user on the device but it has the same issue. I can also sign in to the Windows Skype for Business 2016 client using the room account
Any pointers as to where I should look? I've sent myself the logs using the "Give Feedback" feature but not sure what I should be looking for
Mar 06 2018 07:28 AM
Mar 07 2018 03:34 AM
Mar 07 2018 10:28 AM
Any luck. I have the same issue. I know it is behind a proxy but the message is not very helpful. I noticed there is an update to 1709 but it wants to uninstall some Skype things. Have you tried that? Not sure if the system will still work after?
Jason
Mar 07 2018 10:52 AM
Don't upgrade to 1709 https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Skype-Room-Systems-v2-IT-Admins-shoul...
I'm in the office tomorrow so will have a test out with my Smartdock issue.
Mar 07 2018 11:53 AM
I just got it working by added the device to our domain. Not sure that is the correct method? Why would that allow this to work.
Thanks,
Jason
Mar 07 2018 12:45 PM
Mar 07 2018 12:54 PM
I put our domain in the advanced settings and that had no effect. I will try setting up our other one without joining the domain and see what happens.
Jason
Mar 12 2018 09:30 AM
Power looks fine, I can browse web pages under the admin account without issue (including signing into the office portal and Teams online).
I just rebuilt one of the devices and it's happened again, although this time, signing-in over WiFi and then back in over the LAN didn't fix it :'(
I'm logging this with Premier Support now
Apr 25 2018 04:52 AM
Had the same issue, but mine was solved after doing a full manual sync from our local AD.
Apr 29 2018 05:59 PM
Sounds cert related, if domain joined all ok as trust pushed via GP, if not joined then manual import of cert required.
- see https://docs.microsoft.com/en-us/skypeforbusiness/deploy/deploy-clients/console
"The Skype Room Systems v2 device needs to trust the certificates used by the Skype for Business and Exchange servers it connects to. For O365 this is done automatically, since these servers are using public Certificate Authorities and these are automatically trusted by Windows 10. In a case where the Certificate Authority is private, for instance an on-premises deployment with Active Directory and the Windows Certificate Authority, you can add the certificate to the Skype Room Systems v2 device in a couple of ways:
You can join the device to Active Directory and that will automatically add the required certificates given the Certificate Authority is published to Active Directory (normal deployment option)."
May 24 2018 02:38 AM
SolutionResolved!
We have now fixed this issue and it turns out it was firewall related. This is why it worked on our (Guest) Wi-Fi because that doesn't go through a firewall in the same way.
An easy way to check is to run Microsoft's Network Assessment Tool in "Connectivity Check" mode. It only takes a minute to run and enabled us to give our network team the exact info on what was getting blocked.
It turned out, although we had added all of the URLs & IPs from the official Microsoft list, our next-gen layer 7 firewall was blocking particular ports (UDP 3478, 3479, 3480, 3481). We had to add these ports to our "STUN rule" to get them working.
After that was done, the SRS logged in immediately
Mar 19 2019 07:17 AM
Mar 19 2019 08:31 AM
May 24 2018 02:38 AM
SolutionResolved!
We have now fixed this issue and it turns out it was firewall related. This is why it worked on our (Guest) Wi-Fi because that doesn't go through a firewall in the same way.
An easy way to check is to run Microsoft's Network Assessment Tool in "Connectivity Check" mode. It only takes a minute to run and enabled us to give our network team the exact info on what was getting blocked.
It turned out, although we had added all of the URLs & IPs from the official Microsoft list, our next-gen layer 7 firewall was blocking particular ports (UDP 3478, 3479, 3480, 3481). We had to add these ports to our "STUN rule" to get them working.
After that was done, the SRS logged in immediately