SaaS Network Connectivity Test

If your Exchange Online users complain of inaccessibility, you may want to check the quality of the network link to the Exchange server online. A flaky or latent network connection to the server can sometimes deny users access to their mailboxes on the cloud, adversely impacting their overall experience with Exchange Online. To avoid this, periodically run the SaaS Network Connectivity test, and check the health of the network connection to the Exchange server on the cloud.

This is an external test that emulates a network-level ping to the cloud-based Exchange server and reports whether/not network connectivity to the server is available, and if so, how responsive the server is to network requests. In the process, the test reveals any break or slowness in the network connection to the Exchange Online service.

Target of the test : Exchange Online

Agent deploying the test : An external agent

Outputs of the test : One set of results for the Exchange server on the cloud

Configurable parameters for the test
Parameters	Description
Test period	How often should the test be executed
Host	The host for which the test is to be configured. By default, this is portal.office.com
Packet Size	The size of packets used for the test (in bytes)
Packet Count	The number of packets to be transmitted during the test
Timeout	How long after transmission should a packet be deemed lost (in seconds)
Packet Interval	Represents the interval (in milliseconds) between successive packet transmissions during the execution of the network test for a specific target.
Targets	By default, this is set to outlook.office.com. This test will emulate a network-level ping to this target only.
DD Frequency	Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time the test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enabled/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Avg network delay	Indicates the average delay between transmission of packet to the server and receipt of the response to the packet at the source.	Seconds	An increase in the value of this measure is a cause for concern. Given below are some common reasons for such an anomaly: The network between the server and the eG external agent is congested. When there is an increase in traffic on the interconnecting network, data transmission can slow down, thereby increasing communication latency. The quality of the network connection between the eG external agent and the server is sub-par. Poor signal quality, faulty transmission lines, etc. can result in an increase in packet loss and/or network latency. The server is overloaded. If the Exchange server on the cloud is very busy, it takes longer to respond to requests, and this will result in an increase in latency. There are problems with network routingbetween the server and the eG external agent. A faulty network router, routing loops, etc., can increase network latency. Check the detailed diagnosis of this test to track latency on the first three hops between the agent and the server. The latency to each hop can be used to determine which hop the problem lies in.
Min network delay	The minimum time between transmission of a packet and receipt of the response back from the server.	Seconds	A significant increase in the minimum round-trip time is often a sure sign of network congestion.
Packet loss	Indicates the percentage of packets lost during transmission from source to server and back.	Percent	A value close to 100% for this measure is a cause for concern. Given below are some common reasons for such an anomaly: The network between the server and the eG external agent is congested. When there is an increase in traffic on the interconnecting network, packets may be dropped. The quality of the network connection between the eG external agent and the server is sub-par. Poor signal quality, faulty transmission lines, etc. can result in an increase in packet loss and/or network latency. The server is overloaded. If the Exchange server on the cloud is very busy, it takes longer to respond to requests, and this will result in packet drops. There are problems with network routingbetween the server and the eG external agent. A faulty network router, routing loops, etc., can increase packet loss. Check the detailed diagnosis of this test to track latency on the first three hops between the agent and the server. The latency to each hop can be used to determine which hop the problem lies in.
Network availability	Indicates whether the network connection to the target server is available or not	Percent	A value of 100 indicates that the server is connected over the network. The value 0 indicates that the server is not connected. Typically, the value 100 corresponds to a Packet loss of 0. The value 0 for this measure could mean that the server is either down or too busy, or the interconnecting network is down.

The detailed diagnosis of the Packet loss measure provides a listing of routers that are on the path from the external agent to target server, and the delays on each hop. This information can be used to diagnose the hop(s) that could be causing excessive packet loss/delays.

Figure 1 : The detailed diagnosis of the Packet loss measure