Storage Service had an EWS Autodiscovery Failure–32054

 

I ran into the following scenario during a recent project.  We were migrating Exchange On-Premise to Exchange Online.

Issue:

Users are unable to see Meetings using the Lync Mobile Client, and Event ID 32054 appears in the Lync event log.

Event ID:

Log Name:      Lync Server
Source:        LS Storage Service
Date:          9/18/2015 10:00:00 AM
Event ID:      32054
Task Category: (4006)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      LyncFE.company.com

Description:

Storage Service had an EWS Autodiscovery failure.

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, user1@company.com, Autodiscover Uri=https://autodiscover.company.com/Autodiscover/Autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=ConnectFailure —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 132.245.71.8:443

Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.

 

Setup:

  • Lync 2013 OnPrem with Enterprise Voice
  • Exchange Online – All user mailboxes hosted in O365
  • Exchange UM Online
  • Exchange 2013 OnPrem – Single Hybrid server used only for management
  • SCP – AutoDiscoverServiceInternalUri = $null
  • DNS – A CNAME exists for domain.company.com that resolves to autodiscover.outlook.com
    To integrate Exchange Online in O365 with Lync 2013 On-Premise, the following article was used.

How to integrate Exchange Online with Skype for Business Online, Lync Server 2013, or a Lync Server 2013 hybrid deployment

 

After following all the steps, we verified the “Online Meeting” link was visible when scheduling meetings in OWA, and it was “assumed” that OAuth integration was working as expected.

Yet we still were receiving 32054 LS Storage Service errors. 

Troubleshooting:

Test-CsExStorageConnectivity –SipUri user1@company.com –Verbose

No connection could be made because the target machine actively refused it 132.245.226.72:443

Test failed.

What we can see here is that the connection was being made to 132.245.226.72, an O365 IP Address. 

This is based on the ExchangeAutodiscoverURL being set to https://autodiscover.company.com/autodiscover/autodiscover.svc.  Autodiscover.company.com has a CNAME in DNS that resolves to autodiscover.office.com

If I open an Internet Browser and try the same request, I receive an ERR_CONNECTION_REFUSED.  So it seems O365 does not like this.  Even though step 6 in the above article states to configure it as so.

The next test was to try and point the ExchangeAutodsicoverURL to the On-Premise Hybrid server.

Set-CsOAuthConfiguration –Identity Global –ExchangeAutodiscoverUrl “https://exhybrid.company.com/autodiscover/autodiscover.svc”

Then re-run the CsExStorageConnectivity Test

Test-CsExStorageConnectivity –SipUri user1@company.com –Verbose

“The autodiscover service couldn’t be located”

Test Failed.

I don’t have the entire Verbose log copied, but essentially what we see is Autodiscover finds the user on the Hybrid server, and tries a subsequent Autodiscover lookup based on the users “targetAddress”.  Which is set to “user1@company.onmicrosoft.com”, which is used for mail flow during coexistence.  This obviously fails. 

So what do we do next???  Call Microsoft for support of course.

Resolution:

HTTP instead of HTTPS

The resolution was actually quite simple.  Change HTTPS to HTTP in the ExchangeAutodiscoverURL when pointing to O365. 

Set-CsOAuthConfiguration –Identity Global –ExchangeAutodiscoverUrl “http://autodiscover.company.com/autodiscover/autodiscover.svc”

The HTTP request will actually redirect to https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc

After changing this to HTTP, we re-ran the CsExStorageConnectivity Test

Test-CsExStorageConnectivity –SipUri user1@company.com –Verbose

Test passed.

 

The following Event IDs were also registered:

 

 

Log Name:      Lync Server
Source:        LS Storage Service
Date:          9/18/2015 2:00:00 PM
Event ID:      32048
Task Category: (4006)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      LyncFE.company.com

Description:

OAuth was properly configured for Storage Service.

 

Log Name:      Lync Server
Source:        LS Storage Service
Date:          9/18/2015 2:00:00 PM
Event ID:      32052
Task Category: (4006)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      LyncFE.company.com

Description:

OAuth STS was properly configured for Storage Service.

 

32054 Event IDs went away, and users were able to see Meetings via the Lync Mobile Client.

5 Replies to “Storage Service had an EWS Autodiscovery Failure–32054

  1. Change from HTTPS –> HTTP: was this suggested by the PSS guy, or you found it via trial and error? Any pointer in the official Technet documentation that HTTPS should NOT be used when Exchange online is in the picture? MSFT is going to update the SfB Technet docs if its misleading, or they keep it unchanged, so other people also need to pay for PSS ticket to resolve this?

    1. This was the suggested fix by PSS. There were no published articles that he could reference, but the support engineer had worked on several cases similar and has taken it back to the documentation team to get updated publicly.

  2. Thanks Jeremy, this was an annoying problem that got resolved by switching from https to http! No more annoying Errors in the eventlog 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *