Anders Dissing: September 2010

Tuesday, September 21, 2010

Health Analyzer Demo

What is health analyzer? This is the copy/pasta from msdns Overview of SharePoint Health Analyzer “SharePoint Health Analyzer is a feature in Microsoft SharePoint Foundation 2010 that enables administrators to schedule regular, automatic checks for potential configuration, performance, and usage problems in the server farm.”

So what we need to create a health analyzer rule?

Create a subclass of the SPHealthAnalysisRule or SPRepairableHealthAnalysisRule
Register the rule
Test/execute the rule

1) Create a subclass

In this demo I create a subclass of the SPRepairableHealthAnalysisRule and besides for implement the abstract properties from SPRepairableHealthAnalysisRule, I also override Check and Repair method.

The Check method is used to identify a single potential problem in the SharePoint environment. In this demo we are a test if a very important file exists on the c: drive.

public override SPHealthCheckStatus Check()
{
    FileInfo info = new FileInfo(@"c:\importantfile.txt");
    return info.Exists ? SPHealthCheckStatus.Passed : SPHealthCheckStatus.Failed;
}

Repair method is used to repair the problem that if the Check method return SPHealthCheckStatus.Failed. In the demo we just create the very important file on the c drive.

public override SPHealthRepairStatus Repair()
{
    try
    {
        if (Check().Equals(SPHealthCheckStatus.Failed))
        {
            FileInfo info = new FileInfo(@"c:\importantfile.txt");
            info.Create();
            return SPHealthRepairStatus.Succeeded;
        }
        else
        {
            return SPHealthRepairStatus.Succeeded;
        }
    }
    catch
    {
        //TODO: Log the error
        return SPHealthRepairStatus.Failed;
    }
}

2) Register the rule

Microsoft has a “How to: Create a Feature to Register a Health Rule” where they use a feature receiver to register rule with. But I’m big PowerShell fan, so it was naturally for me to create a simple PowerShell script to register and unregister.

Register PowerShell:

First we load the SharePoint DLL and my custom DLL. Then we call the static RegisterRules method with take the custom assembly as parameter. The RegisterRules return an IDictionary<Type, Exception>. We test if the IDictionary<Type, Exception> count is 0, if not, we display the exceptions by pipe the collection to the Format-List cmdlet.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
$assembly = [System.Reflection.Assembly]::LoadWithPartialName("HealthAnalyzerDemo")
$exceptions = [Microsoft.SharePoint.Administration.Health.SPHealthAnalyzer]::RegisterRules($assembly);
if($exceptions -ne $null)
{
	if($exceptions.Count -eq 0)
	{
		Write-Host "All rules were registered.";
	}
	else
	{
		$exceptions | fl
	}
}
$assembly = $null

Unregister PowerShell:

The only difference between the register script and the unregister script is, instead of call the RegisterRules method we call the UnRegisterRules.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
$assembly = [System.Reflection.Assembly]::LoadWithPartialName("HealthAnalyzerDemo")
$exceptions = [Microsoft.SharePoint.Administration.Health.SPHealthAnalyzer]::UnregisterRules($assembly);
if($exceptions -ne $null)
{
	if($exceptions.Count -eq 0)
	{
		Write-Host "All rules were unregistered.";
	}
	else
	{
		$exceptions | fl
	}
}
$assembly = $null

3) Test/execute the rule

Microsoft has a “How to: Test a Health Rule During Development” where they use a console application to test/execute the health rule. But this is so obviously a PowerShell thing :)

Execute rule PowerShell:

First we load the SharePoint DLL and my custom DLL. Then we create a new object of the rule class. Write the current return status from the Check method. Test if the status is equal to failed, if it is, we call the Repair method.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("HealthAnalyzerDemo") | Out-Null
$checkIfFileOnDiskExistRuleRepair = New-Object "HealthAnalyzerDemo.HealthAnalyzers.CheckIfFileOnDiskExistRuleRepair"
$status = $checkIfFileOnDiskExistRuleRepair.Check()
Write-Host "Status for"$checkIfFileOnDiskExistRuleRepair.Summary"is:"$status
if($status -eq [Microsoft.SharePoint.Administration.Health.SPHealthCheckStatus]::Failed)
{
	Write-Host "Calling the Repair method"	
	Write-Host "Result:" $checkIfFileOnDiskExistRuleRepair.Repair()
}

Summary:

It's really easy to make rules, that will give the It-pros a fight change to managed and maintain the SharePoint platform. Microsoft has some “Guidelines for Designing Health Rules”.

My demo code

Tuesday, September 14, 2010

