Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Exchange ActiveSync Monitor fails with read:errno=104

We have Exchange 2013 running on our F5s. It was built using the iApp and has been working good. They recently discovered that ActiveSync in Exchange 2013 is wide open to everyone so an IP filter list was applied that allows the F5 subnet. Now 2 of our 4 CAS servers are marked down even though they have identical settings, have had IIS restarted, and the servers themselves have been restarted as well. I am doing the following test from F5 command line:

openssl s_client -connect {server_name}:443
GET /Microsoft-Server-Activesync/healthcheck.htm HTTP/1.1 {ENTER}
Host: host.domain.edu {ENTER}
Connection: Close {ENTER}
{ENTER}

The 2 CAS servers that are marked up respond with: 200 OK. The 2 CAS servers that are down respond with: read:errno=104

Does anyone have any insight as to what might cause the read:errno=104 response?

Thanks! Rob

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

That error 104 is basically given back when the remote end closes the connection on you... You'll get back something similar if you use curl as well (Using curl saves typing all those headers, but you can get more control with openssl utility).

I take it the openssl connection is made and you get a valid SSL session established before you move to entering the "GET... " request and headers. That would indicate that the server is running and listening, accepting the connection and negotiating the SSL, but is unwilling or unable to respond (And unable to simply return a 500 error either. It's just closing the connection without actually responding).

Try & get a view of the logs at the CAS server... There should be info in there as to what's happening...

H

0
Comments on this Answer
Comment made 17-Jan-2014 by Rob 133
Thanks Hamish! The SSL does get established first. We're troubleshooting the CAS side as well and opened a case with Microsoft. Understanding what that means is very helpful.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Just in case anyone stumbles across this, we have it fixed now. Exchange 2013 has its own health monitor and the local loopback addresses (127.0.0.1 and ::1) need to be in the IP filter list for the ActiveSync pool. If not, Exchange won't be able to poll it and mark the pool down and then the F5 monitor goes down as well. Hamish was right on the money with the meaning of error 104 (log from Exchange):

Fields: date time c-ip c-port s-ip s-port cs-version cs-method cs-uri sc-status s-siteid s-reason s-queuename

2014-01-22 17:58:03 192.168.1.2 43567 192.168.1.22 443 HTTP/1.1 GET /Microsoft-Server-Activesync/healthcheck.htm - 1 Connection_Dropped MSExchangeSyncAppPool

2014-01-22 17:58:03 192.168.1.2 43587 192.168.1.22 443 HTTP/1.1 GET /Microsoft-Server-Activesync/healthcheck.htm - 1 Connection_Dropped MSExchangeSyncAppPool

2014-01-22 17:58:03 192.168.1.3 48812 192.168.1.22 443 HTTP/1.1 GET /Microsoft-Server-Activesync/healthcheck.htm - 1 Connection_Dropped MSExchangeSyncAppPool

0