Troubleshooting Scenario Questions

Teams Meeting policy

Why it fails: Teams Meeting policies control features within the meeting environment, such as recording, screen sharing, and participant capabilities. They do not manage PSTN telephony features or the ability to dial out to external phone numbers, making this policy irrelevant to the user's reported telephone connectivity issue.

Teams App setup policy

Why it fails: App setup policies control which apps are pinned to the user's Teams client sidebar. While the 'Calls' app is often pinned through these policies, it does not control the underlying telephony permissions or the ability to place PSTN calls. It is merely a UI customization setting.

Teams Messaging policy

Why it fails: Messaging policies define what users can do in chat, such as deleting messages, using Giphy, or sending stickers. They have absolutely no influence over voice telephony or dial-out capabilities to the PSTN network. These policies manage text-based communication features exclusively, leaving audio calling functions unaffected.

Call Quality Dashboard (CQD)

Why it fails: CQD is designed for aggregate, historical analysis of call quality across the entire organization. It is used to identify long-term trends and systemic issues rather than providing the granular, per-second data needed to troubleshoot a single, specific meeting that is currently taking place in real-time.

Teams Usage Reports

Why it fails: Usage reports provide high-level data on how many people are using Teams, which features are popular, and general adoption metrics. They do not contain technical telemetry data such as jitter, packet loss, or round-trip time, making them unsuitable for technical troubleshooting of audio or video quality.

The Microsoft 365 Health Dashboard

Why it fails: The Health Dashboard provides information about the status of Microsoft services globally, such as regional outages or service degradations. It does not provide data about individual user sessions or specific meetings, as its purpose is to alert admins to broad platform-level issues affecting many tenants.

Audio Jitter

Why it fails: Audio jitter specifically refers to the variance in packet arrival time for voice traffic. While it affects sound quality, it does not directly impact the visual quality or resolution of screen-sharing content, which is handled as a separate data stream within the media stack.

Round Trip Time (RTT)

Why it fails: Round Trip Time measures the latency between endpoints. While high latency can cause a delay in screen updates, it does not explain blurriness, which is typically caused by insufficient bitrate or frame rate drops due to network congestion or poor bandwidth availability.

Signaling latency

Why it fails: Signaling latency relates to the time taken to establish a connection or send chat messages. It does not influence the quality of the media stream once the call is established and is therefore irrelevant to troubleshooting blurry video or screen sharing quality issues.

Messaging policy

Why it fails: Messaging policies control features within chat, such as the ability to delete messages, use Giphys, or translate messages. They do not determine whether a user can initiate a chat with an external Teams user. Therefore, this policy would not explain why finance users cannot start external chats while internal chats work.

Teams app permission policy

Why it fails: Teams app permission policies control which apps are available to users within Teams, such as whether they can add tabs or bots. They have no bearing on the ability to chat with external users. The scenario describes a communication restriction, not an app availability issue, so this policy is not the right place to look.

Meeting policy

Why it fails: Meeting policies govern meeting features such as recording, transcription, and who can bypass the lobby. They do not control the ability to start one-on-one or group chats with external users. Since the problem is about chats, not meetings, this policy is irrelevant. Troubleshooting here would waste time and not resolve the external chat issue.

Call Quality Dashboard (CQD)

Why it fails: CQD provides aggregate call quality data across the organization and allows filtering by dimensions like user, location, and network type. However, it does not provide session-level details such as individual media streams, codecs, and network traversal for a single meeting. It is better suited for identifying trends and broad issues rather than deep-diving into one session.

Teams admin center > Users > Manage users > Call history

Why it fails: Call history in the Teams admin center shows a list of calls and meetings for a user, including date, time, and participants, but it does not include technical details about media streams, codecs, or network traversal. It is useful for auditing who called whom, but not for troubleshooting media quality at the stream level.

Microsoft 365 network connectivity test tool

Why it fails: The network connectivity test tool checks network readiness and connectivity to Microsoft 365 endpoints from a specific location. It does not provide per-session media stream details or codec information for a specific meeting. It is used for pre-deployment validation or diagnosing general network issues, not for analyzing a particular meeting's media characteristics.

The policy is corrupted.

Why it fails: Policy corruption is extremely rare in Microsoft 365. When a feature does not function as expected, it is almost always due to a conflict between organization-wide settings and user-assigned policies, or a lack of proper license assignment, rather than an underlying corruption of the policy object itself.

The user is not licensed for guest access.

