Problem with Skype for Business and Exchange Online Integration - SOLVED RRS feed

  • General discussion

  • We were having a strange problem with integration between our on-premises Skype for Business infrastructure and Exchange Online.

    In the event log on the SfB front-ends we were getting EVENT 32054 from the "LS Storage Service" with text like this, where the email address belonged to a user with an Exchange Online mailbox:

    Storage Service had an EWS Autodiscovery failure.

    ExchangeAutodiscoverException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=Ben.Lye@example.com, Autodiscover Uri=https://autodiscover.example.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL> --->

    Microsoft.Exchange.WebServices.Data.AutodiscoverLocalException: The Autodiscover service couldn't be located.

       at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.GetSettings[TGetSettingsResponseCollection,TSettingName](List`1 identities, List`1 settings, Nullable`1 requestedVersion, GetSettingsMethod`2 getSettingsMethod, Func`1 getDomainMethod)
       at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.GetUserSettings(List`1 smtpAddresses, List`1 settings)
       at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.InternalGetSoapUserSettings(String smtpAddress, List`1 requestedSettings)
       at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService.GetUserSettings(String userSmtpAddress, UserSettingName[] userSettingNames)
       at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.SendGetUserSettingsRequest(StoreContext ctx, String smtpAddress)
       --- End of inner exception stack trace ---
       at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.SendGetUserSettingsRequest(StoreContext ctx, String smtpAddress)
       at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.GetUserEwsSettings(StoreContext ctx, String smtpAddress, CacheMode cacheMode)

    Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.
    Check event details.  Check autodiscovery Uri is properly configured and reachable. Check that proxy setting is properly configured and reachable.  Validate Skype for Business to Exchange Autodiscovery configuration by following the trouble shooting guide. If problem persists, notify your organization's support team with the event details.

    Running Test-ExCsStorageConnectivity failed for any user whose mailbox was in Exchange Online, but succeeded for all on-prem Exchange mailboxes.  Running the test with the -Verbose flag showed where the failure was occurring, but the errors were not clear.

    You'll see lots of messages like "No Autodiscover endpoints are available", "DnsQuery returned error error 'DNS name does not exist'", "No appropriate SRV record was found", "No matching Autodiscover DNS SRV records were found".

    Autodiscover was hitting our on-premises autodiscover server and getting a referral address to our Exchange Online domain, the process was then continuing to the point where it got a referral to autodiscover-s.outlook.com

    2016/12/07 17:56:37.627 Autodiscover.EWSMA trace, type=AutodiscoverConfiguration, message=<TraceTag="AutodiscoverConfiguration" Tid="10" Time="2016-12-07 17:56:37Z">Redirection URL found: 'https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml'</Trace>
    2016/12/07 17:56:37.627 Autodiscover.Validate Redirection Url,redirectionUrl=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, redirectAllowed=False, reason=no match

    The key part here is "redirectAllowed=False", which is a clue.

    First thing - make sure your OAuth settings are configured correctly, and that it is working.  This script is useful:

    Then, looking back at the OAuth configuration in Skype for Business on-premises, there is a parameter to configure allowed redirect domains, ExchangeAutodiscoverAllowedDomains.

    Our OAuth configuration for Exchange Autodiscover looked like this:

    PS C:\Temp> Get-CsOAuthConfiguration | fl ExchangeAuto*
    ExchangeAutodiscoverUrl                : https://autodiscover.example.com/autodiscover/autodiscover.svc
    ExchangeAutodiscoverAllowedDomains     : "example.com","example.co.uk","example.mail.onmicrosoft.com"

    What we need to do is add "outlook.com" to the allowed domains list.  The problem here is that the documentation on TechNet for doing this is wrong, and so is the value in ExchangeAutodiscoverAllowedDomains above - it needs to be entered as a semi-colon separated string.

    To fix the issue we ran this command (obviously you need to substitute the "example.*" domains for your own):

    Set-CsOAuthgConfiguration Global -ExchangeAutodiscoverAllowedDomains "*.example.com;*.example.co.uk;*.example.mail.onmicrosoft.com;*.microsoft.com;*.outlook.com"

    After a few minutes the Test-CsExStorageConnectivity cmdlet started to succeed for Exchange Online mailboxes.

    Hopefully posting this here helps someone else out who runs into this error.  We had a case open with MS support for our problem, and as a result have asked them to fix the TechNet documentation.


    • Edited by Ben Lye Thursday, December 8, 2016 10:22 AM
    • Changed type jim-xu Friday, December 9, 2016 2:19 AM
    Thursday, December 8, 2016 10:19 AM

All replies

  • Hi Ben,

    Welcome to our forum.     

    Thanks for sharing. We are glad to hear the issue has been solved. If there are any issues in feature, welcome to our forum to get help.

    Best Regards,
    Jim Xu
    TechNet Community Support

    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
    • Edited by jim-xu Friday, December 9, 2016 2:22 AM
    Friday, December 9, 2016 2:21 AM
  • Thanks for sharing. I have been looking for this fix for sometime.

    For our setup I was missing the outlook.com in the ExchangeAutodiscoverAllowedDomains section.

    Very happy to say that this is working now :)

    Friday, March 3, 2017 10:05 AM