This article is part 2 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.
Load Balancing
Unlike previous versions of Exchan...
Updated Jul 01, 2019
Version 2.0
Blog Post
Hi Ross, thanks for the useful info. I have a question about monitoring /healthcheck.htm. For example, in my testing, I can disable the Information Store and other services to the point that the EWS HealthSet has an AlertValue of Unhealthy.
However, after more than 30 minutes in that state, the EWS.proxy ServerComponentState never transitions to Inactive or even Unhealthy and a 200 status is always returned. This is true of all the services we monitor using /healthcheck.htm via BIG-IP. When that is the only monitor we use, it results in nodes being marked healthy incorrectly and mailbox open errors on clients.
We can work around this by applying a supplemental EAV monitor that logs into the mailbox, marking the node down if either it or /healthcheck.htm fails.
Can you advise if the behavior of Managed Availability w/r/t HealthSet AlertValue/ServerComponentState is expected, or is this a bug? Can MA be configured to improve the responsiveness of ServerComponentState?
If this is expected behavior, it seems like supplemental monitoring should be required for any HLB solution.
Also, here you state, "if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Client Access server". However, if I manually set the ServerComponentState to Inactive, requests to /healthcheck.htm receive *no* response. Could this be a bug? I'm running service pack 1.
thanks
Michael
However, after more than 30 minutes in that state, the EWS.proxy ServerComponentState never transitions to Inactive or even Unhealthy and a 200 status is always returned. This is true of all the services we monitor using /healthcheck.htm via BIG-IP. When that is the only monitor we use, it results in nodes being marked healthy incorrectly and mailbox open errors on clients.
We can work around this by applying a supplemental EAV monitor that logs into the mailbox, marking the node down if either it or /healthcheck.htm fails.
Can you advise if the behavior of Managed Availability w/r/t HealthSet AlertValue/ServerComponentState is expected, or is this a bug? Can MA be configured to improve the responsiveness of ServerComponentState?
If this is expected behavior, it seems like supplemental monitoring should be required for any HLB solution.
Also, here you state, "if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Client Access server". However, if I manually set the ServerComponentState to Inactive, requests to /healthcheck.htm receive *no* response. Could this be a bug? I'm running service pack 1.
thanks
Michael