Why it fails: Guest access does not require a specific license for the user to invite guests; it relies on the tenant-wide configuration and the presence of the Microsoft Entra B2B collaboration feature. Licensing issues typically affect the ability to host meetings, not the ability to add guests.

The AllowPrivateCalling parameter is blocking the guests.

Why it fails: The AllowPrivateCalling parameter controls peer-to-peer calling capabilities, not the ability to invite external participants to scheduled meetings. Guest access is independent of private calling permissions, so this setting would not prevent a user from adding a guest to a scheduled meeting session.

Teams client debug logs

Why it fails: Teams client debug logs capture client-side activity, including media and signaling, but they do not provide the full SIP trace from the SBC perspective. While they can be useful, they are less comprehensive for Direct Routing issues. The SBC logs are more authoritative for SIP-level troubleshooting.

Microsoft 365 network connectivity test tool

Why it fails: The Microsoft 365 network connectivity test tool assesses network readiness and connectivity to Microsoft 365 services. It does not capture SIP traffic or provide call-specific signaling details. It is useful for general network diagnostics but not for troubleshooting individual call drops.

Microsoft Teams admin center Call Analytics

Why it fails: Call Analytics provides detailed information about calls, including quality and signaling, but it does not capture raw SIP traffic. It shows media and signaling metrics but is not a packet capture tool. For deep SIP troubleshooting, you need to capture the actual SIP messages exchanged between Teams and the SBC.

Assign the branch users a Calling Plan license as a backup to Direct Routing.

Why it fails: Calling Plans provide PSTN connectivity through Microsoft's cloud, but they require an internet connection to Microsoft 365. During a WAN outage, the branch office loses connectivity to Microsoft 365, so Calling Plans would not work. The SBA is specifically designed to provide local PSTN fallback when the WAN is down. Adding Calling Plans would not solve the outage scenario and would incur unnecessary costs.

Enable Media Bypass on the SBA and update the network topology.

Why it fails: Media Bypass reduces latency by keeping media on the local network, but it does not provide PSTN call survivability during a WAN outage. The SBA itself is responsible for providing fallback PSTN connectivity. Media Bypass requires the SBA to have direct connectivity to the session border controller (SBC), but if the WAN is down, the SBA must handle calls locally. This option does not address the need for local call routing and failover.

Deploy a second SBC at the branch office and configure it for high availability.

Why it fails: A second SBC improves redundancy for the SIP trunk connection to Microsoft 365, but it does not provide local survivability during a WAN outage. The SBA is the component that enables local call routing when the branch loses connectivity to the cloud. Adding another SBC would not help if the WAN link is down, because the SBC still needs to communicate with Microsoft 365 for call signaling. This option misidentifies the role of the SBA.

Teams admin center > Analytics & reports > Usage reports > PSTN usage report

Why it fails: The PSTN usage report provides aggregate data on PSTN call usage and minutes, not per-call diagnostics. It can show trends but will not pinpoint why a specific user's outbound calls fail. The scenario requires real-time troubleshooting for specific users, and this report is too high-level and lacks detailed failure reasons.

Microsoft 365 network connectivity test tool

Why it fails: The Microsoft 365 network connectivity test tool assesses network readiness for Teams, including latency and connectivity to Microsoft 365 endpoints. It is not designed to troubleshoot individual call routing issues. Since inbound calls and internal calls work, the network path is likely functional, making this tool inappropriate for diagnosing outbound dialing failures.

Teams admin center > Users > select the user > Voice tab

Why it fails: The Voice tab in the Teams admin center shows a user's assigned phone number, dial plan, and voice routing policy, but it does not provide diagnostic logs for call failures. It is useful for configuration verification, but the scenario indicates inbound calls work, so the number is likely assigned correctly. This tool would not reveal why outbound calls specifically fail.

Teams admin center user activity log

Why it fails: The Teams admin center user activity log shows actions taken by users within Teams, such as creating meetings or sending messages. It does not include authentication details or conditional access policy evaluations. It would not explain why a user cannot join a meeting due to device compliance.

Call Analytics

Why it fails: Call Analytics provides data on call and meeting quality, including network metrics and device information for sessions that were established. It does not capture authentication failures or conditional access denials. Since the user cannot join, there would be no session to analyze, making this tool ineffective.

Microsoft 365 network connectivity test

Why it fails: This tool tests network connectivity to Microsoft 365 endpoints, including Teams. It can identify network-related issues that might prevent joining a meeting, but it does not evaluate conditional access policies or authentication. It would not reveal if a device compliance policy blocked access.

