SOLVED

Skype Room System shows calendar info but can't sign in

Copper Contributor

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

13 Replies
Looks like there is something funny with our network but could still do with help identifying it.

If I connect the smartdock to our LAN it will not be able to sign in
If I then connect it to any public wifi it can sign in.
If I then plug it back into the LAN then it is now able to sign in.

This makes me think it caches something after a successful sign-in that it doesn't need to do on subsequent sign-ins?

So still related to the firewalls on our LAN but not a port/URL that it needs each time!?
Is the dock powered correctly? I've noticed sometimes if the dock isn't powered then no LAN connection is possible.

I have a similar issue, I moved mine from one SfB deployment to a other and then back and I am experiencing signing into the calendar (O365) but not SfB (on-premises). Something I need to troubleshoot.

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

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.

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

That is odd, I've never joined the domain with our SRS systems. Just add in the domain in the advanced settings. Putting it on the domain makes it a trusted device and will allow sign in etc.

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

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

Had the same issue, but mine was solved after doing a full manual sync from our local AD.

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)."

best response confirmed by Thom Mckiernan Admin (Copper Contributor)
Solution

Resolved!

 

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

 

 

Thom, did you achieve this by putting your device in a domain? Or was it stand alone ?
Many thanks, Joris.
They are not currently on the domain
1 best response

Accepted Solutions
best response confirmed by Thom Mckiernan Admin (Copper Contributor)
Solution

Resolved!

 

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

 

 

View solution in original post