Using GeSHi to syntax higligh

I just found this great tool to create syntax highligt in Windows Live Writer.

The tool is call GeSHi (Generic Syntax Highlighter) and has the following goals:

Support for a wide range of popular languages.
Easy to add a new language for highlighting.
Highly customisable output formats.

For more infomation:

Homepage: http://www.vcprojects.com/geshi/
Download & Discussion: http://www.vcprojects.com/geshi/download-discussion

Managing Custom Areas and Categories with Powershell

The patterns & practices SharePoint Guidance team has posted this article on how to manag custom areas and categories i SharePoint 2010 http://msdn.microsoft.com/en-us/library/ff798462.aspx. But all the examples is written in C# (and that’s a good thing Smile ) but I don’t want to have to use a feature receiver add my custom areas and categories, so I have create this demo PowerShell script, strongly inspire by the Microsoft article.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Practices.ServiceLocation") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Practices.SharePoint.Common") | Out-Null
 
#EventSeverity		Description
#	None			Indicates no event entries are written. 
#	ErrorCritical	Indicates a problem state that needs the immediate attention of an administrator.
#	Error			Indicates a problem state requiring attention by a site administrator. 
#	Warning			Indicates conditions that are not immediately significant but that may eventually cause failure.
#	Information		Contains noncritical information provided for the administrator.
#	Verbose
 
#TraceSeverity		Description
#	None			Writes no trace information to the trace log file.
#	Unexpected		Represents an unexpected code path and actions that should be monitored.
#	Monitorable		Represents an unusual code path and actions that should be monitored. 
#	High			Writes high-level detail to the trace log file.
#	Medium			Writes medium-level detail to the trace log file.
#	Verbose			Writes low-level detail to the trace log file.
 
#Create a List<DiagnosticsArea> to collect the Diagnostics Area
$areaCollection = New-Object 'System.Collections.Generic.List[Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea]'
 
#Add a DiagnosticsArea with the name Custom Area
$customArea = New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea' -ArgumentList "Custom Area"
#Add a DiagnosticsCategory, to the Custom Areas DiagnosticsCategories collection, with the name Business logic, EventSeverity set to Warning and TraceSeverity to Medium
$customArea.DiagnosticsCategories.Add((New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsCategory'("Business logic", ([Enum]::Parse([Microsoft.SharePoint.Administration.EventSeverity], 'Warning')), ([Enum]::Parse([Microsoft.SharePoint.Administration.TraceSeverity], 'Medium')))))
#Add a DiagnosticsCategory, to the Custom Areas DiagnosticsCategories collection, with the name Data layer, EventSeverity set to Error and TraceSeverity to Medium
$customArea.DiagnosticsCategories.Add((New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsCategory'("Data layer", ([Enum]::Parse([Microsoft.SharePoint.Administration.EventSeverity], 'Error')), ([Enum]::Parse([Microsoft.SharePoint.Administration.TraceSeverity], 'Medium')))))
#Add the Custom Area to the List<DiagnosticsArea> collection
$areaCollection.Add($customArea)
 
#Create a new DiagnosticsArea witht the name Test Area and adds it to the List<DiagnosticsArea> collection
$areaCollection.Add((New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea' -ArgumentList "Test Area"))
 
#Get a IConfigManager from the SharePointServiceLocator
$configManager =[Microsoft.Practices.SharePoint.Common.ServiceLocation.SharePointServiceLocator]::GetCurrent().GetInstance([Microsoft.Practices.SharePoint.Common.Configuration.IConfigManager])
 
#Create a new DiagnosticsAreaCollection with the IConfigManager as parameter
$configuredAreas = New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsAreaCollection' $configManager
 
#loop through the newly collection of diagnosticsareas
$areaCollection | % {
 
	#get the instance from the current configuration
	$existingArea = $configuredAreas[$_.Name]
 
	#if the area the is null, we add add the area from the List<DiagnosticsArea> collection
	#else we loop through the collection we got from current configuration
	if($existingArea -eq $null)
	{
		$configuredAreas.Add($_)
	}
	else
	{	
		#loop through the collection we got from current configuration
		$customArea.DiagnosticsCategories | % {
 
			#get the category instance from the $existingArea (DiagnosticsArea)
			$existingCategory = $existingArea.DiagnosticsCategories[$_.Name]
			#if the category is null, we add to the current configuration
			if($existingCategory -eq $null)
			{
				$existingArea.DiagnosticsCategories.Add($_);
			}
		}
	}
}
#save the current configuration
$configuredAreas.SaveConfiguration()

Anders Dissing