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.