locked
Test-CsExStorageConnectivity Results in Error: "The Request Failed With An Empty Response" RRS feed

  • Question

  • I am attempting to integrate a Skype for Business Server 2015 with an Exchange Server 2016.  I have been successful in creating the partner applications on both servers.  However, when I attempt to test the setup, it fails with the error below:

    Here's the command I issued on the SfB Server:

    Test-CsExStorageConnectivity -SipUri "sip:First.Lastname@mydomain.com" -Verbose

    Which results in the following error (truncated):

    Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=574,
    reason=#CTX#{ctx:{traceId:192143289, activityId:"fa709643-3903-49a3-af3e-c8dcff288259"}}
    #CTX#StoreException: code=ErrorUnhandledException, reason=Wrapped callback failed --->
    System.InvalidOperationException: Client found response content type of '', but expected
    'text/xml'.

    The request failed with an empty response.

    Looks like another user experienced a similar issue on this thread, but his resolution had to do with a Load Balancer - which I'm not using.  Has anyone run into this problem before and if so, how did you resolve it?


    • Edited by Kismet-Gerald Friday, August 24, 2018 5:26 PM Minor typo correction
    Friday, August 24, 2018 4:44 PM

Answers

  • Never mind folks. 

    I managed to resolve my issue by resetting the EWS Virtual Directory from the Exchange Control Panel. 

    You see, the whole time I'd been getting the test failure, I was able to browse manually to the EWS at https://EXCH_FQDN/ews/exchange.asmx from the SKYPE server; it just prompted me for credentials.  So I figured there was something wrong with the authentication setup on the EWS and since the test cmdlet didn't ask for credentials, it was likely failing somehow.  I tinkered with various combinations of the authentication settings manually, but none seemed to work.  So I finally decided to just reset them to default.

    This seems to have cleared out whatever the issue was and I was able to run the test cmdlet successfully.

    • Marked as answer by Kismet-Gerald Thursday, August 30, 2018 9:13 PM
    Thursday, August 30, 2018 9:13 PM

