Lync Server 2013 issue with Exchange Autodiscovery

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

Level: Error

Description: Storage Service had an EWS Autodiscovery failure.

ExchangeAutodiscoverException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed,, Autodiscover Uri=, 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 ““. For this account, the corresponding SIP URI and primary email address were the same as the account name.

The Microsoft Office 365 tenant was


In our environment with a hybrid Exchange configuration, the DNS A record for 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 -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 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 but didn’t have permission to do so.


To resolve the issue we ran the following command:

Set-CsOAuthConfiguration -Identity Global -ExchangeAutodiscoverAllowedDomains *

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.

1 Comment

  1. Fernando dos Santos

    Hi Peter, good afternoon.

    Your tip was so useful. I apreciate it.

    Peter, the error gone, but only our on-premise users can sign in OWA IM.

    Exchange Online users only have a interrogation signal and no error are logged on
    my FE or Edge Skype servers.

    Do you have any idea?

    Best regards!


Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.