Monitoring Zoom
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, understanding of how Zoom is used for collaboration, as well as familiarity with the ThousandEyes platform. If you are new to ThousandEyes, we recommend our getting started guides to establish a solid foundation.
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.
Comfortable with networking concepts, such as:
TCP/IP, HTTP, DNS, and how they relate
Content Delivery Networks (CDNs)
Quality of service (QOS) settings and DSCP
The difference between DNS resolvers (recursive DNS servers) and authoritative DNS nameservers. Learn more in the ThousandEyes Learning Center
Hub-and-spoke WAN architecture vs direct internet egress
Proficient in Zoom collaboration concepts and connectivity principles.
Introduction
This guide will walk you through how to monitor your workforce’s Zoom meeting digital experience. To accomplish this, you'll use multiple features within ThousandEyes, including:
Zoom Architecture
The Zoom architecture includes a client-side app and a server-side infrastructure. The Zoom client is software installed on clients’ computers or devices to connect to the Zoom servers. The servers are hardware and software dedicated to hosting meetings, routing the traffic, and providing the associated services. Zoom servers are in data centers, public cloud (AWS), and corporate networks. This section describes the highlights of Zoom’s key technologies.
Zoom Data Center
The Zoom data center hosts the Meeting Zones. A Meeting Zone consists of a cluster of servers that are used to host a Zoom call. Meeting Zones can be in one of Zoom’s data centers or in an organization’s network if they use Zoom’s on-premises solution (this is managed from the Zoom public cloud). Meeting Zones consist of a Multimedia Router (MMR) and a Zone Controller (ZC). The Multimedia Router routes audio and video streams to the correct participants in a Meeting Zone. Zone Controllers manage new connections, monitor the server load and overall are responsible for all the activity in the Meeting Zone.
Zoom’s Server Architecture
Zoom’s backend infrastructure consists of interconnected data centers spread across the globe to reduce the latency of video calls. Zoom uses geolocation to pinpoint which data center is closest to each user and then routes the traffic through that data center. The table below includes a sample of the abbreviations for various zoom data centers. (Use the link to see the full list.)
City | Code | Subdomains | Region |
San Jose | SJ, SC, SJC, PAO | sj.zoom.us, sc.zoom.us, sjc.zoom.us, pao.zoom.us | US |
Toronto | TR, YYZ | tr.zoom.us, yyz.zoom.us | CA |
Amsterdam | AM, AMS | am.zoom.us, ams.zoom.us | EU |
Singapore | SG, SIN | sg.zoom.us, sin.zoom.us | ASIA |
Tokyo | TY | ty.zoom.us | JAPAN |
Sydney | SY, SYD | sy.zoom.us, syd.zoom.us | AU |
For other standards-based video conferencing solutions like Cisco, Polycom, Tandberg, Lifesize, Panasonic and Aver, Zoom has a conference room connector (CRC) hosted in their cloud data center, which allows connections to Zoom meetings. It acts as a bridge between the Zoom cloud and on-premises systems. Additionally, Zoom has a virtual room connector (VRC), which can be deployed as an OVF in a customer’s data center to perform this same function.
Web Infrastructure
This hosts the zoom.us website as well as multiple internal APIs. The website and APIs are leveraged by external developers and other pieces of Zoom’s architecture. For example, when a video call is started, the Web Infrastructure determines the Zoom Meeting Zone.
Content Delivery Network (CDN)
Zoom uses Cloudflare as their primary CDN for services and content. A content delivery network (CDN) is a group of distributed servers that caches content near end users providing improved performance, lower latency, reliability, security and redundancy.
HTTP Tunnel
HTTP tunnels exist on each Meeting Zone and in the Public Cloud. The tunnels offer participants a point of connection should other network connection strategies fail.
Zoom Client
The Zoom client consists of an app for iOS, Android, Web, PC, and Mac that is used by end users to join meetings, chat, and make calls. Regardless of the app used, the communication with Zoom’s architecture functions in the same way.
Zoom Protocols
Zoom leverages a dynamic protocol selection strategy for client-server communication, utilizing UDP for its low latency and then, if necessary, switching to TCP followed by SSL. The approach is the same for multi-participant meetings and the fallback could be due to issues like firewalls blocking types of traffic, packet loss, or high latency.
Zoom Meeting Call Flow
In order to effectively monitor Zoom services, it’s important to understand that zoom.us uses CloudFront as a CDN and is hosted in AWS data centers (Zoom data centers) which initiate the command or call, controlling the signaling and communication during a Zoom meeting or call. The multi-media routers (MMRs) transcode the audio and video stream from users and from other MMRs. ThousandEyes has Cloud Agents that are located in AWS data centers around the world, but they are not necessarily installed in the same zone that Zoom uses to host their MMRs. The ThousandEyes AWS Cloud Agents are still a good way to determine the health of the general network path to the AWS data center.
The image below shows the Zoom clients connecting to zoom.us, which controls the authentication and conference information, and manages the users’ meeting permissions. The blue arrows represent how the Zoom MMRs communicate between the different data centers.
The client selects the best MMR based on its location and network performance, as well as the best protocol for the connection - i.e., UDP, TCP, HTTPS, proxy, etc.
The MMRs handle the backend communication between the different Zoom data centers to facilitate the meeting between the different Zoom users.
Monitoring Zoom Meetings with Cloud and Enterprise Agents
This section includes where to locate your ThousandEyes agents to monitor Zoom meetings, Zoom’s network testing and performance requirements, and what to test from each vantage point. ThousandEyes Enterprise Agents provide vantage points within your own secure networks and ThousandEyes Cloud Agents provide monitoring from outside of your own networks.
Zoom Client Network Testing and Troubleshooting
One tool that you can use when reactively troubleshooting network connectivity issues between the Zoom desktop client and Zoom services is the Zoom Network Connectivity Tool. It is built into the Zoom client, and can run network tests to potentially provide insight into network issues.
To employ a more proactive and holistic end-user monitoring solution, see Monitoring Zoom with Endpoint Agents.
The following table provides network performance recommendations based on the Zoom help center's meeting and phone statistics:
Metric | Optimal | Acceptable | Degraded |
Packet Loss | 0% | <1% | >1% |
Latency | 100 ms | 100-150 ms | >150 ms |
Jitter | <30 ms | 30-40 ms | >40 ms |
MOS | 4.0-5.0 | 3.5 | <3 |
Agent Placement and Selection
Use ThousandEyes Enterprise Agents to proactively monitor your Zoom collaboration experience from vantage points within your enterprise WAN. This is known as “inside-out” testing.
In the default template configuration, you should have Enterprise Agents to deploy the Zoom 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 the Zoom application performance.
Use ThousandEyes Cloud Agents to:
Monitor public DNS infrastructure and Zoom’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 Zoom. These Cloud Agents provide an external baseline.
Note on Proxies
Zoom fully supports HTTPS/SSL proxy servers via port 443 for Zoom traffic. Zoom will automatically detect proxy settings although users may be prompted to enter the proxy username/password. For best performance, it is recommended to allow zoom.us and *.zoom.us to bypass SSL inspection. You can find more details in the Zoom network firewall or proxy server settings page.
Zoom Monitoring Test Template
ThousandEyes provides a single test template that includes Cloud and Enterprise Agent tests for comprehensive network and DNS monitoring of the following critical Zoom Meeting services:
.zoom.us
zoomcrc.com (optional: Zoom Conference Room Connector)
The Zoom Meeting template does not include the following ThousandEyes tests:
Site-to-site testing with Enterprise Agents using RTP or agent-to-agent UDP testing.
SIP tests to monitor the Zoom virtual room connector (VRC) using Enterprise Agents.
Agent-to-agent UDP tests from Enterprise Agents to the AWS cloud region that is configured to host your Zoom meetings.
Network agent-to-server tests for monitoring Zoom MMRs.
QoS-based tests for monitoring Zoom MMRs.
Transaction tests to monitor https://status.zoom.us, which could be configured to verify when services are operational.
Included Tests
The template includes these 4 tests:
The tests leveraging Cloud Agents are marked “external” in the template and Enterprise Agents are marked “internal” as described in the sections below.
Zoom Application Test
This HTTP server test will monitor the performance, reachability, and availability of the Zoom landing page or your tenant landing page.
Test Layer / Type | Web / HTTP Server |
Test Description | Monitor the Zoom Application |
Test Target (URL) | https://.zoom.us |
Interval | [1 / 2 / 5 minutes] |
Agents | [Enterprise Agents, Cloud Agents for base line] |
Advanced Settings | Follow Redirects: Disable |
Zoom Cloud Room Connector
This HTTP server test will monitor the performance, reachability and availability of the Zoom Cloud Room Connector. It is enabled by default for Enterprise Agents only and can be updated to match your cloud room connector region. Note: It should be toggled off if you do not use this service.
Test Layer / Type | Web / HTTP Server |
Test Description | Monitor the Zoom Cloud Room Connector (see Zoom Domains for regional list of CRCs) |
Test Target (URL) | https://zoomcrc.com |
Interval | [1 / 2 / 5 minutes] |
Agents | [Enterprise Agents] |
Advanced Settings | Follow Redirects: Disable |
Zoom Application DNS Server test
This test is configured to run from ThousandEyes Enterprise Agents to monitor network connectivity and DNS resolution performance to your DNS recursive resolvers (public or internal).
Test Layer / Type | DNS / DNS Server |
Test Description | Monitor the DNS resolution for Zoom |
Test Target (domain) | .zoom.us |
DNS Servers | [Customer’s DNS Resolvers] |
DNS Class | IN |
DNS Record Type | CNAME |
Interval | [1 / 2 / 5 minutes] |
Agents | [Enterprise Agents] |
Advanced Settings | Send recursive queries: false |
Zoom Application DNS Trace test
The DNS trace test monitors DNS from the root nameservers, through the top-level domain (TLD) nameservers, and down to the Zoom authoritative nameservers. This test will be ran from ThousandEyes Cloud Agents.
Test Layer / Type | DNS / DNS Trace |
Test Description | Public DNS Infrastructure |
Test Target (domain) | .zoom.us |
DNS Record Type | CNAME |
Interval | [1 / 2 / 5 minutes] |
Agents | [Cloud Agents] |
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 Zoom due to the extensive use of Anycast, 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." If you need to conserve ThousandEyes units, you can toggle these tests off to disable them, or modify them to a higher test interval.
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 Zoom monitoring 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 Zoom application and Cloud Room Connector (CRC) 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 identify the scope of any issues quickly and easily, 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 Zoom 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?.
DNS Server Test Deployment
The diagram below shows DNS server testing from Enterprise Agents. When your users try to access Zoom, their device must be able to resolve the hostname (i.e. zoom.us) to the best IP address for the service. 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 Zoom
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 Zoom test template, you will need to know the IP addresses or host names 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 Zoom’s authoritative nameservers. See DNS Trace Test for information on why this test type is important.
Using the Zoom Template
Now that we've discussed all the tests, agents, and targets in the ThousandEyes Zoom Meeting 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
Select Add From Template.
The Deploy Template dialog opens.
In the Deploy Template dialog, either use the Search field and type “Zoom” to filter the list of available templates, or use the Collections filter pulldown to select Zoom.
Click the Zoom Meetings template to proceed with configuring the tests and deploying the template.
After clicking the Zoom Meeting template, the dialog moves forward to Step 2 of 3 - Configure tests showing 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.
Enter your Zoom tenant. This example uses thousandeyes.
Select a testing interval. (Recommended: 1 or 2 minutes; no greater than 5 minutes)
Enter your DNS resolvers. See the note below.
Provide a name for your test suite to easily identify the tests that are deployed using 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.
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 Review.
Before proceeding to review your template deployment, you may want or need to exclude some of the tests in the template from the deployment. For example, if you do not use the Zoom CRC, toggle the test off before continuing to the review step.
Note on Entering DNS Resolvers
By default, the template will automatically look up the authoritative DNS servers for the Zoom tenant. 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.
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.
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 brings you to the Cloud & Enterprise Agents > Test Settings page, filtered to show only the tests included in this deployment.
Clicking Go to Dashboards brings you to the dashboard created by the template.
Click the button or links:
• Click Done to close the window. Or click Create Another Template* to monitor other services. • Click Go To Test Settings to see a filtered view of the tests that have been deployed. • Click Go To Dashboards to open the deployed dashboard, which will be covered in the next section. It will take a moment for the tests to run and gather results before the dashboard will display the metrics from the deployed tests.
Zoom Meeting Health Overview Dashboard
This section describes the dashboard that is included in the Zoom Meeting 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 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.
The dashboard provides a service-oriented health overview for Zoom Meetings. The widgets in this dashboard are primarily grouped by service, highlighting issues that affect one or more of the individual Zoom Meeting services.
The first three rows of the service-oriented dashboard show alerts activity, web app health summary, and network health summary, aggregated for all Zoom Meeting 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 Zoom Meetings overall.
When Zoom 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 alert’s 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 Zoom Meetings and the map view, shown above, helps isolate where users are having high latency or packet loss 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 Zoom Meeting services, such as the tenant site landing page, DNS and Zoom CRC (optional). 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 display each of your Zoom Meeting 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 that covers the catalogs for seeing when large-scale Zoom outages occur. These are not included in the default dashboard, but can be easily added based on your requirements.
Monitoring Zoom 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 Zoom combined with scheduled synthetic testing for proactive monitoring. ThousandEyes recommends deploying Endpoint Agents and enabling the following synthetic and real-user tests to best monitor Zoom meetings. You must have the Edit endpoint tests permission to set up scheduled and dynamic tests.
Synthetic Tests
Synthetic Endpoint Agent tests consist of a combination of scheduled and dynamic tests and should be enabled for all Zoom meeting users. They can be easily configured by navigating to Endpoint Agents > Test Settings > Synthetic Tests. Click on the Monitor Application button and select the Zoom monitoring template.
Scheduled Test and Dynamic Tests
Scheduled tests run from Endpoint Agents at regularly scheduled intervals without any user interaction and provide a great baseline for troubleshooting. The following tables contain the information on the tests and settings that are built into the Zoom Endpoint Agent application monitoring template.
Test Layer / Type | Web / HTTP Server |
Test Name | Zoom - HTTP Server |
Test Target (URL) | https://.zoom.us |
Protocol | Auto-detect |
Agents | [All agents, specific agents or your preferred agent label] |
Interval | [1 / 2 / 5 minutes] |
Other Basic Configuration | [Prioritize this test for the selected agents] |
Advanced Settings | Follow Redirects: Disable |
Dynamic tests for Zoom enable the Endpoint Agent to monitor and identify the dynamic network connections between an end-user's Zoom application and the destination meeting node (host server). This provides detailed network connectivity information helping isolate and solve issues as the tests are created based on destination(s) used for the Zoom meeting and are torn down when the meeting session ends.
Target | Zoom |
Protocol | Auto-detect |
Interval | [1 / 2 / 5 minutes] |
Agents | All Agents |
Prioritize | Toggle On |
Maximum Number of Agents | Adjust Based on Deployment |
Follow the steps shown below to configure end user Zoom Meeting visibility using scheduled and dynamic tests.
Go to the Endpoint Agents > Test Settings. (The default view will be the Synthetic Tests tab.)
Click + Monitor Application.
The Monitor Application modal opens.
Select the Zoom Endpoint Agent template and fill out the form based on each of the configurations shown below:
Application Name: Zoom
Interval: 1/2/5 minute
Zoom Tenant Name: Enter your Zoom tenant name. This example shows “thousandeyes” which will automatically configure the HTTP server test to target “thousandeyes.zoom.us”.
Source Agents: All agents
Max Number of Agents per Tests: Adjust this based on your deployment (25 is the default).
Click the Review button to verify the application monitoring configuration then click the Deploy Now button.
To verify the default scheduled test configuration, use the *Run Once option by selecting the Zoom – HTTP Server test. You may have to adjust the test settings to match your network configuration.
You should see the below window indicating that setup completed successfully.
Click the Done button or click Go to Test Settings to view the newly created Zoom tests as shown in background.
To learn more, see the Monitoring an Application using Synthetic Tests article.
Real User Tests
Configure real user monitoring for Zoom by including the most important domains in the monitored domain set for your Endpoint Agents. Real user browser session monitoring provides you with detailed session information when users navigate in their web browser to the associated monitored domain including page load elements, detailed endpoint information and network statistics. ThousandEyes recommends creating the below Monitored Domain Set for Zoom.
Navigating to the Endpoint Agents > Test Settings and click the Real User Tests tab.
Click the Add New Monitored Domain Set button.
The Add New Monitored Domain Set window will pop out. Configure it using the below settings.
Domain Set Name: Zoom Monitoring
Monitored Domains:
zoom.us
zoom.com
digicert.com
zoomonprem.com
zoom-general.s3.amazonaws.com
Agents: Adjust based on deployment but all agents are selected by default.
Click Add New Monitored Domain Set
The browser plugin must be installed and active for the ThousandEyes Endpoint Agent to capture browser statistics. More information can be found in the Install the Endpoint Agent Browser Extension guide.
To learn more about configuring browser sessions, see the Real User Tests article.
Monitoring Zoom with Internet Insights
When a critical service is disrupted, it is common to wonder if you are 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 AWS (Amazon Web Services) and Zoom. 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 there is a larger outage causing a Zoom service disruption. The UCAAS package directly aligns with the Zoom application services and will help isolate large outages with Zoom. The AWS IAAS package will help you clearly isolate larger issues for the Zoom data centers hosted in AWS and issues with meeting and chat transcriptions stored in a S3 bucket. Lastly the ISP package will help show larger ISP outages that are causing Zoom-related network access issues.
UCAAS package for each applicable region:
Zoom
IAAS package in each applicable region, which includes:
Amazon Web Services
ISP package for each applicable region:
Asia/Pacific ISPs
EMEA ISPs
Latin America ISPs
North America ISPs
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
