locked
Autodiscover Failure in ExRCA Test RRS feed

  • Question

  • Hey everyone - when I run the ExRCA Autodiscover test, it fails and I get the following details:

    ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml for user user@contoso.com.
     	ExRCA failed to obtain an Autodiscover XML response.
     	
    	Additional Details
     	Exception details:
    Message: The underlying connection was closed: An unexpected error occurred on a receive.
    Type: System.Net.WebException
    Stack trace:
    at System.Net.HttpWebRequest.GetResponse()
    at Microsoft.Exchange.Tools.ExRca.Tests.AutoDiscover.AutoDiscoverGetXMLBase`2.Discover()
    Exception details:
    Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
    Type: System.IO.IOException
    Stack trace:
    at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
    at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
    at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
    at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
    at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
    at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)
    at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
    at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
    Exception details:
    Message: An existing connection was forcibly closed by the remote host
    Type: System.Net.Sockets.SocketException
    Stack trace:
    at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

    Also - when I browse to https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml, I get a login prompt and then get the following output:

    This XML file does not appear to have any style information associated with it. The document tree is shown below.
          <Autodiscover><Response><Error Time="10:35:39.4459810" Id="3474788706"><ErrorCode>600</ErrorCode><Message>Invalid Request</Message><DebugData/></Error></Response></Autodiscover>

    Any ideas? Thanks!

    Background if that helps - this is an Exchange environment with 2 MBX, 2 CAS/HUB, 2 EDGE, and everything routed through an F5 LTM with APM module.

    • Edited by Der Hai Wednesday, August 15, 2012 2:40 PM
    Wednesday, August 15, 2012 2:36 PM

All replies

  • ExRCA is failing.  It could be a bug in ExRCA, but I think a more likely scenario is that your CAS is improperly published to the Internet and/or something like a web publishing device is corrupting the content.

    You didn't state whether you were running your browser test from inside or outside your network, but it is normal to get a 600 response to that--in fact a 600 is considered a success for that particular test, although it tells you nothing about exactly what Autodiscover is going to return.  I haven't seen it exactly the way you posted it, but more like:

    <?xml version="1.0" encoding="UTF-8"?>
    -<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> -<Response> -<Error Id="4057784753" Time="16:30:50.2193949"> <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> <DebugData/> </Error> </Response> </Autodiscover>


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, August 15, 2012 11:32 PM
  • As mentioned that is a valid response since you're not posting a valid request. As far as forcibly closed by the remote host, I'm assuming this happens every single time you run the test? Are you using any reverse proxy? You need to know which device is issuing a tcp reset it may not even be making it to your CAS, see if you can get help from your network team to capture a trace.

    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

    Thursday, August 16, 2012 12:41 AM
  • As mentioned that is a valid response since you're not posting a valid request. As far as forcibly closed by the remote host, I'm assuming this happens every single time you run the test? Are you using any reverse proxy? You need to know which device is issuing a tcp reset it may not even be making it to your CAS, see if you can get help from your network team to capture a trace.

    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

    Yes, I'm getting the same results every time I run the test. I also tried the browser test externally, and it timed out once (connection reset error in FF) after it asked for credentials - then I just refreshed the page and it displayed the same XML file as above.

    For reverse proxy, we are using a F5 LTM which as far as I know (based on F5 support, and config guides) is configured properly. At this point, Autodiscover "works", but it appears to be inconsistent - i.e. external Outlook clients are not staying connected all the time, and when they try to connect it takes a while to get a connection to Exchange. It doesn't appear to be affecting all external users though, so the whole thing is very strange.

    Thursday, August 16, 2012 2:10 PM
  • Hi Der

    My understanding of the issue is:
    - ExRCA is failing for the accounts.

    Eager to know:
    - if you can access the OOF, Free-busy from the remote location using Outlook?

    >> Remote users are unable to connect to the mailbox?
    What is the protocol which you are trying to connect? Tcp\Ip or Https?
    Reason: Autodiscover will play a role while creating a new Outlook profile...then to access the OOF,Free-busy only.
    Autodiscover shouldn't interfer in the normal https or tcp\ip communications.

    Other Testing:
    1. Can you configure Outlook-Anywhere from any LAN machine, pointing the URL to the CAS-server directly
    Is that working fine?
    Check if the OOF,Free-busy are working from this LAN-Machine

    Cheers
    Aravind

    Tuesday, August 21, 2012 7:06 AM
  • Hi Der

    My understanding of the issue is:
    - ExRCA is failing for the accounts.

    Eager to know:
    - if you can access the OOF, Free-busy from the remote location using Outlook?

    >> Remote users are unable to connect to the mailbox?
    What is the protocol which you are trying to connect? Tcp\Ip or Https?
    Reason: Autodiscover will play a role while creating a new Outlook profile...then to access the OOF,Free-busy only.
    Autodiscover shouldn't interfer in the normal https or tcp\ip communications.

    Other Testing:
    1. Can you configure Outlook-Anywhere from any LAN machine, pointing the URL to the CAS-server directly
    Is that working fine?
    Check if the OOF,Free-busy are working from this LAN-Machine

    Cheers
    Aravind

    Hi Aravind,

    Users on our LAN network are working great - no issues I've seen so far (and I can configure them all day long with zero problems). The only intermittent issues I'm experiencing are people on external networks. We are mostly seeing sporadic disconnections of Outlook clients from Exchange while users are on non-local networks. The disconnections are not affecting everyone, but there are still a good chunk of users having issues. OOF and calendar functionality is working fine when users can stay connected to the server.

    For connections, the Outlook clients are configured with https://exchange.contoso.com proxy settings (More Settings --> Connection --> Outlook Anywhere --> Exchange Proxy Settings) and then the check box "On slow networks, connect using HTTP first, then connect using TCP/IP".

    Just in case this helps, a little background: we were previously front-ending all Exchange services with TMG. Two weeks ago we switched to F5 LTM/APM equipment to accomplish this goal along with implementing a dual stack IPv4/IPv6 network. Ever since the change from TMG to F5, we've been having these intermittent connection issues.

    Tuesday, August 21, 2012 7:47 PM
  • It seems that you know the answer, then.  It appears that you don't have the F5 properly configured, or it doesn't perform the task properly.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, August 21, 2012 8:26 PM
  • It seems that you know the answer, then.  It appears that you don't have the F5 properly configured, or it doesn't perform the task properly.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."


    Ed - just trying to cover all avenues here. I wasn't sure if there was a TMG specific Exchange setting that I may have missed during the conversion that needed to be changed that could be effecting things in this manner.
    Tuesday, August 21, 2012 8:58 PM
  • There is nothing configured in Exchange Server that is specific to TMG.  Sometimes you'll need to create a separate OWA virtual directory if you want to enable forms authentication internally and use the TMG's forms authentication, but that applies only to OWA and ECP, and it would impact every session and wouldn't show up as an intermittent.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."


    Tuesday, August 21, 2012 10:38 PM
  • Hi

    In My Opinion, Can we enable and view the logs @ the F5 device during the time of the issue.

    The requests should reach the devices and then failing @ Outlook end.

    so as long as there is no DNS issue, we need to still suspect & work @ the F5 configuration.

    (May be some rule consider these Outlook requests as harmful and blocking them??)

    Cheers

    Aravind

    Tuesday, September 4, 2012 1:15 AM