Logon Status Test

Where Exchange Online is used, users need to be able to quickly and easily login to Exchange Online, so that they have on-emand access to their mailboxes on the cloud. If users are unable to login to Exchange Online when in need, their productivity is bound to get badly hit. Frequent logon issues may also force users to question the reliability of this cloud-based service. To ensure 'happy users', administrators should promptly capture logon issues, isolate its root cause, and rapidly initiate measures to address it. This is where the Logon Status test helps!

This test emulates a user logging into Exchange Online via the Office 365 REST API. The emulated logon process is as outlined below:

  1. The eG agent uses the Office 365 login credentials configured for the eG tests to login to the REST API.
  2. Once Azure AD successfully validates the credentials, the authentication step completes.
  3. After successful authentication, the eG agent hits the URL of the Exchange Domain configured for this test to complete the login.

The test reports the success/failure of each step of the emulated logon process. Additionally, the test also measures the time taken to complete every step. This way, the test enables administrators to proactively detect problems in a typical user logon to Office 365 and also pinpoints the exact step of the logon process where the bottleneck lies - in authentication? or when the domain-specific URL is hit?

This test is disabled by default. To enable the test, follow the Agents -> Tests -> Enable/Disable in the Admin tile menu, select Microsoft Exchange Online as the Component type, select Logon Status test from the Disabled Tests list, and click the << button to enable it.

Note:

Before enabling this test, make sure that the SharePoint Online Management Shell is installed on the eG agent host. You can download the installable for the SharePoint Online Management Shell from the URL: https://www.microsoft.com/en-in/download/details.aspx?id=35588. After downloading, use the installable to install the management shell on the eG agent host.

Target of the test : Exchange Online

Agent deploying the test : A remote agent

Outputs of the test : One set of results for the Office 365 tenant being monitored

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

O365 User Name, O365 Password, and Confirm Password

For execution, this test requires the privileges of an O365 user who is vested with the View-Only Audit Logs, View-Only Recipients, Mail Recipients, and Mail Import Export permissions. Configure the credentials of such a user against O365 User Name and O365 Password text boxes. Confirm the password by retyping it in the Confirm Password text box.

While you can use the credentials of any existing O365 user with the afore-said privileges, it is recommended that you create a special user for monitoring purposes using the Office 365 portal and use the credentials of that user here. To know how to create a new user using the Office 365 portal and assign the required privileges to that user, refer to Creating a New User in the Office 365 Portal.

Domain, Domain User Name, Domain Password, and Confirm Password

These parameters are applicable only if the eG agent needs to communicate with the Office 365 portal via a Proxy server.

In this case, in the Domain text box, specify the name of the Windows domain to which the eG agent host belongs. In the Domain User Name text box, mention the name of a valid domain user with login rights to the eG agent host. Provide the password of that user in the Domain Password text box and confirm that password by retyping it in the Confirm Password text box.

On the other hand, if the eG agent is not behind a Proxy server, then you need not disturb the default setting of these parameters. By default, these parameters are set to none.

Proxy Host, Proxy Port, Proxy User Name, and Proxy Password

These parameters are applicable only if the eG agent needs to communicate with the Office 365 portal via a Proxy server.

In this case, provide the IP/host name and port number of the Proxy server that the eG agent should use in the Proxy Host and Proxy Port parameters, respectively.

If the Proxy server requires authentication, then specify the credentials of a valid Proxy user against the Proxy User Name and Proxy Password text boxes. Confirm that password by retyping it in the Confirm Password text box. If the Proxy server does not require authentication, then specify none against the Proxy User Name, Proxy Password, and Confirm Password text boxes.

On the other hand, if the eG agent is not behind a Proxy server, then you need not disturb the default setting of any of the Proxy-related parameters. By default, these parameters are set to none.

Exchange Domain

Specify the Exchange Domain this test should connect to, when emulating the API logon process.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Authentication status

Indicates whether/not the login credentials were validated by Azure AD.

If the login credentials are successfully validated by Azure AD, then this measure will report the value Success. The value Failed is reported if authentication fails.

The numeric values that correspond to these measure values are as follows:

Measure Value Numeric Value
Success 1
Failed 0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the authentication status. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Authentication time

Indicates the time taken for the login credentials to be validated.

Seconds

An abnormally high value is a cause cor concern, as it indicates that authentication is slow.

If you suspect issues in the API logon process, then compare the value of this measure with that of the Login time measure to know where exactly the logon process is bottlenecked - is it during authentication - i.e., when login credentials are validated by Azure AD? or is it at login - i.e., when the domain-specific URL is hit?

Login status

Indicates whether/not the URL that this test hit returned a valid response page.

If this measure reports the value Success, it means that the test was able to connect to the SharePoint URL of the domain, successfully. On the other hand, if this measure reports the value Failed, it implies that the test could not connect to the SharePoint URL of the domain.

The numeric values that correspond to these measure values are as follows:

Measure Value Numeric Value
Success 1
Failed 0

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the login status. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Login time

Indicates the time taken to connect to the URL of the monitored domain.

Seconds

An abnormally high value is a cause cor concern, as it indicates that it is taking an unusually long time to connect to the URL.

If the Total login time reports an abnormally high value, then compare the value of this measure with that of the Authentication time measure to know where exactly the logon process is bottlenecked - is it at authentication - i.e., when login credentials are validated by Azure AD? or is it at login - i.e., when the domain-specific URL is hit?

Total login time

Indicates the total time taken to complete the API logon process.

Seconds

A very high value for this measure indicates a bottleneck in the API logon process. Under such circumstances, compare the value of the Authentication time and Login time measures to know what is delaying API logon - authentication? or connecting to the domain-specific URL?