Exchange 2010 Monitors for LTM

For OWA, Exchange seems to require a User-Agent string (along with the GET and Host headers). For an OWA monitor, try this string:

 

 

GET /owa/auth/logon.aspx?url=http://host.domain.com/owa/&reason=0 HTTP/1.1\r\nUser-Agent: Mozilla/4.0\r\nHost: host.domain.com\r\n\r\n

 

 

And look for something like

 

 

OwaPage

 

 

(which is a string in the returned HTML page, on the 3rd line, in a comment that is, in full: )

 

 

You can use a more complete User-Agent string, for instance the one your browser actually sends, but I'm not sure that nets you anything and is just more data to send.

 

 

Keep in mind that the FQDN in both the GET request and the Host header must match each other and must be the FQDN that you've set up for access through the BIG-IP virtual server; if you use the local name of a host, it will fail for a differently-named host in the same pool.

 

 

You could also look for a header, for instance:

 

 

X-OWA-Version: 14.1.218.13

 

 

That's the version returned by 2010 SP1; your version may be slightly different. You don't even need the version and can just look for the header, which will be safer in case the version changes with future updates. In short, you can be as specific as you want here.

 

 

In terms of logins, I would not suggest taking that approach. Yes, you test the full Client Access + Authentication + Mailbox Server path, but the dangers of a false positive are pretty high. It could be that one specific mailbox (the one you're checking) is disabled, moving, etc. or een the password for the account has inadvertently expired or been locked because of too many bad attempts from a mis-typed monitor string or something. If the login fails, it would then disable that entire Client Access server, when it may in fact be capable of serving requests for other users/mailboxes. And actually, I'm not even sure that a login approach is viable if you're using the default forms-based authentication; if you switch over to non-forms and also turn enable Basic, you could use the authenticated approach, but the same dangers as above still hold true.

 

 

The send/receive for each of the other services are different. I can cover those is more detail in a future post. Note also that a new version of the Guide with more advanced monitors will be out in the not-too-distant future.

 

 

 

Dayne,

 

 

Thanks for the response.

 

 

You say: "Keep in mind that the FQDN in both the GET request and the Host header must match each other and must be the FQDN that you've set up for access through the BIG-IP virtual server; if you use the local name of a host, it will fail for a differently-named host in the same pool."

 

 

I'm not sure I understand that 100%.

 

 

Really what I want to do is effectively monitor and load balance across 3 physical servers. As I mentioned, for whatever reason the default website is going unavailable (haven't tracked down the cause of this) but the other virtual directories are staying up. The monitor is only looking at the default website and when it fails it's taking down all of the pools (note: an IIS reset isn't fixing the default website, only a restart is).

 

 

I'm not a guru with this thing, I'm doing my best to pickup and understand what I can about it but it's really not functioning how I expect it to in terms of the monitors. I really just need some simple but effective monitors or a means of monitoring each of these virtual directories. =)

What I meant by that statement is that you can't use a local hostname, but have to use the external FQDN, for the monitor string.

 

 

Let's say you have 3 CA servers: ca0.domain.com (10.0.0.10), ca1.domain.com (10.0.0.11) and ca2.domain.com 10.0.0.12). You correctly configure the external URL for OWA to be something like https://owa.domain.com/owa, and correctly set up SSL offloading: removing the requirement for SSL on the appropriate IIS directories and creating the correct Registry entry on each server. You leave the internal URL untouched on each (so https://ca0.domain.com/owa, https://ca1.domain.com/owa, and https://ca2.domain.com/owa, respectively).

 

 

If you ssh to the BIG-IP, you can start to test connect strings. Pick host ca0 and do the following (where represents hitting Enter, and for everything after the first telnet, will translate to \r\n in the monitor string).

 

 

telnet 10.0.0.10 80

 

GET /owa/auth/logon.aspx?url=http://ca0.domain.com/owa/&reason=0 HTTP/1.1

 

User-Agent: Mozilla/4.0

 

Host: ca0.domain.com

 

 

That will work just fine for ca0, but will fail for ca1 and ca2, so it's the wrong way to go. You must use the external FQDN (owa.domain.com in this case) in place of any of the local FQDNs (ca0.domain.com, etc.), like so:

 

 

telnet 10.0.0.10 80

 

GET /owa/auth/logon.aspx?url=http://owa.domain.com/owa/&reason=0 HTTP/1.1

 

User-Agent: Mozilla/4.0

 

Host: owa.domain.com

 

 

Which when translated to the BIG-IP monitor GUI input field would be:

 

 

GET /owa/auth/logon.aspx?url=http://host.domain.com/owa/&reason=0 HTTP/1.1\r\nUser-Agent: Mozilla/4.0\r\nHost: owa.domain.com\r\n\r\n

Dayne,

 

I appreciate your insight. I tossed in that monitor and initially it looked good but then the pool failed. It's my plan to get everything functioning to begin with and then I'll go back later and tweak the monitors to actually be useful..

 

 

Are you currently monitoring each one of your virtual directories with different monitors or how does your config look? I'd appreciate anything you want to share.

 

 

-Ken

To clarify here, I've followed the deployment guide for Exchange 2010 and the monitors for OWA, OA, AS, etc. don't work. Is it because I haven't switched the SSL offloading off of the Exchange servers that it won't work? I have the name of the CAS array in the GET statements as of now.

 

 

thanks,

 

 

--John