SharePoint 2010 has a special hidden feature that ensures anonymous users with read access cannot view list and library form pages (i.e. “Forms/AllItems.aspx”). This feature is also known as SharePoint Lockdown mode and is automatically enabled on publishing sites. Especially on internet facing SharePoint sites, this feature ensures anonymous users stay out of certain area’s of a site. Since this feature is not automatically enabled on non-publishing sites, we need to find a way to check this features state on a regular basis. We could of course create a scheduled PowerShell script for this, but I like a more solid approach for this one.
More info on the Lockdown feature on this MSDN blog (MOSS 2007, but still applicable. By Ryan Duguid)
As we all know, SharePoint 2010 includes the Health Analyzer. This component uses a bunch of rules to check the farm for predefined issues and report on any found:
Image may be NSFW.
Clik here to view.
Fortunately, the rule set is extensible and we can add our custom ones. This is not a difficult task and a good candidate for our feature check!
To start we need to create a class that inherits from either the SPHealthAnalysisRule or SPRepairableHealthAnalysisRule. From these abstract classes we need to implement some string properties “Summary”, “Explanation” and “Remedy” (for explaining the issues found) and the “Category” and “ErrorLevel” properties. The “Check()” method performs the actual analysis so must be implemented too. If you want users to be able to execute a repair right from the Central Administration interface, the SPRepairableHealthAnalysisRule includes a “Repair()” method just for that. Finally we can implement the “AutomaticExecutionParameters” property to enable automatic Timer Job execution for our rule and in this case we do.
More detailed info on this on MSDN.
1. We start with an Empty SharePoint Project, and deploy it as a Farm Solution. We add our Central Administration web as our Site Url.
2. Next we add the class that inherits from SPHealthAnalysisRule and add the necessary using statements. After implementing the abstract class our rule looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Health;
namespace Blog.Examples.HealthAnalysisRule
{
public sealed class ViewFormPagesLockDown : SPHealthAnalysisRule
{
public override SPHealthCategory Category
{
get { throw new NotImplementedException(); }
}
public override SPHealthCheckStatus Check()
{
throw new NotImplementedException();
}
public override SPHealthCheckErrorLevel ErrorLevel
{
get { throw new NotImplementedException(); }
}
public override string Explanation
{
get { throw new NotImplementedException(); }
}
public override string Remedy
{
get { throw new NotImplementedException(); }
}
public override string Summary
{
get { throw new NotImplementedException(); }
}
}
}
3. Next we add our logic to the Check() method to do the actual testing. This method uses two helper functions, both included in the downloadable solution:
- isAnonymousEnabled: checks if the Web Application has Anonymous Access turned on.
- isFeatureActivated: checks if the FormPagesLockDown feature is activated.
The method itself stores any failing Web Application and a counter which we can use for reporting the issues.
public override SPHealthCheckStatus Check()
{
SPHealthCheckStatus ret = SPHealthCheckStatus.Passed;
SPFarm farm = SPFarm.Local;
foreach (SPService service in farm.Services)
{
if (service is SPWebService)
{
SPWebService webService = (SPWebService)service;
foreach (SPWebApplication webApp in webService.WebApplications)
{
if (isAnonymousEnabled(webApp))
{
foreach (SPSite site in webApp.Sites)
{
try
{
if (!isFeatureActivated(site, new Guid(FEATUREGUID)))
{
//Anonymous Access is enabled on the Web Application, but the ViewFormsLockDown feature was not found.
this.failingWebApplications.Add(webApp.Name, +1);
}
}
finally
{
if (site != null)
{
site.Dispose();
}
}
}
}
}
}
}
if (this.failingWebApplications.Count == 0)
{
ret = SPHealthCheckStatus.Passed;
}
else
{
ret = SPHealthCheckStatus.Failed;
}
return ret;
}
4. Finally implement the property “SPHealthAnalysisRuleAutomaticExecutionParameters” to enable automatic Timer Job schedules.
public override SPHealthAnalysisRuleAutomaticExecutionParameters AutomaticExecutionParameters
{
get
{
SPHealthAnalysisRuleAutomaticExecutionParameters retval = new SPHealthAnalysisRuleAutomaticExecutionParameters();
retval.Schedule = SPHealthCheckSchedule.Daily;
retval.Scope = SPHealthCheckScope.All;
retval.ServiceType = typeof(SPTimerService);
retval.RepairAutomatically = false;
return retval;
}
}
5. We now could build and deploy, but we would have to register the custom Health Analyzer rules through PowerShell. This process can be automated through SharePoint’s feature framework.
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
try
{
Assembly currentAssembly = Assembly.GetExecutingAssembly();
IDictionary exceptions = SPHealthAnalyzer.RegisterRules(currentAssembly);
}
catch (Exception ex)
{
throw new Exception("There was an error registering the Health Analysis rules: " + ex.Message);
}
}
If we compile and deploy, we can see our rule in action.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
If you want the rule to report any errors, make sure you enable anonymous access on a Web Application and disable the (hidden) feature. Of course we should use PowerShell for this:
Disable-SPFeature -Identity ViewFormPagesLockDown -Url http://public.demo.loc
Download the complete solution here.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
