Forum Discussion

Robert_Luechte2's avatar
Robert_Luechte2
Icon for Cirrus rankCirrus
Jun 30, 2016

Exchange 2010 monitors

I'm configuring my LTM for Exchange 2010. I'm not using the iApp to do it. Yes, I know, it would be easier/better/faster, but I'm not.

 

Going through the manual configuration pages, for the monitors it says to use the healthcheck.htm page. But according to my Exchange administrator, that page doesn't exist for 2010, only for 2013. And based on my searching the Internet, I'm inclined to agree with her. Everywhere I see that mentioned, I see 2013 referenced.

 

Does anyone know what the guide suggested to use for a monitor string prior to Exchange 2013?

 

application delivery
exchange 2010
LTM

1 Reply

Sort By
  • Chase_Abbott's avatar
    Chase_Abbott
    Icon for Employee rankEmployee
    Jun 30, 2016

    I would suggest keeping it simple since most times CAS fails, it's either going to be a basic services issues or something so granular, most monitors wouldn't pick it up unless they're quite invasive. Here's what I used to run:

     

    1. Basic HTTP(s) monitor to determine the absolute URL of the web virtual directory get request was returning a http/* 200 OK. Check out SOL2167 for help with constructing HTTP monitors. This monitor caught probably 75% of any issues related to CAS.
    2. Other services like transport I just ran dedicated receive connectors that listened only to the BIG-IP for SMTP checks. If I receive a 220 ESTPM header, the monitor was good (Make sure you QUIT the connection). Not everyone has an SMTP virtual for their Exchange, instead running edge or other appliances for SMTP incoming... but having BIG-IP handle the SMTP from those systems allowed me to check those services too and fail over to other sites in case of total CAS/Transport meltdown.
    3. If you run POP/IMAP you can build specific port monitors for those services and if you want build a script to fully log into the mailbox for testing. This is a little excessive but it's doable.
    4. The most expansive monitor was generated by running several health checks on Exchange and dumping the output to an HTML file which I than read from another regex-based HTTP monitor. This allowed me to look for anything an exchange health test could output. If the file had any errors or NULL results, the HTTP regex could parse the error and failover the connection for that server. For Regex monitors, check out SOL5917. These types of monitors are beneficial because not only could I output the results of any powershell to HTML, I could have additional scripts alert (email or pager) while BIG-IP was in process of failing over. This ended up being a faster warning system than our managed management agents.

    It'll be up to you to decide how granular and what services you'll need to monitor but for the most part, the SMTP and HTTP checks on the various web virtual directories (HTTP/1.0 200 OK) was plenty for me. Anything beyond that was so esoteric, even Exchange health agents couldn't figure out why a transport queue was backing up. I had a script for that too.