Monitoring Microsoft Teams
This best-practices guide is intended for readers who already have some proficiency in ThousandEyes and are ready to delve into more advanced guidance. It assumes a basic understanding of networking concepts, an understanding of how Microsoft Teams is used for collaboration, as well as familiarity with the ThousandEyes platform. If you are new to ThousandEyes, we recommend starting with our getting started guides to establish a solid foundation.
This article describes monitoring for a third-party application, and might not apply to all use cases. Because the third-party company updates their application separately from ThousandEyes, the information outlined here might not represent the application's latest architecture. ThousandEyes will provide best-effort support for these solutions.
Audience Prerequisites
To effectively follow this guide, you should be:
Familiar with the three types of ThousandEyes agents and the test types for Cloud and Enterprise Agents and Endpoint Agents.
Familiar with ThousandEyes’ role-based access control settings to ensure your user account has the necessary permissions.
Able to deploy Enterprise Agents and/or Endpoint Agents, if they’re not already deployed.
Aware of your organization’s available licenses for Endpoint Agents and Internet Insights, and available units for Cloud and Enterprise Agents. For information on your organization’s usage and capacity, see the articles in the Usage-Based Billing section.
Proficient in Microsoft Teams collaboration concepts and connectivity principles.
Comfortable with networking concepts, such as:
TCP/IP, HTTP, DNS, and how they relate to the ThousandEyes platform
Content delivery networks (CDNs)
Quality of service (QOS) settings and DSCP
The difference between DNS resolvers (recursive DNS servers) and authoritative DNS nameservers. To learn more, see the ThousandEyes Learning Center.
Hub-and-spoke WAN architecture vs. direct internet egress
Introduction
This guide will walk you through how to monitor your workforce digital experience for Microsoft Teams. To accomplish this, you'll use multiple features within ThousandEyes, including:
ThousandEyes Cloud and Enterprise Agents
ThousandEyes Endpoint Agents
ThousandEyes Internet Insights
Microsoft 365, previously known as Office 365, is not included in this article. Please see our Monitoring Microsoft 365 guide.
Microsoft Teams Architecture
Microsoft Teams is a cloud-based unified communication and collaboration platform that combines persistent workplace chat, video meetings, file storage (including collaboration on files), and application integration into a single workspace. The Teams service integrates with the company's Microsoft 365 subscription office productivity suite, previously known as Office 365, and features additional extensions that can integrate with non-Microsoft products. In order to effectively monitor a SaaS collaboration solution like Microsoft Teams, it is important to understand its architecture: where and how the services are hosted, and how your users reach those locations.
Microsoft Teams is designed to provide a reliable and scalable platform for global collaboration. The solution is:
Built on Microsoft 365 groups, Microsoft Graph, and the same enterprise-level security, compliance, and manageability as the rest of Microsoft 365.
Based on identities stored in Azure Active Directory (Azure AD) and provides users with access to critical services, such as chat, video conferencing, and file sharing, regardless of their location in the world.
Hosted on Azure virtual machines in Microsoft datacenters and uses many features of Microsoft Azure.
One of the key technologies is front-end optimization, which places servers as close to users as possible. This helps to reduce latency and improve performance. Microsoft Teams uses a global network of front-end servers to provide users with access to the service from all over the world.
Another key technology that Microsoft Teams uses is the Azure content delivery networks (CDNs) that are distributed around the world. Azure CDNs are used to cache static content, such as images, documents, CSS, and JavaScript files. This helps to improve performance and reduce bandwidth usage. Microsoft Teams uses Azure CDNs to deliver static and streaming content to users from the server that is closest to them.
In addition to front-end optimization and Azure CDNs, Microsoft Teams also uses several other technologies to ensure global access to critical services, such as:
Traffic shaping to prioritize critical traffic, such as chat and video conferencing. This helps to ensure that users have a good experience with the service, even when there is high traffic on the network.
Load balancing to distribute traffic across multiple servers, to improve performance and reliability.
Redundancy to ensure that critical services are always available. Microsoft Teams leverages multiple servers that can provide the same service so that if one server fails, the other servers can continue to provide the service.
Multi-geo capabilities that enable Microsoft Teams chat data to be stored at rest in a specified Macro Region Geography or Local Region Geography location. Chat data consists of chat messages, including private messages, channel messages, and images used in chats.
There are multiple domains and subnets associated with Microsoft Teams, all managed by Microsoft. The domain's authoritative name servers are hosted in Azure DNS. These name servers use an anycast IP addressing scheme. Anycast networking allows DNS queries to automatically route to the “closest” name servers for the “best possible performance” as described in What is Azure DNS?, but it doesn’t always work as intended when internet routing paths are suboptimal.
The answers supplied by the authoritative nameservers may also be anycast IP addresses – the regional authoritative nameserver may also respond with a unicast IP address within the same region, or within a different region. DNS resolution is a way Microsoft steers users to healthy service instances. Service health status can be viewed on the Azure Status page.
These four general principles will help you understand Microsoft Teams call flows:
A Microsoft Teams conference is hosted by Microsoft 365 in the same region where the first participant joined.
A Microsoft Teams media endpoint in Microsoft 365 is used based on media-processing needs, and not based on call type. See Microsoft Teams Meeting and Call Flow for Internal Users One-on-One and Microsoft Teams Meeting and Call Flow for Users Who Cannot Connect Directly.
Media traffic for peer-to-peer calls takes the most direct route that is available, assuming that the call doesn't mandate a media endpoint in the cloud (see #2 above). The preferred route is direct to the remote peer (client), but if that route isn't available, then one or more Transport Relays will relay traffic. It is recommended that media traffic should not be routed through packet shapers, VPN servers, and so on, since this will impact the media quality.
Signaling traffic from the user always goes to the closest server.
Microsoft Teams Meeting and Call Flow for Internal Users One-on-One
The illustration below shows a one-to-one Microsoft Teams call flow for internal users who can connect directly.
Teams User 1 sends a call invitation to Teams User 2 via Microsoft Teams
Microsoft Teams notifies Teams User 2 of call invitation from Teams User 1
The system attempts to connect Teams User 1 and Teams User 2 directly (detecting if it's possible)
Direct connection prefers UDP for voice and video traffic, but will use TCP 443 as a fallback. This is also ThousandEyes' testing strategy, as it takes the same network path.
Microsoft Teams Meeting and Call Flow for Users Who Cannot Connect Directly
The illustration below shows an example for users who connect through a Microsoft Teams Transport Relay.
Teams User 1 connects to Microsoft Teams (TCP/443) to send a call invitation to Teams User 2.
Microsoft Teams notifies Teams User 2 of the call invitation from Teams User 1.
Teams User 2 connects to Microsoft Teams (TCP/443) and answers the call invitation.
The client for Teams Users 1 and 2 detects that a direct connection is not possible, and connects using the Microsoft Teams Transport Relay.
Conversation starts between Teams User 1 and Teams User 2 using the Transport Relay. It will prefer UDP for voice and video traffic, but will fall back to TCP 443 (which is ThousandEyes' testing strategy).
In order to provide high-quality, low-latency connectivity to achieve the best call quality within Microsoft Teams, Microsoft recommends that you:
Bypass devices that affect latency, such as proxies and DPI.
Use the path to the Microsoft edge closest to your network.
Use UDP for voice and video traffic as preferred, but fall back to TCP 443 - which is the same as the ThousandEyes testing strategy, since the network traffic will take the same path.
Ensure that DNS resolves in the local network.
Measure and calculate delay, loss, jitter, and required bandwidth to Microsoft 365 in advance.
For more information on Microsoft’s recommendations, see Proxy servers for Teams and Skype for Business Online.
The illustrations above show the sequence of how users connect for a Microsoft Teams call. The two illustrations below show the two prevailing enterprise network architectures.
On the left, branch offices must backhaul through a central internet egress point at the head office, leading to a worse user experience because traffic is not routed to the nearest Microsoft Teams front door for all users. On the right, branch offices have local internet breakout, and can directly reach the nearest Microsoft Teams service front door.
The primary region will be based on where the initial user initiates the Microsoft Teams meeting.
Monitoring Microsoft Teams with Cloud and Enterprise Agents
To monitor Microsoft Teams, use ThousandEyes Enterprise Agents from within your own secure networks, and use ThousandEyes Cloud Agents to monitor from outside of your own networks. This section includes: where to locate your ThousandEyes agents, Microsoft's network performance requirements, and what to test from each vantage point.
Network Performance Requirements Edge-to-Edge
To ensure a good meeting and collaboration experience for your users, connectivity between your company’s own network edge and the Microsoft network edge must meet the network performance requirements and thresholds shown in the table below. The ThousandEyes tests that will be set up using the Microsoft Teams template will provide you with an easy way to visualize the network performance and quickly isolate issues, whether it’s an internal issue, external ISP problem, or Microsoft’s network.
See these additional resources for more information:
Microsoft’s Media Quality and Network Connectivity Performance in Microsoft Teams documentation provides more details on the network requirements.
Microsoft has a Network Assessment Tool that can help with your network performance analysis.
Teams Network Assessment Tool (July 2021 update), a private blog describing in detail the differences between the previous and current assessment tools.
Metric
Target
Latency (one way)
< 30ms
Latency (RTT)
< 60ms
Burst packet loss
<1% during any 200 ms interval
Packet loss
<0.1% during any 15s interval
Packet inter-arrival jitter
<0.01% out-of-order packets
Agent Placement and Selection
Use ThousandEyes Enterprise Agents to proactively monitor your Microsoft Teams collaboration experience from vantage points within your enterprise WAN. This is known as “inside-out” testing.
In the default template configuration, you must have Enterprise Agents in order to deploy the Microsoft Teams test template. If you have not yet installed any Enterprise Agents, see the Installing section of the Enterprise Agent documentation.
At a minimum, place an Enterprise Agent at each internet egress point.
For hub-and-spoke network architectures with centralized egress, the recommended best practice is to also test from Enterprise Agents at each “spoke” user location. Spokes are typically branch offices.
Enterprise Agents are used to monitor DNS resolution (either internal resolvers or public resolvers), and to monitor Microsoft Teams application performance.
Enterprise Agents are required in 8 of the 14 tests included in the Microsoft Teams test template. If you want to deploy the Microsoft Teams test template without any Enterprise Agents, you must:
Exclude all of the "Internal" tests from the template, as described in Excluding Tests from the Template Deployment section in Using the Microsoft Teams Test Template later in this article.
Select any Cloud Agent in the Which Enterprise Agents should we run tests from? agent selector.
The template requires that all user input fields be filled. If you disable all the "Internal" tests, you must nevertheless make a selection in the Which Enterprise Agents field. Your selection will not be used in any of the deployed tests; it is only required because of user input validation.
Use ThousandEyes Cloud Agents in order to:
Monitor public DNS infrastructure and Microsoft’s authoritative nameservers.
Establish a baseline for web application performance outside of the enterprise network.
It is recommended to select at least one Cloud Agent for each region where you have an internet egress and an Enterprise Agent. Additionally, Cloud Agents can be added based on where you have a concentration of users connecting to Microsoft Teams. These Cloud Agents provide an external baseline.
Note on Proxies
Since Microsoft Teams media traffic is already encrypted, passing this traffic through a proxy server doesn't make the traffic any more secure. Proxies can cause performance problems with latency, incorrect traffic routing, and packet loss when Microsoft Teams traffic is routed through a proxy server. Microsoft recommends that Microsoft Teams traffic bypass any proxy server infrastructure, including SSL inspection. You can find more information in Proxy servers for Teams and Skype for Business Online.
Microsoft Teams Test Template
ThousandEyes provides a single test template that includes Cloud and Enterprise Agent tests for comprehensive monitoring of the following Microsoft Teams critical services:
Microsoft Teams Relay
The Microsoft Teams application portal
The Microsoft online login service (a common shared service)
The Microsoft Teams template does not include site-to-site testing with Enterprise Agents using RTP or agent-to-agent UDP testing. But these could be used to provide more visibility into your internal network health and performance. Additionally, you could run agent-to-agent UDP tests from Enterprise Agents to the closest Azure cloud agents.
Included Tests
There are four types of ThousandEyes test included in the Microsoft Teams test template. The tests leverage Cloud Agents (marked “external” in the template) and Enterprise Agents (marked “internal” in the template):
HTTP server tests run from both ThousandEyes Enterprise Agents and Cloud Agents. HTTP server tests are used to monitor the performance, reachability, and availability of the Microsoft Teams landing page and Microsoft login site. The test template includes Enterprise Agents tests and a separate set of tests sourced from the selected Cloud Agents and targeting the following sites:
https://teams.microsoft.com
https://login.microsoftonline.com
Network agent-to-server tests run from both ThousandEyes Enterprise Agents and Cloud Agents. These tests are used to monitor the Microsoft Teams Transport Relay. If you have QoS enabled for Microsoft Teams, the tests for audio and video are preconfigured with the appropriate DSCP settings and should be enabled. This will show where in your network DSCP values are not being honored or where they get changed. Otherwise, you can use a single network test which will be applied to your Enterprise Agents (“internal”). There is also a network test that is applied to Cloud Agents (“exernal”) so you can quickly see if the issue is internal versus external. The following endpoint is the test target for the Microsoft Teams Transport Relay:
worldaz.tr.teams.microsoft.com
DNS server tests run from ThousandEyes Enterprise Agents (“internal”). These tests monitor network connectivity to your DNS recursive resolvers (public or internal) and DNS resolution performance. The following domains are included in the test template to ensure the health of DNS for the Microsoft Teams service:
teams.microsoft.com
login.microsoftonline.com
worldaz.tr.teams.microsoft.com
DNS trace tests run from ThousandEyes Cloud Agents (“external”). DNS trace tests monitor the DNS from the root nameservers, through the top-level domain (TLD) nameservers, and down to the Microsoft Teams authoritative nameservers. The following domains are included in the test template:
teams.microsoft.com
login.microsoftonline.com
worldaz.tr.teams.microsoft.com
The HTTP server, network agent-to-server, and DNS server test types are multi-layer: they automatically include network tests towards their targets, measuring packet loss, latency, jitter, and identifying the network path. This is all in addition to the application metrics they collect. See Test Type Layering for more information on test layers.
Monitoring DNS in addition to HTTP for application availability and performance is crucial because DNS is critical for translating domain names to IP addresses. Any issues or delays in DNS resolution can significantly impact the accessibility and performance of a web application, even if the HTTP service itself is functioning properly. DNS is especially important for Microsoft Teams due to the large anycast DNS architecture, the use of low time-to-live values (i.e, minimal caching and frequent lookups), and because DNS is used to direct users to the best service front door.
Note that the Microsoft Teams test template includes two HTTP server tests for each of the target services: one HTTP server test is sourced from Enterprise Agents (the “internal” tests) and a second HTTP server test sourced from Cloud Agents (the “external” tests).
This configuration consumes the same number of units as if the HTTP server tests were combined into a single test from both types of agent. However, it is more flexible in terms of visualizing the data in dashboards and test views, and for fine-tuning alert rules. For example, you may decide to disable alert rules for the tests that only run from external vantage points and only treat alerts from internal vantage points as actionable.
A high-level diagram is shown for each of these test types below, in the next section. When you deploy the test template, you will have the opportunity to deselect any of the tests you do not want to include in your Microsoft Teams test suite.
HTTP Server Test Deployment
The diagram below shows HTTP server testing from Cloud Agents and Enterprise Agents. As described previously, Enterprise Agents should be placed at each internet egress point – in the diagram below, this includes the branch office shown at the top, and the head office. If any branch offices do not have direct internet egress and instead backhaul through an enterprise WAN, Enterprise Agents should also be deployed at the branch office location if possible. The Enterprise Agent HTTP server tests monitor each site’s network path and quality to the Microsoft Teams service front doors, Microsoft Login application performance, and availability metrics.
The Cloud Agent HTTP server tests provide a baseline and reference point to complement your own Enterprise Agent tests. The combined visibility of internal and external vantage points allows you to quickly and easily identify the scope of any issues, such as:
Issues solely within your enterprise network or network edge (e.g., one or more Enterprise Agents affected, no Cloud Agents affected)
Issues within regional transit providers (e.g., multiple Enterprise Agents and Cloud Agents affected within a particular region or ISP)
Issues within Microsoft Teams itself (e.g., all Enterprise Agents and Cloud Agents affected, either within a region or globally)
For more details on the metrics collected by HTTP server tests, see the HTTP Server section of What Do Your Results Mean?.
Network Agent to Server Test Deployment
The diagram below shows network agent-to-server tests, audio and video testing from Enterprise Agents. If you are not using QoS for Microsoft Teams, the audio and video tests can be disabled and a single network-to-agent Transport Relay test used instead. Cloud Agents are used for external testing but do not use the DSCP values, so there is just a single test.
As described previously, Enterprise Agents should be placed at each internet egress point – in the diagram below, this includes the branch office shown at the top, and the head office. If any branch offices do not have direct internet egress and instead backhaul through an enterprise WAN, Enterprise Agents should also be deployed at the branch office location if possible. The Enterprise Agent network agent-to-server tests monitor each site’s network path and quality to the Microsoft Teams Transport Relay service front doors.
DNS Server Test Deployment
The diagram below shows DNS server testing from Enterprise Agents. When your users try to access Microsoft Teams, their device must be able to resolve the hostname (e.g, teams.microsoft.com) to the IP address for the service front door. There are three critical components to this operation:
The device’s configured DNS resolver
The public DNS infrastructure (including root nameservers and top-level domain nameservers)
The authoritative nameservers for Microsoft Teams
The purpose of the DNS server tests from your Enterprise Agents is to monitor your own organization’s DNS resolvers.
Your organization may use internal DNS resolvers or public DNS resolvers, or sometimes both. Common public DNS resolvers include Google DNS, Cloudflare DNS, Quad9, and Cisco Umbrella (formerly OpenDNS). To deploy the Microsoft Teams test template, you will need to know the IP addresses or hostnames of the DNS resolvers that your organization uses. If you do not know your organization’s DNS resolvers, you should ask your network team or DNS team, if your organization has one.
In this template, DNS server tests are only run from Enterprise Agents to accommodate use cases where none of your resolvers are public and are therefore unreachable from Cloud Agents.
If your organization uses public DNS resolvers, you may add Cloud Agents to the DNS server tests from the Cloud & Enterprise Agents > Test Settings page after you deploy the template.
DNS Trace Test Deployment
The diagram below shows DNS trace testing from Cloud Agents. While the DNS server test described earlier monitors your DNS resolvers, the DNS trace test monitors the public DNS infrastructure and Microsoft Teams authoritative nameservers. See DNS Trace Test for information on why this test type is important.
Using the Microsoft Teams Template
Now that we've discussed all the tests, agents, and targets in the ThousandEyes Microsoft Teams test template, we are ready to use this template to deploy our tests.
Multiple permissions are required to view and deploy test templates. For the complete list, see the Prerequisites section of the Test Templates article.
To begin deploying a template:
Navigate to the Cloud & Enterprise Agents > Test Settings page.
In the dropdown menu, click Add From Template.
The Deploy Template dialog opens. At the top of the Deploy Template dialog:
Type “Microsoft Teams” in the Search box to filter the list of available templates
Click the Microsoft Teams template in the list to proceed to configure the tests
After clicking the Microsoft Teams template, the dialog moves forward to Step 2 of 3 - Configure tests and shows the template’s Global Settings. This test template requires you to:
Select the Enterprise Agents for the internal tests
Select the Cloud Agents for the external tests
Select a testing interval (recommended: 1 or 2 minutes, no greater than 5 minutes)
Enter your DNS resolvers, see note below
Provide a name for your test suite to easily identify which tests were deployed from this template. This name is arbitrary, but note that:
The name will be prefixed to all of the tests’ names, and long names may be harder to discern or distinguish in dashboards and test views
A label will be created with this same name and applied to all the tests
Note on Entering DNS Resolvers
By default, the template will automatically look up the authoritative DNS servers for the Microsoft Teams targets. As described above, the DNS server tests are intended to monitor your DNS resolvers, not the authoritative nameservers (DNS trace tests are used for that instead).
To enter your DNS resolvers, first click the “x” at the right side of the DNS resolvers input field to clear the servers that were automatically identified.
Next, place your cursor in the text input field and type the IP address or hostname of your DNS resolver, and press your enter key. Repeat for each of your DNS resolvers.
Excluding Tests from the Template Deployment
Before proceeding to review your template deployment, you may want or need to exclude some of the tests in the template from the deployment.
If your organization uses QoS with Microsoft Teams the dedicated tests for Audio and Video (noted by 1 and 2 in the below image) have the associated DSCP settings configured and will be assigned to your deployed Enterprise Agents. These tests will provide visibility into your internal network and show if there are QoS related issues like DSCP being changed between hops. In this case you can toggle off the MS Teams - MS Teams TR - Internal test (as shown by 3 in the image below) since it does not have any DSCP settings associated with it. Conversely, if you are not using QoS then toggle off the Audio and Video tests (1 and 2) and only use the MS Teams - MS Teams TR - Internal test (3).
By default all tests will be enabled. If you do not have any Enterprise Agents deployed, you must exclude the "Internal" tests. To exclude a test, click the toggle switch next to the test’s name.
Once you have provided the necessary details in the template’s Global Settings, you should be able to proceed to review the template deployment by clicking the Review button.
The deployment process may take a few minutes to complete. When it has finished, the dialog shows a success message and includes two links:
Clicking Go to Test Settings will navigate to the Cloud & Enterprise Agents > Test Settings page, filtered to show only the tests included in this deployment
Clicking Go to Dashboards will navigate to the dashboard created by the template
Microsoft Teams Health Dashboard
This section describes the dashboard that is included in the Microsoft Teams test template. The dashboard is designed with the highest-level information shown at the top, with increasing service granularity in the widgets as you navigate down the page.
All of the widgets in these dashboards allow you to drill down into the individual tests for complete details. Click on the widget, in this example Latency, to open the drilldown dialog, then select the test or tests to view, and click Open in Views. See Troubleshooting with Dashboard Drill Down for more information.
Microsoft Teams Health Overview - By Service
This dashboard provides a service-oriented health overview for Microsoft Teams. The widgets in this dashboard are primarily grouped by service, highlighting issues that affect one or more of the individual Microsoft Team’s services.
The first three rows of the service-oriented dashboard show alerts activity, web app health summary, and network health summary, aggregated for all Microsoft Teams tests in your deployment. This top third of the dashboard, shown in the image above, is intended as a default "NOC view" from which you can easily glean the health status of Microsoft Teams overall.
When Microsoft Teams is healthy, expect to see 'No Alert Activity' in the alerts widget, and green number cards in the web app health and network app health widgets. When problems arise, alerts will show in the alerts widget, and the web app health and network app health widgets will change from green to yellow to orange to red, depending on the scope and severity of the performance degradation.
Enterprise agents provide an internal vantage point of Microsoft Teams and the map view, shown above, helps isolate where users are having high latency resulting in audio, video and screen sharing delays.
The middle section of the service-oriented dashboard, shown above, begins to break down the metrics and groups them by Microsoft Teams services, such as the landing page for meetings, Microsoft Login, and Transport Relay. This allows you to easily see if user experience for an individual service is impacted. Additionally, each row in this section contains two columns:
On the left, the widgets are filtered to show data from Enterprise Agents, i.e, tests run from within your environment
On the right, the widgets are filtered to show data from Cloud Agents, i.e, tests run from outside your environment
This allows you to quickly compare the experience from your enterprise network versus the baseline from external vantage points.
The bottom widgets of the service-oriented dashboard shows each of your Microsoft Teams tests, along with their current alert status, the most recent test measurements, and the trends of those measurements over the last 12 hours. You can click on any of the tests in this list to open the test view. The test widgets are filtered based on internal versus external tests to provide a quick visual of the service health and baseline.
To learn more about modifying dashboards or adding additional data sources like Endpoint Agent metrics or Internet Insights, network or application outages, be sure to review the Getting Started with Dashboards and the Customizing Your Dashboard guides. The next sections cover how to set up tests using Endpoint Agents for an end user perspective followed by the Internet Insights section covering the catalogs for seeing when large scale Microsoft outages occur. These are not included in the default dashboard but can be easily added based on your requirements.
Monitoring Microsoft Teams with Endpoint Agents
In addition to the Cloud and Enterprise Agent test template described above, you can use ThousandEyes Endpoint Agents for real user monitoring of Microsoft Teams combined with scheduled synthetic testing for proactive monitoring. ThousandEyes recommends the following synthetic tests and real user tests described below.
Synthetic Tests
Synthetic tests are a combination of scheduled and dynamic tests designed for end-user monitoring to gain visibility into the user experience.
The Endpoint Agents run tests at set times without needing user input. This helps with troubleshooting. The dynamic test allows the Endpoint Agent to monitor and identify the changing network connections between a user's Microsoft Teams application and the destination node (host server). This gives detailed network information to help find and fix issues. The tests are based on the destination used for the Microsoft Teams meeting and are stopped when the session ends.
Configure Synthetic Tests
You must have the Edit endpoint tests permission to configure synthetic tests.
ThousandEyes provides a pre-defined (but customizable) synthetic test template for Microsoft Teams comprising the required tests configured with the options and values making it efficient and easier to deploy.
To configure the synthetic test:
Navigate to the Endpoint Agents > Test Settings > Synthetic Tests tab.
Click the Monitor Application button and select the Microsoft Teams template.
If required, edit the information for both tests under the Global Settings section. To learn more about configuring synthetic tests, see the Configuration Options for Synthetic Tests article.
Click Review to review the test configuration.
After reviewing the test configuration, click Deploy Now to monitor Microsoft Teams.
Real User Tests
Configure real user monitoring for Microsoft Teams by including the most important domains in the monitored domain set for your Endpoint Agents. Real user tests provide detailed session information when users navigate their web browser to the associated monitored domain including page load elements, detailed endpoint information, and network statistics. ThousandEyes recommends including the following Microsoft Teams Monitored Domain Set in your real user test configuration:
Microsoft Teams Monitored Domain Set:
teams.microsoft.com
microsoftonline.com
msidentity.com
msftidentity.com
The Edit endpoint agent monitored domain sets permission is required to configure real user tests.
Configure the real user test Monitored Domain Set as described in the steps below:
Navigate to the Endpoint Agents > Test Settings > Real User Tests tab.
Click the Add New Monitored Domain Set button.
Configure the basic settings for the session.
Add the domains above to the Monitored Domains input field (Note: You must enter each domain one at a time, you cannot copy and paste the full list)
teams.microsoft.com
microsoftonline.com
msidentity.com
msftidentity.com
Agents select All agents, Specific agents or use Agent labels (ThousandEyes recommends selecting All agents unless you have a specific use case)
Click Add New Monitored Domain Set to save so that the selected agents will monitor the domains
The browser plugin must be installed and active for the ThousandEyes Endpoint Agent to capture browser statistics.
To learn more about real user tests, see the Real User Tests article.
Monitoring Microsoft Teams with Internet Insights
When a critical service is disrupted, it's common to wonder if you're the only one affected by the outage or if the issue is larger in scope or scale. Internet Insights collects data from a diverse set of vantage points across the globe to offer visibility into service providers, including Azure and Microsoft Teams. Internet Insights is built upon ThousandEyes’ collective data set -- billions of probes across the Internet to websites, apps, and API endpoints every day -- combined with outage detection to provide a macro-scale view into network and application outages. The intelligence derived from this data enables operations teams to quickly identify and resolve issues with providers using concrete Internet telemetry data.
ThousandEyes recommends selecting the following packages in your Internet Insights Catalog Settings configuration to enable you to understand if these services are affected by disruptions.
Package Selection
SaaS package in each region from which your users work (for example, “North America SaaS Providers”), which includes:
Microsoft
Microsoft Online
Microsoft 365
UCaaS package in each region from which your users work (for example, “North America SaaS Providers”), which includes:
Microsoft Teams
IaaS package in each region from which your users work (for example, “North America IaaS Providers”), which includes:
Azure
Internet Insights packages are a pre-set collection of service providers categorized by geographic region and provider type. Here, we recommend the selection of the “SaaS” and “UCaaS” packages because they identify application outages with Microsoft Teams and its common shared underlying services with Microsoft 365.
We also recommend the “IaaS” packages, because they identify application and network outages within Azure, upon which Microsoft Teams services are built and hosted.
If possible, all should be activated. However, if your licensed capacity limits you to choosing only one, we recommend the UCaaS and SaaS packages over the IaaS packages because they are more specific to Microsoft Teams.
To activate a package for Internet Insights when you have available licenses for it:
Go to Internet Insights > Catalog Settings screen and click the Packages tab
Verify that the Available counter shows one or more licenses
Find the row with the package that you want to add
In the Included column, click the Active slider to add the package
To activate a package when you have no available licenses, you can purchase an additional license by contacting your customer success manager. Or, you can first deactivate a package, then activate the desired package in its place. To deactivate an Internet Insights package:
Go to Internet Insights > Catalog Settings screen and click the Packages tab
Find the row with the package that you want to remove
In the Included column, click the Active slider to remove the package
To learn more about Internet Insights, see the Getting Started with Internet Insights article and the Internet Insights section of the documentation.
Last updated
