Troubleshooting SharePoint Online Monitoring

Troubleshooting the Failure of eG Agent to Report Metrics on SharePoint Online

If the eG agent is unable to report metrics on SharePoint Online performance, then you may want to check whether/not the Microsoft Azure Active Directory Module for Windows PowerShell and the Microsoft Online Services Sign-in Assistant for IT Professionals RTW are properly installed on the eG agent host. To perform this check, do the following:

  1. On the eG agent host, click Start, and search for Windows Powershell ISE. Once it is found, run Windows Powershell ISE in the elevated mode.

  2. First, check if the PackageManagement module is installed properly. For that, type Install-Module, and see if the auto-complete feature of Windows automatically lists the command you were about to type (see Figure 11).

Figure 11 : Checking if the PackageManagement module has been installed properly

  1. If the command auto-completes, it means that the PackageManagement module has been installed properly. If the command does not auto-complete, then you can conclude that the PackageManagement module has not been installed on the eG agent host. In this case, first install this module on the eG agent host. You can download the installable from the URL: https://download.microsoft.com/download/C/4/1/C41378D4-7F41-4BBE-9D0D-0E4F98585C61/PackageManagement_x64.msi

  2. If you find that the PackageManagement module has been installed properly, proceed to check if the Microsoft Azure Active Directory Module for Windows PowerShell and the Microsoft Online Services Sign-in Assistant for IT Professionals RTW are properly installed on the eG agent host. To perform this check, with the Windows Powershell ISE in the elevated mode, type the following commands one after another:

    Connect-MSolService

    Get-MsolDomain

    Get-MsolGroup

  3. If these commands auto-complete - i.e., if Windows lists these commands even before you type them fully - you can conclude that the Microsoft Azure Active Directory Module for Windows PowerShell and the Microsoft Online Services Sign-in Assistant for IT Professionals RTW are properly installed on the eG agent host. On the other hand, if the commands do not auto-complete, then you must proceed to install both the aforesaid modules on the eG agent host. To know how to install, refer to the Pre-requisites for Monitoring Microsoft Office 365 Environments.

If the following tests do not report metrics, then check whether the SharePoint Online Management Shell has been installed and run on the eG agent:

  • Tenant Storage test
  • Health Score test
  • Site Collections test
  • Site Collection Health Checks
  • Site Connectivity test
  • File Operations test

To perform this check, run Windows PowerShell ISE in the elevated mode, and then type any of the following commands:

Connect-SPOService

Get-SPOSite

Get-SPOUser

If these commands auto-complete - i.e., if Windows lists these commands even before you type them fully - you can conclude that the SharePoint Online Management Shell is properly installed on the eG agent host. On the other hand, if the commands do not auto-complete, then you must proceed to install management shell on the eG agent host. To know how to install, refer to the Pre-requisites for Monitoring Microsoft Office 365 Environments.

Troubleshooting the Addition of eG Test-Related Files in the Preservation Hold Library of the SPO Root Site

Files end up in the Preservation Hold Library when SharePoint must retain them because of a retention policy applied to the site, a retention label applied to individual files, or eDiscovery holds. In all cases, files remain in the Preservation Hold Library until the hold applied by retention or eDiscovery lapses.

So, if you find thousands of eG test-related records in the Preservation Hold Library of the SPO root site, it can only mean that a retention policy / label has been applied to the eG test files in that site. By fine-tuning the retention policy/label, you can make sure that these files do not pile up and are instead automatically deleted from the Preservation Hold Library at regular intervals.

In order to figure out how the retention period is to be set, its important to understand how the Preservation Hold Library works.

Typically, when a user changes an item that's subject to retention from a retention policy or a retention label that marks items as a record, or deletes any item subject to retention, the original content is copied to the Preservation Hold library. This behavior lets the user change or delete the content in their app, while keeping a copy of the original for compliance reasons. This also helps you recover files deleted/changed inadvertently by a user.

A timer job periodically runs on the Preservation Hold library. For content that has been in the Preservation Hold library for more than 30 days, this job compares the content to all queries used by the retention settings for that content. Content that is older than their configured retention period and isn't awaiting disposition review is then deleted from the Preservation Hold library, and from the original location if it is still there. This timer job runs every seven days, which means that together with the minimal 30 days, it can take up to 37 days for content to be deleted from the Preservation Hold library.

This implies that for the retention settings configured under a policy/label to kick in and delete files from the library, it will take a minimum of 37 days. To make sure that obsolete/unimportant files are removed from the library not too long after the 37-daysperiod, make sure you configure your retention settings right.