Forum Discussion
Exchange 2010 monitors
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:
- 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.
- 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.
- 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.
- 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.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com