All replies

  • Hi Kismet-Gerald

    Did you take a look at this? 

    https://www.ucchub.co.uk/test-csexstorageconnectivity-failure-with-error-code574/

    Friday, August 24, 2018 5:18 PM
  • Hi Kismet-Gerald

    Did you take a look at this? 

    https://www.ucchub.co.uk/test-csexstorageconnectivity-failure-with-error-code574/


    Yes sir, I have.  The solution there deals with a Kemp Load Balancer - which I'm not using in my case.  While there are two Domain Controllers w/DNS roles on both servers running in my environment, I don't have any load balancing going on.  Using NSLookup, I have confirmed that the autodiscover record is present on both DNS servers.
    Friday, August 24, 2018 5:44 PM
  • Hi Kismet-Gerald

    Did you take a look at this? 

    https://www.ucchub.co.uk/test-csexstorageconnectivity-failure-with-error-code574/


    Yes sir, I have.  The solution there deals with a Kemp Load Balancer - which I'm not using in my case.  While there are two Domain Controllers w/DNS roles on both servers running in my environment, I don't have any load balancing going on.  Using NSLookup, I have confirmed that the autodiscover record is present on both DNS servers.

    I found this thread: https://social.technet.microsoft.com/Forums/windows/en-US/a172f43c-e3e0-40de-ad02-3d9f05ab88f0/unified-contact-store-ucs-integration-issue-event-source-ls-storage-service-event-id-32043?forum=lyncinterop

    I had a similar problem when we had to integrate OWA (Exchange Online) with on-premises skype.

    Is there any entry Lync Event Viewer log when you run the cmdlet?

    Friday, August 24, 2018 6:00 PM
  • Thanks for that link Fernando, however, I've already reviewed that one as well prior to coming here.  The problem here was DNS related - which I don't think is what I'm experiencing.

    To answer your question, yes I do see Event ID 32008 logged on the SfB server - the details of which are below.  However, I do believe this is just the same error I was getting in the console:

    Unexpected exception.
    
    Message=Callback wrapped by StoreAsyncResult failed
    Exception: Client found response content type of '', but expected 'text/xml'.
    The request failed with an empty response.
    Stack Trace:  at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
     at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(lAsyncResult asyncResult)
     at Microsoft.Rtc.Internal.Storage.Exchange.Ews.ExchangeServiceBinding.EndInvoke(lAsyncResult asyncResult)
     at Microsoft.Rtc.Internal.Storage.Exchange.Ews.ExchangeServiceBinding.EndCreateItem(lAsyncResult asyncResult)
     at Microsoft.Rtc.Internal.Storage.Adaptor.ExStoreAdaptor.OnCreateItemComplete(lAsnycResult result)
     at Microsoft.Rtc.Internal.Storage.StoreAsnycResult`1.CallbackWrapper(lAsyncResult result)
    Cause: Unexpected exception.
    Resolution:
    If problem persists, notify your organization's support team with the event detail.

    Friday, August 24, 2018 7:36 PM
  • my last attempt

    https://social.technet.microsoft.com/Forums/lync/en-US/63c75243-ec09-40a4-bcc8-e48886719fe8/lync-2013-and-exchange-2013-ucs-integration-error-soap-version-mismatch?forum=lyncinterop

    Best regards!

    Friday, August 24, 2018 8:46 PM
  • my last attempt

    https://social.technet.microsoft.com/Forums/lync/en-US/63c75243-ec09-40a4-bcc8-e48886719fe8/lync-2013-and-exchange-2013-ucs-integration-error-soap-version-mismatch?forum=lyncinterop

    Best regards!


    I really appreciate the effort thus far, but this didn't resolve my issue either.  Thanks anyway for trying to assist - hopefully somebody else comes along that has experienced the problem before.  I plan on bringing both servers up-to-date with their respective CUs then I will check again if the problem persists.
    Monday, August 27, 2018 12:18 PM
  • Hi Kismet,

    one thing more. Did you run Get-SettingOverride cmdlet on your exchange server? The output show some settings about certificates and so on. Perhaps it can helps  you to find the issue.

    Best regards!

    Tuesday, August 28, 2018 9:30 AM
  • Hi Kismet,

    one thing more. Did you run Get-SettingOverride cmdlet on your exchange server? The output show some settings about certificates and so on. Perhaps it can helps  you to find the issue.

    Best regards!

    Thanks again Fernando.  The Get-SettingOverride cmdlet returned zero results, so it is my assumption that no settings have been overwritten and saved to AD for that matter.  I'll keep chugging along until I find a solution.  I may end up just blowing the Exchange Server away and re-installing.  It's a production server, so I really don't wanna do that..... but we'll see.

    Thanks again.

    Tuesday, August 28, 2018 7:38 PM
  • Hi,

    If you access https://autodiscover.domain.com/autodiscover/autodiscover.svc URL, could you get the correct xml file page?

    In addition, is the user’s sipaddress same as the SMTP address?

    Could you try to create another user account?

    Wednesday, August 29, 2018 10:02 AM
  • Never mind folks. 

    I managed to resolve my issue by resetting the EWS Virtual Directory from the Exchange Control Panel. 

    You see, the whole time I'd been getting the test failure, I was able to browse manually to the EWS at https://EXCH_FQDN/ews/exchange.asmx from the SKYPE server; it just prompted me for credentials.  So I figured there was something wrong with the authentication setup on the EWS and since the test cmdlet didn't ask for credentials, it was likely failing somehow.  I tinkered with various combinations of the authentication settings manually, but none seemed to work.  So I finally decided to just reset them to default.

    This seems to have cleared out whatever the issue was and I was able to run the test cmdlet successfully.

    • Marked as answer by Kismet-Gerald Thursday, August 30, 2018 9:13 PM
    Thursday, August 30, 2018 9:13 PM
  • Hi Kismet

    I have the same issue

    You said " So I finally decided to just reset them to default."

    What, where and how you reset them to default?

    Is it something you have done on Exchange or SFB Frontend server?

    Saturday, May 4, 2019 12:49 AM
  • The same problem here, I fix resetting the EWS Virtual Directory from the ECP.

    thanks.


    Thursday, June 6, 2019 7:49 PM