Monitoring Benefit
Collaboration is the deepest of the Outlook probe tests. Where Autodiscover, MAPI/HTTP and Outlook Anywhere confirm that a client can connect, Collaboration confirms that a user can actually work — sign in, send mail, look someone up in the directory, book a meeting, and see free/busy information.
It is the closest thing in the product to a synthetic user, and it catches the class of problem where everything is reachable and nothing works properly.
This test runs from a remote probe only. Unlike the other Outlook tests, there is no ENow web server equivalent, so there is no server-side result to compare a probe failure against. That changes how you troubleshoot it — see below.
What it exercises
The suite performs a sequence of real operations against the configured test mailbox, covering:
- Sign-in — authenticating and reaching the mailbox at all
- Sending mail, including messages with attachments, and confirming delivery
- Directory lookup — resolving a user in the directory
- Calendar operations — creating and removing an appointment
- Free/busy lookup — retrieving availability for the test account
Each step is timed as well as pass/fail, so the test reports latency for the operations that matter to a user, not just for a connection handshake.
Where the settings are
Probe test accounts are configured under Server > Tuning Policy > Settings > Probe Configuration > Configure Probes….
Latency thresholds are set under Server > Monitoring Policy > Thresholds, in the Remote Probes section, with separate values for the login, send, property retrieval and free/busy lookup timings.
A note on threshold names. The threshold labels in the Admin Console do not always line up one-for-one with the indicators shown on the monitoring page for this test. If you adjust a threshold and the indicator you expected does not change, that is a known mismatch rather than a configuration mistake on your part — raise it with ENow Support rather than continuing to adjust values.
Where this is shown in the console
This check appears under Exchange Remote Probes > Outlook, which you can open directly:
https://<ENow web server>:20080/MailscapeWeb/Exchange/ExchangeOutlookRemoteProbe.aspx?server=<PROBE>The probe name in the query string carries a suffix — for example LONDON-EXCHANGE rather than LONDON. You can also reach the page by selecting the probe's row under Exchange Remote Probes on the dashboard at /MailscapeWeb/Default.aspx. Because there is no server-side equivalent of this test, the probe pages are the only place its results appear.
How do we verify the monitoring test results?
Because there is no server-side equivalent, verification works differently from the other Outlook probe tests. Instead of comparing probe against server, compare probe against probe, and the failing step against the same operation done by hand.
- Identify which step failed. The suite is sequential and a later step failing while earlier ones pass is highly informative — sign-in working but free/busy failing is a permissions or availability-service problem, not a connectivity one.
- Perform that operation manually as the test mailbox from a machine at the probe's site: send the mail, look up the user, create the appointment, check someone's free/busy.
- Compare against another probe. If a second location passes the same step, the fault is local to the failing site.
- Check the other Outlook probe tests at the same site. If Autodiscover or MAPI/HTTP are also failing there, fix those first — Collaboration depends on the same foundations.
- Confirm the probe is reporting — see Remote Probe - Connectivity Status. A probe that has stopped checking in turns its indicators red and states on the detail page that the agent has not reported in, which distinguishes a probe problem from a Collaboration one.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| Sign-in fails — everything else fails with it | Credentials or authentication. Check the test account in Configure Probes…, and whether Conditional Access is blocking the probe's location — see Conditional Access and ENow: Why Device-Based Policies Block Monitoring and, for the addresses to trust, Network Requirements: Ports, Endpoints and Proxy Configuration. |
| Sign-in passes, send fails | Check the test mailbox is not over quota, restricted from sending, or caught by a transport rule. Confirm the recipient the test sends to still exists. |
| Send passes, delivery confirmation fails | Mail is leaving but not arriving in the expected time. Look at mail flow and any journaling or inspection introducing delay, rather than at the probe. |
| Directory lookup fails | The test account cannot resolve the target in the directory. Check address list scoping and any address book policy applied to the account. |
| Free/busy fails, everything else passes | Availability service rather than mailbox access. In hybrid environments this is often the organisation relationship or the sharing configuration between on-premises and cloud. |
| Everything passes but latency is high | Compare against another probe. Consistent slowness at one site is that site's path; slowness everywhere points at Exchange or the availability service. |
| The test sends more mail than expected | The suite sends several messages per run by design. If volume is a concern in your environment, discuss the run interval with ENow Support rather than disabling the test. |
Comments
0 comments
Article is closed for comments.