We run a hosted a Skype for Business solution. We have had many different users have this issue and it normally seems to happen with VVX410s and VVX500s. We sync the outlook/domain passwords to be the same account and password for Skype but some users seem to always get that message even though outside of the Polycom phone they can access the calender through the skype app just fine its only the phone that is having issues and keeps prompting the warning message.
This has been happening on 5.4 firmware versions. I have already opened a ticket with Polycom but just because we are really looking to get this resolved I was wondering if anyone else had this issue and knows of any work around or way to fix it. I tried disabling exchange altogether on the Polycom but it still happens for these users.
We had a similar issue with this. I believe it came down to the fact that is was trying to authenticate against Exchange using the users SAM account name, rather than a UPN... I'll look back through my notes and see if I can remember how we got around this.
Also when you checked the logs for when it happened did it show the SAM account name? When I check the Polycom logs it will show the UPN being used to try and authenticate to Exchange
Did you see my reply to your other post => here <= ?
In addition what is your Polycom service ticket reference?
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Polycom Global Services
Appreciate this is an old post however does not seem to have a resolution. Ive been working on some Trio8800 and VVX410 with the latest firmware 188.8.131.5238 and 184.108.40.20625 respectively. I found that when signing in the sign in address authenticated to SfB be it online or onprem. Whereas the user field value was used for Exchange sign in. So if putting a local domain and then pre 2000 username in domain and user fields, in situations where mail had been moved to O365 then this failed to pick up EWS settings.
This then worked when leaving the domain field blank and entering the sign in address (SIP)/primary SMTP address of the O365 account in both sign in address and user fields. In most deployments we match SIP, Sign in, UPN, Primary SMTP etc.
Might be obvious to some but had me stumped for a while.