SRSv2 Calendar Issue only on Lenovo SmartHub 500 system

[Dan Byne]

Hi All,

We have an issue with one of our clients Lenovo SmartHub 500s and getting a Cannot Fetch Calendar issue.

Here is the background:

• Room account created correctly
• Logs into Skype for Business on the unit just not Exchange
• Account is on Skype for Business Online
• Account is on Exchange Online (Hybrid)
• Exchange 2010 SP1 server on-premise
• Account works on Logitech SmartDock device in another location
• Other accounts that work on Logitech SmartDock don't work on Lenovo
• Lenovo moved to Logitech SmartDock location and the same issue

From this we have ruled out:

• Account creation issues
• DNS issues
• Outlook 2010 SP1 being in the Autodiscover loop
• Network connection issues

So currently we are looking into the OS/Applications on both devices to see what the major difference is.

The Lenovo's come with IoT pre-installed from the factory and the Logitech are self installed with Windows 10 Enterprise so they are very similar although IoT is another name for LTSB so maybe a little outdated with feature updates but that should be the main difference.

Does anyone out there have any advice for moving forward? I can't see anything in the release notes for this issue so assume it hasn't been found before.

The error logs don't show anything interesting about the Exchange part at all.

Thanks,

Dan

[#2 · Accepted solution]

Does it actually fail to fetch the calendar long term … I assume so? We hit this issue often with one customer but it is temporary as the message goes away after a few seconds, and we don't see issues with the calendar showing up if the room is booked. We haven't tried to investigate as it self fixes so can't offer any great pointers.

However, Exchange 2010 used for auto discover is not supported. We recently had to update the local hosts file to get around autodiscover not allowing a redirect from Exchange 2010 to Exchange 2016. You could add a local hosts file entry in the SRS to point to Exchange online to cover this off if that is your issue. Note we also got warning messages saying Exchange 2010 wasn't supported which alerted us to this issue, but it could have been the SP wasn't up to date also as the Exchange version was being decommed at the time.

https://docs.microsoft.com/en-us/skypeforbusiness/manage/skype-room-systems-v2/room-systems-v2-opera...

Jed

[#3]

Hi Jed,

Thank you for the reply.

I agree with the Exchange 2010 part and it not being supported, mainly the redirection that it does causes the issues.

The local IT guys on site have forced the autodiscover to use Office 365 services and it connects as it should.

I think they must have had the issue before with another device and hadn't told us their workaround even though it was one that we suggested initially after discovering the Exchange 2010 in the middle of the loop.

Thanks again,

Dan

[#4]

@Dan Byne 

We have added a host file that directs outlook.office365.com to  

40.97.142.34

Our smart hub blinks back and forth with Cannot fetch calendar

we are running SRS 4.0.85.0

SFB on prem works fine

Outlook hybrid mode with 2010 on prem.

Any other hints / tricks anyone have up their sleeves??

Thanks,

Jim

[#5]

Hi @jimsmithcsgicom,

It might be worth adding a few more entries into the hostfile just in case that one entry is unavailable (autodiscover.outlook.com):

40.101.51.200
40.101.55.56
40.101.12.8
40.101.90.184
40.101.54.184
40.101.43.184
40.101.12.88
40.101.50.216
40.101.125.216

Also make sure that each is set to autodiscover.<yourdomain>

It's not the best workaround, especially if you have quite a few of them, a separate DNS server with the CNAME in and forwarding upstream would be a better idea and just assign this DNS server to these devices using custom DHCP options.

Also make sure the exchange account is hosted in O365 and not on premise otherwise O365 will point the device back to your on-premise Exchange server.

This has worked with a few of our customers that are running legacy Exchange.

Thanks,

Dan

[#6]

Dan,
Revealing all of the reply's looking up (nslookup) autodiscover.YOURTENNENT.onmicrosoft.com
Gave me exactly what we needed for the host file and it works fine.
Thanks,
Jim

[#7]

I had to create an entry in the hosts file for autodiscover.YOURDOMAIN.  This was due to our on prem AD server not forwarding the request.