Issues with Exchange 2013 iApp on 11.4.1

Hi Alex-

Just to make sure--are you running the 1.3.0 version of the iApp?

For your SSL question: What do you mean by "nothing would become available"? Do you mean that there weren't any serverssl profiles to select from the drop-down (meaning that you're not choosing the option to "Create a new Server SSL profile), or that you can't pass traffic when you select a profile that doesn't have the 'No TLSv1.2' option enabled? Or something else? If you provide some more details, we should be able to help.

Based on the fact that your OWA monitor works and your other two don't, I believe you have incorrect authentication credentials. The OWA monitor, even in Advanced mode, doesn't perform an authenticated connection when OWA is configured with Forms-Based Authentication. Instead, it just checks for the availability of the login form. The other two services use authenticated monitors; since they're failing, I suspect the format of the credentials you entered might not be quite right.

The 4 credential questions, and required format, are:

• What email address do you want to use for the advanced monitors?

This is required to format a valid XML POST for Autodiscover. It should be in normal user@mycompany.com format.

• Which mailbox account should be used for monitors?

This is the Windows username. Mine, for instance, might be dmiller (exact format will be specific to your domain, of course). This has to be the username associated with the mailbox email address entered in the previous field.

• What is the password for that mailbox account?

Self-explanatory ;) I believe we accept all extended characters that are valid for Windows passwords; the only exception is that a password can not start with one or more leading blank spaces.

• What is the domain name of the user account for the monitors?

This is the question most often answered incorrectly. The domain is the short (NetBIOS) version of the Windows domain (example: MYDOMAIN) or the FQDN (example: mydomain.com). In neither case should you have a trailing backslash or any other character.

Please try adjusting the credentials; make sure you're using an account that hasn't been locked!

Hey Dayne,

iApp Version is f5.microsoft_exchange_2010_2013_cas.v1.3.0

The SSL Problem: When I remove the "No TLSv1.2" no services will be available, not even owa. The BIGIP Logon Form will be displayed but after logging on the connection will be reset. After activitating the option and reloading the page owa will work as expected.

The ActiveSync and Autodiscover monitor problem: I have verified that email address, user account name, password and fqdn of cas server are correct. (see picture).

Is there a way to verify the monitors manually (e.g. by curl), so I can obtain an error message?

Kind regards, Alexander

When I execute the following curl command I receive the below answer. To me the answer looks good as it contains a "200 OK" as expected by the monitor (see picture below). Why does the monitor not become green?

    [admjk@F5BIGIP03:Active:Standalone] tmp  curl -k  https://172.17.27.192 -d "/Microsoft-Server-Activesync/healthcheck.htm HTTP/1.1\r\nHost: exchange.domain.de\r\nConnection: Close\r\n\r\n" -verbose
* About to connect() to 172.17.27.192 port 443 (0)
*   Trying 172.17.27.192... connected
* Connected to 172.17.27.192 (172.17.27.192) port 443 (0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*        subject: C=DE; CN=exchange.domain.de
*        start date: 2014-05-09 12:43:00 GMT
*        expire date: 2016-05-08 12:43:00 GMT
*        common name: exchange.domain.de (does not match '172.17.27.192')
*        SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> POST / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3 libidn/0.6.5
> Host: 172.17.27.192
> Accept: */*
> Referer: rbose
> Content-Length: 107
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/8.5
< X-Powered-By: ASP.NET
< Date: Fri, 23 May 2014 14:16:14 GMT
< Content-Length: 150
<
* Connection 0 to host 172.17.27.192 left intact
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
 

Surprisingly, the advanced monitor wears a fasionable green:

Configuration generated by iApp:

Why does this one succeed when the other fails?

Oh, similar picture for the advanced owa monitors:

?????

Hi Alex-

Thanks for providing so much information.

Please open a case with F5 Support and send me a private message with the case ID so I can take a closer look at your configuration (or the engineer you talk to may very well be able to help directly, of course).

In the meantime, how did you discover that "No TLSv1.2" is the option that makes your connections work? I'm not aware of a specific IIS or Exchange configuration that would require that; is there a MSFT TechNet, F5 Support, or related article that you referenced to find that? If so can you provide that to us?

What happens if you let the iApp build its own new server SSL profile, rather than selecting one you've customized?

I have a few theories on the monitor situation, though nothing definitive without more information. The fact that your advanced monitors succeed shows that your auth credentials are fine (which is good). The fact that the advanced [EAV, i.e. external] monitors (which use curl) work and the built-in BIG-IP monitors don't, AND you have a seemingly-unusual SSL/TLS config on the server side, makes me think that BIG-IP's internal HTTPS monitor (which does not use curl) is somehow receiving a certificate error or having the connection reset. However, we really don't know at this point.

When you talk to Support, they'll probably ask that you grab a server-side tcpdump capture and decrypt it with your private key so we can see what's going on with the monitor traffic. If the problem is during SSL negotiation, the decryption may not be necessary (or possible); if it's right after negotiation and something that's occurring at the HTTP level, we'll need to see what Exchange/IIS is doing.

Hey Dayne,

well, I suspected that it had something to do with the server ssl profile and so I tried out the options, first enabling all of them after which owa became available. Then I narrowed down the options until the "no tlsv1.2" option was left over.

When I create a server ssl profile, owa and activesync become unavailable, whereas the monitors keep the same colors as with my custom server ssl profile.

So the problem with the monitors keeps the same whether I enable the option or not...

Regards, Alex

Alex,

I just finished troubleshooting this same issue for over a month with F5 support. I didn't really want to accept the answer that you had to disable TLS 1.2 to get it working. I was running 11.3.1 with Exchange 2013 SP1 and while testing an upgrade to 11.4.1 I would lose Outlook Anywhere and Outlook Web Access connectivity to Exchange as soon as I failed over to the standby box running 11.4.1 HF8. When going to the OWA page, I would see Outlook Web Access displayed for a split second with the spinning wheel and then it would redirect to a page could not be found error.

I dug deeper, taking wireshark and ssl traces. I believe the issue is a mismatch between the ciphers that BIG IP 11.4.1 and Exchange 2013 servers use to negotiate. When looking over the supported ciphers in 11.5.1 I noticed there were some additional ones which weren't supported in 11.4.1. I went ahead and upgraded to 11.5.1 and as soon as I failed over everything was working as expected. If you would like my case I'd be happy to send it to you.

You are not alone with v11.4. see:

https://devcentral.f5.com/questions/ssl-handshake-errors

So it is a plus for v11.5.1.

Hi Alexander, I was not able to reproduce this issue against either Windows 2008 R2 or Windows 2012. That makes sense, because the documentation seems to indicate that this is only an issue when the server side does not support TLS 1.2, and both the OS I tested with do support it out of the box.

Which version of Windows Server are you running on your CAS?

thanks

Mike