Custom Health Rules in SharePoint 2010

by Scosby Monday, April 26, 2010

You can build your own health rules in MSF or MSS 2010. SharePoint 2010 includes a new, integrated health analysis tool that is named SharePoint Health Analyzer that enables you to check for potential configuration, performance, and usage problems.  A health rule runs a test and returns a status that tells you the outcome of the test. When any rule fails, the status is written to the Health Reports list in SharePoint Foundation 2010 and to the Windows Event log. The SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list on the Review problems and solutions page in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem. You can also open the rule that raised the alert and change its settings.

Let's take a breif walk through on the MSDN example, so I can point out how to use the new VS2010 SharePoint Project to simplify the deployment of your new custom health rule. Of course, nothing is free and there are always unintended consequences. So be sure to review the guidelines for desiging health rules before you get started. The following screen shots will illustrate the key points for building your new rule and the output you can expect in Central Administration.

You can follow along with developing and deploying a custom health rule on MSDN.

When creating your health role, derive from the abstract base class SPHealthAnalysisRule and implement the abstract methods. The only thing I will note here, is to simplify your first rule and make the SPHealthAnalysisRule.Check override with the following:

        public override SPHealthCheckStatus Check()
        {
            //Implement test logic...
            return SPHealthCheckStatus.Failed;
        }

In order to deploy our new health rule, be sure to create a class derived from SPFeatureReceiver and follow the MSDN example for the FeatureActivated and FeatureDeactiving method overrides. It is ok for you to declare your feature receiver in the same assembly as your health rule, you can always change this later. Once you have completed this task, build the feature receiver and open it with Redgate's Reflector so you can obtain the assembly full name. Write this down for later.

Next, let's add an empty SharePoint project to our solution. Once it's created, add a feature and let's wire in our assembly containing our FeatureReceiver and custom Health Rule.

If we double click our Package.package file (not shown above), we can add our assembly to the GAC in the "Advanced" tab. Choose to add an assembly from project output, as shown in the following 2 screens:

 

Now we can edit our Feature by double clicking it in the solution explorer. In the properties window, we need to declare the receiver assembly and class using the assembly full name from Reflector.

 

Be sure that you follow along with the MSDN example and set your scope and always force install options accordingly (as shown above).

Next, we can set the SharePoint project as our startup project for our Visual Studio solution and hit "F5" to deploy our new feature and have it run the overrides in the FeatureReceiver class.

Now we can visit the Monitoring section in Central Administration to see our new health rule:

We can now run it from the "View Item" menu and see what happens:

 

After a moment, we should see the health analyzer ribbon on the Central Administration home page:

 If we click on "view these issues", we see a nice summary of what's going on in our farm:

 

Finally, we can check the Windows Event Log to see how the Health Analyzer reports our health rule:

Good luck with creating your own Health Rules and be sure to follow the above mentioned guidelines!

   

Tags: ,

IT | Programming

blog comments powered by Disqus