Monitoring Microsoft Teams
Last updated
Last updated
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 to establish a solid foundation.
To effectively follow this guide, you should be:
Familiar with the and the test types for and .
Familiar with ThousandEyes’ 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 section.
Proficient in Microsoft Teams collaboration concepts and .
Comfortable with networking concepts, such as:
TCP/IP, HTTP, DNS, and how they relate to the ThousandEyes platform
Content delivery networks (CDNs)
(QOS) settings and DSCP
The difference between DNS resolvers (recursive DNS servers) and authoritative DNS nameservers. To learn more, see the .
Hub-and-spoke WAN architecture vs. direct internet egress
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 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:
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.
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:
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.
A Microsoft Teams conference is hosted by Microsoft 365 in the same region where the first participant joined.
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.
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.
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).
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.
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.
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:
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
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.
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:
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 that you 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.
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)
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
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.
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.
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)
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.
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.
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.
To begin deploying a template:
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.
Before proceeding to review your template deployment, you may want or need to exclude some of the tests in the template from the deployment.
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
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.
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 Teams 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.
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 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.
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:
Click the Monitor Application button and select the Microsoft Teams template.
Click Review to review the test configuration.
After reviewing the test configuration, click Deploy Now to monitor Microsoft Teams.
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:
Click Add New Monitored Domain Set.
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
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.
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
To activate a package for Internet Insights when you have available licenses for it:
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:
Find the row with the package that you want to remove
In the Included column, click the Active slider to remove the package
Microsoft 365, previously known as Office 365, is not included in this article. See our guide.
Built on Microsoft 365 groups, , and the same enterprise-level security, compliance, and manageability as the rest of Microsoft 365.
Hosted on Azure virtual machines in and uses many features of Microsoft Azure.
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.
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 IP addressing scheme. Anycast networking allows DNS queries to automatically route to the “closest” name servers for the “best possible performance” as described in , 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 page.
These four general principles will help you understand :
A Microsoft Teams media endpoint in Microsoft 365 is used based on media-processing needs, and not based on call type. See and .
For more information on Microsoft’s recommendations, see .
Microsoft’s documentation provides more details on the network requirements.
Microsoft has a that can help with your network performance analysis.
, a private blog describing in detail the differences between the previous and current assessment tools.
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 section of the Enterprise Agent documentation.
Exclude all of the "Internal" tests from the template, as described in section in later in this article.
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 .
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 .
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 for more information on test layers.
For more details on the metrics collected by HTTP server tests, see the HTTP Server section of .
The diagram below shows network agent-to-server tests, audio and video testing from Enterprise Agents. If you are not using , 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.
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 for information on why this test type is important.
Multiple permissions are required to view and deploy test templates. For the complete list, see the of the Test Templates article.
Navigate to the page.
Click the dropdown ()next to the Add New Test button.
If your organization uses 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).
After clicking the Review button, the dialog moves forward to Step 3 of 3 - Review template and displays a summary of the tests, labels, and dashboards included in the deployment. Review the summary. There may be warnings () if labels or dashboards already exist from other templates being deployed previously. This is just a warning indicating the existing labels will be updated so the Microsoft Teams tests will show up in other service related dashboards. Click Deploy Now to deploy the monitoring suite The dialog updates to show the template is being generated and the tests, labels, and dashboards are being built, as shown in the image below.
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 for more information.
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 and the 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.
Navigate to the tab.
If required, edit the information for both tests under the Global Settings section. To learn more about configuring synthetic tests, see the article.
Navigate to the tab.
To learn more about real-user tests, see the article.
Go to screen and click the Packages tab
Go to screen and click the Packages tab
To learn more about Internet Insights, see the article and the of the documentation.
