Microsoft Teams - VIP Monitoring Status

Monitoring Benefit

VIP Monitoring tracks Microsoft Teams call quality for a named set of users — typically executives — and alerts when one of them accumulates poor calls. It exists because the native Microsoft view makes it hard to answer the question an IT team actually gets asked: why were my calls bad this week?

The specific problem it solves is that Microsoft classifies a meeting as poor if any participant had a bad experience. So an executive's dashboard can show a run of poor meetings when their own audio was fine throughout. VIP Monitoring separates the calls where the VIP user personally had a poor experience from meetings that were rated poor because of somebody else.

Where it appears

VIP Monitoring sits under the Microsoft Teams indicator on the main dashboard, alongside Teams Chat and Simplified Teams CQD.

It is hidden from the default and NOC views. Visibility is controlled by a Show VIP Teams Monitoring option in the dashboard manager, and by the Teams Engineer dashboard role. If the indicator is missing for a user who expects it, that is the first thing to check — it is a permissions and view setting, not a fault.

Which users are monitored

Membership is driven by a Microsoft Entra ID (Azure AD) group rather than by a list maintained inside ENow — by default a group named ENow VIP Teams Monitoring. Add a user to the group and they appear; remove them and they drop off.

The view is designed to fit on one screen without scrolling, so it is intended for roughly 15–25 users. It is not a whole-organisation report — the Simplified Teams CQD checks cover the tenant as a whole.

What drives the indicator

Each VIP user is reported with two separate counts of poor calls, and the indicator is driven by both:

Both are threshold-driven. By default a user is flagged as a warning at 8 poor calls and critical at 10, evaluated over a configurable look-back period of between 24 hours and 30 days. Both the thresholds and the look-back window are set in the ENow Admin Console, so confirm the values in force in your own environment.

The look-back window matters as much as the threshold. Eight poor calls in 24 hours and eight across 30 days describe very different experiences, so set the window to match how quickly you want to hear about a problem.

The two counts disagreeing is information, not a fault. A user with few Microsoft-reported poor calls but many self-reported ones is having an experience the telemetry is not capturing — often audio device or room acoustics rather than network. The reverse, poor telemetry but no complaints, usually means the user has adapted to it.

Drilling into a user

Selecting a VIP user opens their call detail, which breaks the poor calls down by:

• Poor direct calls versus poor meetings and conferences
• Reason — for example network versus other causes
• Connection type — wireless versus wired
• Who the calls were between, which surfaces a consistently bad pairing
• Device type

Individual calls and meetings are then listed with their ID, start time, participants, duration, client, connection type, audio quality, poor call quality reason and Rate My Call score, over a selectable period.

This breakdown is the point of the feature. A user whose poor calls are 75% wireless has a different problem from one whose poor calls are 75% with the same colleague.

How do we verify the monitoring test results?

• Compare against the Teams admin center. The Microsoft-reported figure comes from Microsoft's own data, so it should broadly agree with what the Teams admin center shows for the same user over the same period.
• Check the group membership. Confirm the user is in the Entra ID group backing this feature. A user who is absent from the table is usually absent from the group.
• Allow for Microsoft's reporting delay. Call quality data is not real time. A call made in the last few hours may not have reached the dashboard yet, so a discrepancy on recent activity is expected rather than a fault.

Common warning or error results, and potential solutions

When no data appears

The VIP and poor-quality views share their collection pipeline, so they usually fail together. Check in this order:

1. Service account permissions. Confirm the monitoring account can still read call quality data from the tenant, and that it is not being blocked by Conditional Access. See How to Configure Service Accounts to Bypass MFA and Conditional Access Policies.
2. Service logs on the ENow web server. EnowMicrosoft365Service.log for the collection itself, and ENowCloudReportService.log for the report build. An absence of Teams entries in the first is as meaningful as an error in it.
3. The report cache. Teams poor-communication data is built into the UI cache. If the cache has been left holding a partial or failed build, clearing the relevant cached files lets it rebuild on the next cycle.
4. Application pool permissions. Confirm the MailscapeAppPool identity still has access to the ENow data folder on the web server.
5. SQL errors. Check the ENow SQL service error log. A report that fails part way through leaves the dashboard empty rather than showing an error, so a failure here looks like "no data" from the front end.

If those are clean and the dashboard is still empty, contact ENow Support with the service logs and the SQL error log from the same period.