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.

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."

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."

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

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

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.

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.

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 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 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.

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.

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."

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."

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.

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.

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."

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

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