Monitoring Benefit
The Namespace CAS Health — Connection Status check tests client access protocol connectivity against a configured Exchange namespace rather than against an individual server. That is the point of it: a namespace is what your clients actually connect to, so a namespace that fails while every individual server reports healthy is a load balancer, DNS or certificate problem rather than an Exchange one.
The protocols covered are ActiveSync, Autodiscover, Exchange Web Services, MAPI, Outlook Anywhere, Exchange Control Panel and Outlook Web App. Each is tested and reported separately, so the failing protocol narrows the cause considerably.
How do we verify the monitoring test results?
1. Read what ENow recorded. From EMS 8.0 onward, collected results are held in the ENow SQL database rather than in files on the web server. Open the Namespace monitoring page in the ENow console, select the namespace, and review the per-protocol status and the error text recorded against the failing one.
2. Test the same namespace independently. The Microsoft Remote Connectivity Analyzer tests the same protocols from outside your network, which is the closest match to what a real client experiences:
Microsoft Remote Connectivity Analyzer
Run the test matching the failing protocol, against the same namespace and using the configured test mailbox. Then run it again with a second mailbox known to be working, so you can tell a namespace problem from an account problem.
3. Compare the two. This is where the answer usually is:
- Both fail with a similar error — the namespace or the endpoint behind it is genuinely unhealthy. Work from the error text.
- ENow fails, the Analyzer succeeds — the problem is specific to the ENow web server's path to that namespace. Check the monitoring service account's rights, and whether the namespace resolves differently from the web server than from outside (split-brain DNS, an internal load balancer, or a TLS inspection appliance presenting its own certificate).
- ENow succeeds, clients complain — check whether the namespace ENow is configured to test is the one clients actually use.
4. Check the certificate on the namespace. A namespace-wide failure across several protocols at once is very often a certificate that has expired, or one whose subject or SAN no longer covers the namespace.
Common warning or error results, and potential solutions
| Result | Potential solution |
| One protocol failing, the rest healthy | The fault is in that protocol's virtual directory or its path through the load balancer, not in the namespace as a whole. Check the virtual directory configuration and authentication settings for that protocol. |
| Every protocol on the namespace failing at once | Look at what is shared: DNS resolution, the load balancer VIP, or the certificate. An individual protocol misconfiguration cannot take all of them down together. |
| Intermittent failures on some cycles only | Frequently one unhealthy node behind a load balancer. The check succeeds or fails depending on which node it lands on. Test each node directly to find the odd one out. |
| Fails after a certificate renewal | Confirm the new certificate is bound to the correct IIS site and services on every node behind the namespace, not only the one it was installed on. |
| Results are stale rather than failing | If several unrelated checks stopped updating at the same moment, look at the ENow SQL database connection rather than at the namespace. |
Comments
0 comments
Article is closed for comments.