Teams usage reports

Why it fails: Teams usage reports provide aggregate data on how users are using Teams, such as number of meetings and messages. They do not include network performance metrics or connectivity details. Therefore, they cannot help diagnose choppy video and audio caused by network problems in a specific office.

Teams Network Planner

Why it fails: Network Planner is a design tool that helps estimate bandwidth requirements for Teams across your network. It does not provide real-time diagnostics or troubleshooting for an existing network issue. It is used before deployment or when planning changes, not for analyzing current connectivity problems in a specific office.

Call Analytics

Why it fails: Call Analytics is used to troubleshoot individual call quality issues by providing per-user call details. While it can show network metrics for a specific call, it does not provide a comprehensive analysis of the network connectivity for an entire office. It is more reactive and user-specific, not suited for assessing overall network health of a location.

The users are not members of the team and only have guest access.

Why it fails: If the users were not members, they would not see the team or channel at all. The scenario states they are members of the team but cannot send channel messages. Guest access would also affect direct messages with team members, but the issue is isolated to channel messages. Therefore, this is not the cause.

The users have been assigned a messaging policy that disables channel messages.

Why it fails: Messaging policies in Teams control features like chat, but they do not have a setting to disable channel messages specifically. Channel messaging permissions are controlled through team settings and channel moderation, not messaging policies. Therefore, a messaging policy is not the cause.

The team's sensitivity label prevents external sharing of messages.

Why it fails: Sensitivity labels can restrict external sharing but do not prevent internal members from posting messages in channels. The issue is that members cannot send messages in channels, not that messages are blocked from external recipients. Therefore, a sensitivity label is not the cause.

The meeting organizer's meeting settings to see if mobile participants are blocked.

Why it fails: Meeting organizers cannot block participants based on device type. Meeting options allow organizers to restrict who can bypass the lobby or present, but not to block mobile devices. This is not a configurable setting in Teams, so checking it would not yield a solution. The issue is more likely local to the user's mobile device.

The meeting policy assigned to the user for mobile access.

Why it fails: Meeting policies can restrict features like IP video or screen sharing, but they do not typically block joining a meeting entirely from a mobile device. If a policy were the cause, the user would likely see an error message about permissions. Checking policies first is less efficient than verifying the mobile app's basic functionality and connectivity.

The Teams upgrade policy for the user to ensure they are in Teams Only mode.

Why it fails: The upgrade policy determines whether users access Teams or Skype for Business, but if the user can join from desktop, they are already using Teams. The upgrade policy would not cause a mobile-specific join failure. This check is irrelevant to the scenario and would not help resolve the issue.

The user's Exchange Online mailbox size and archiving policy.

Why it fails: Exchange Online mailbox size does not affect Teams meeting recording storage, as recordings are saved to SharePoint and OneDrive, not to the mailbox. While the mailbox is used for scheduling and some meeting artifacts, it is not the storage location for recordings. Therefore, checking mailbox size would not resolve the issue.

The Teams meeting policy setting for cloud recording.

Why it fails: The scenario states that the meeting policy allows recording, so this setting is already confirmed. Rechecking it would be redundant and would not address the issue. The problem is likely with the storage location, not the policy, so focusing on storage-related configurations is more productive.

The Microsoft Stream service health status in the Microsoft 365 admin center.

Why it fails: Microsoft Stream is used for storing recordings in some legacy scenarios, but new Teams recordings are stored in SharePoint and OneDrive. While service health is important, if only one user is affected, it is unlikely a service-wide issue. Checking service health for Stream would not address user-specific storage problems.

The call will route to Exchange Online Unified Messaging voicemail automatically.

Why it fails: Exchange Online Unified Messaging has been retired for Microsoft Teams, and modern cloud voicemail requires explicit provisioning and enablement via Teams PowerShell properties. Without HostedVoiceMail enabled, calls cannot route to legacy or modern cloud mailboxes.

The call will ring indefinitely until the caller hangs up.

Why it fails: Unanswered calls follow standard simultaneous ringing or unanswered routing rules configured in call forwarding settings. If no voicemail box is assigned, the call eventually hits maximum ring duration thresholds and disconnects rather than ringing infinitely.

The call will automatically transfer to the user's primary departmental delegate.

Why it fails: Delegation settings must be explicitly configured by the user or administrator via call forwarding rules. Disabling hosted voice mail does not automatically trigger delegate routing unless specific simultaneous ring or call unanswered forwarding rules are established.