I wrote this article is to try and correct some of the bad guidance already published on the Internet regarding a certain Lync/Skype server issue that we were facing in one of the environments that we support.
In our Lync Server logs we were periodically getting the following error messages:
Event ID: 32054
Source: LS Storage Service
Description: Storage Service had an EWS Autodiscovery failure.
ExchangeAutodiscoverException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=User1@novotips.com, Autodiscover Uri=https://autodiscover.novotips.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL> —> Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: The Autodiscover service couldn’t be located.
Unfortunately this error message wasn’t very helpful in solving this issue which had persisted for several months.
The environment consisted of a Microsoft Lync 2013 Server, and a hybrid Microsoft Exchange 2013 Server. The Lync Server was not in a hybrid configuration.
The account for the affected user was “firstname.lastname@example.org“. For this account, the corresponding SIP URI and primary email address were the same as the account name.
The Microsoft Office 365 tenant was novotipscloud.onmicrosoft.com.
In our environment with a hybrid Exchange configuration, the DNS A record for autodiscover.novotips.com was correctly pointing to our on-premises Exchange server.
During our investigation we noticed that the following command would fail from the Lync Server Management Shell:
Test-CsExStorageConnectivity -SipUri sip:User1@novotips.com -Verbose
The diagnostics showed that the autodiscover mechanism first tried to obtain information from our internal Exchange server. Since the mailbox for User1 was hosted in Exchange Online (i.e. not on our Exchange server), the autodiscover mechanism utilised a series of HTTP redirects to redirect the request to Microsoft.
Near the bottom of the trace we noticed some interesting information that helped to solve the issue. At some point the autodiscovery mechanism redirected to https://autodiscover-s.outlook.com/autodiscover/autodiscover.html but the redirect was not allowed. This is shown in the following extract from the trace:
We also looked at the OAuth configuration on our Lync 2013 server.
The key information from this command is the ExchangeAutodiscoverAllowedDomains field.
The ExchangeAutodiscoverAllowedDomains field defines the collection of domains that autodiscover requests can be redirected to. In our environment, we were being redirected to https://autodiscover-s.outlook.com but didn’t have permission to do so.
To resolve the issue we ran the following command:
Set-CsOAuthConfiguration -Identity Global -ExchangeAutodiscoverAllowedDomains *.outlook.com
The Get-CsOAuthConfiguration command now returned the following:
We performed a search on the Internet about similar issues that other people were facing. In some of these articles we found guidance to use the Set-CSOAuthConfiguration command to change value of the ExchangeAutodiscoverUrl from https to http. Doing this just bypasses the issue without solving it and has the undesired effect of lowering the security of the system. We strongly discourage following this advice and instead encourage people to solve the issue via the ExchangeAutodiscoverAllowedDomains parameter as described in this article.