Site Collection Health Checks Test

SharePoint Online includes a set of rules that you can run against a site collection to verify that it is working as expected. These rules are part of the site collection health checks.

You run the health checks manually to prepare for an upgrade. In addition, the health checks are run automatically in repair mode when you start to upgrade a site collection.

The site collection health checker includes the following rules:

Rule Name

Description

Conflicting Content Types

This rule checks for conflicts between existing content types and content types that are created when you upgrade the site. A conflict occurs when both content types have the same name.

Customized Files

This rule checks for any files that were customized (or unghosted) in the site collection or subsites. When run in repair mode, it can reset the page to the default (reghost the file).

Missing Galleries

This rule checks for all default galleries and reports if any are missing from the site collection or subsites.

Missing Parent Content Types

This rule checks for missing parent content types. If a missing parent content type is found, you can either delete the orphaned content type or associate the orphaned content type with a different parent content type.

Missing Site Templates

This rule checks to make sure that the template the site is based on is available and reports if any elements are missing.

Unsupported Language Pack References

This rule checks to make sure that the language packs that are used by the site collection exist and are referenced correctly by the site collection.

Unsupported MUI References

This rule checks to make sure that the multi-user interface elements that are used by the site collection exist and are referenced correctly.

Whenever one/more of the aforesaid health checks are run - whether manually or automatically - an administrator needs to know which health checks were run, on which site collection they were run, which of these checks passed, and which ones failed. This way, administrators can identify the unhealthy site collections or collections that are not upgrade-ready. Additionally, the knowledge of rules that failed will enable administrators initiate measures to investigate the reasons for the failure and fix them, so that they can then confidently proceed to upgrade the site collections. This is what the Site Collection Health Checks test helps administrators achieve!

This test automatically discovers the site collections on which health checks are run, and reports the count of rules that passed, rules that failed with warnings, and rules that failed with errors. This will point administrators to unhealthy site collections or site collections that are not upgrade-ready. Using the detailed diagnostics provided by the test, administrators can accurately identify the precise rules that passed and failed, and can thus easily troubleshoot the failures.

Target of the test : Microsoft SharePoint Online

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each site collection

First-level descriptor: Site collection URL

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 has been assigned the Service support admin and SharePoint admin roles and is vested with the View-Only Audit Logs permission. 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.

O365 Domain

To have a personalized business email address, team site address, or even an account name, you set up a domain name with Office 365. A domain is a unique name that appears after the @ sign in email addresses, and after www. in web addresses. It typically takes the form of your organization's name and a standard Internet suffix, such as yourbusiness.com or stateuniversity.edu. Office 365 gives you an initial domain name to use. By default, this will be of the format: *.onmicrosoft.com - eg., abc.onmicrosoft.com. To enable this test to pull metrics, you need to configure the test with the name of this initial domain. Therefore, configure the O365 Domain parameter with the name of the initial domain. To know what is your Office 365 initial domain name, do the following:

  1. Log on to the Microsoft Office 365 Online Portal using an administrative account.
  2. Under Management, click on Domains.
  3. The initial domain should be listed with a name ending with .onmicrosoft.com.

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.

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

Passed

Indicates the number of health checks run on this site collection that passed.

Number

Use the detailed diagnosis of this measure to know which rules passed.

Failed warnings

Indicates the number of health checks run on this site collection that failed with warnings.

Number

Use the detailed diagnosis of this measure to know which rules failed with warnings.

Failed errors

Indicates the number of health checks run on this site collection that failed due to errors.

Number

Use the detailed diagnosis of this measure to know which rules failed owing to errors.

The detailed diagnosis of the Passed measure reveals the names and IDs of the rules that passed

Figure 3 : The detailed diagnosis of the Passed measure

The detailed diagnosis of the Failed warnings measure lists the names and IDs of rules that failed with warnings. The reason for the failure will have to be investigated.

Figure 4 : The detailed diagnosis of the Failed warnings measure