The SharePoint 2010 Health System: A Quick Primer

SharePoint 2010 introduces the SharePoint Health framework, a formalized API and user interface for defining checks to be run against SharePoint farms and services and reports to be returned by these checks. The framework actually has its roots in the STSADM PreUpgradeCheck command introduced in SharePoint 2007 Service Pack 2. Checks performed by both tools utilize the Microsoft.SharePoint.Administration.Health APIs, although the 2007 version is more rudimentary than its 2010 descendant. Following is an introduction to the internals of these checks and a primer for administering them.

The SharePoint Health API centers on the SPHealthAnalysisRule abstract class, which serves as the base class for all health check rules. The key method of this class is Check() , which an implementer overrides to define the exact check to be performed and ultimately return a value from the SPHealthCheckStatus enum - Passed or Failed. When a check fails, a report is added to the Health Reports List in Central Administration with summary and explanatory information also defined within the specific implementation. SPRepairableHealthAnalysisRule derives from SPHealthAnalysisRule, adding the Repair() method to attempt repair of a detected problem.

SPHealthAnalysisRules are called and executed by internal methods defined in the SPHealthAnalyzer class, which are in turn called on schedule by jobs instantiated from the SPHealthAnalyzerJobDefinition type. A Health Analyzer job is configured for each permutation of schedule, scope, and host service declared in the farm; for example, there is one job for rules scoped to all servers and scheduled to run hourly, and a separate job for rules scoped to all servers and scheduled daily. These jobs query the farm Rules list, discussed below, for jobs matching their parameters, and then submit them for execution. You can list all Health Analyzer jobs currently scheduled on a farm by running the following PowerShell line:

Get-SPTimerJob | ? { $_.TypeName -match "Microsoft.SharePoint.Administration.Health.SPHealthAnalyzerJobDefinition" }

Rules and reports are stored in specialized SharePoint lists stored in the Central Administration site. SPHealthRulesList and SPHealthReportsList store references to rules and reports generated by those rules, respectively. Use the .Local static property on each class to return a reference to the farm-local instance of these lists. You can interact with the lists through the Monitoring page in Central Administration, or use PowerShell to return lists, tables, and reports on configured rules. For example, the following line returns information about each Rule defined for the farm, including its descriptive Title, the compiled Type it is based on, and whether or not it is enabled.

[Microsoft.SharePoint.Administration.Health.SPHealthRulesList]::Local.Items |
Select-Object @{ Label="Title"; Expression= { $_["Title"] } },
@{ Label="HealthRuleType"; Expression= { $_["HealthRuleType"] } },
@{ Label="HealthRuleCheckEnabled"; Expression= { $_["HealthRuleCheckEnabled"] } } |
Format-List

This line returns information about recent checks of severity Warning (2) or Error (1) which have failed:

[Microsoft.SharePoint.Administration.Health.SPHealthReportsList]::Local.Items |
Select-Object @{ Label= "Title"; Expression= { $_["Title"]} },
@{ Label= "HealthRuleType"; Expression= { $_["HealthRuleType"] } },
@{ Label= "HealthReportSeverity"; Expression= { $_["HealthReportSeverity"] } },
@{ Label= "HealthReportCategory"; Expression= { $_["HealthReportCategory"] } },
@{ Label= "HealthReportExplanation"; Expression= { $_["HealthReportExplanation"] } } |
? { $_.HealthReportSeverity -match "^[12]" }

The purpose of the SharePoint Health system is to provide preventative diagnostic information by running occasional low resource-cost tests on SharePoint farms, services, and servers. Many useful checks are provided on initial install, and with minimal effort you can add additional checks needed for your environment. Bet on the product team to also add rules in the future as demand or need arises.