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?

  1. Create a subclass of the SPHealthAnalysisRule or SPRepairableHealthAnalysisRule
  2. Register the rule
  3. 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.

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

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.

  1. public override SPHealthRepairStatus Repair()
  2. {
  3. try
  4. {
  5. if (Check().Equals(SPHealthCheckStatus.Failed))
  6. {
  7. FileInfo info = new FileInfo(@"c:\importantfile.txt");
  8. info.Create();
  9. return SPHealthRepairStatus.Succeeded;
  10. }
  11. else
  12. {
  13. return SPHealthRepairStatus.Succeeded;
  14. }
  15. }
  16. catch
  17. {
  18. //TODO: Log the error
  19. return SPHealthRepairStatus.Failed;
  20. }
  21. }

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.

  1. [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
  2. $assembly = [System.Reflection.Assembly]::LoadWithPartialName("HealthAnalyzerDemo")
  3. $exceptions = [Microsoft.SharePoint.Administration.Health.SPHealthAnalyzer]::RegisterRules($assembly);
  4. if($exceptions -ne $null)
  5. {
  6. if($exceptions.Count -eq 0)
  7. {
  8. Write-Host "All rules were registered.";
  9. }
  10. else
  11. {
  12. $exceptions | fl
  13. }
  14. }
  15. $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.

  1. [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | Out-Null
  2. $assembly = [System.Reflection.Assembly]::LoadWithPartialName("HealthAnalyzerDemo")
  3. $exceptions = [Microsoft.SharePoint.Administration.Health.SPHealthAnalyzer]::UnregisterRules($assembly);
  4. if($exceptions -ne $null)
  5. {
  6. if($exceptions.Count -eq 0)
  7. {
  8. Write-Host "All rules were unregistered.";
  9. }
  10. else
  11. {
  12. $exceptions | fl
  13. }
  14. }
  15. $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.

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


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:

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

For more infomation:


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.

  1. [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Practices.ServiceLocation") | Out-Null
  2. [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Practices.SharePoint.Common") | Out-Null
  4. #EventSeverity Description
  5. # None Indicates no event entries are written.
  6. # ErrorCritical Indicates a problem state that needs the immediate attention of an administrator.
  7. # Error Indicates a problem state requiring attention by a site administrator.
  8. # Warning Indicates conditions that are not immediately significant but that may eventually cause failure.
  9. # Information Contains noncritical information provided for the administrator.
  10. # Verbose
  12. #TraceSeverity Description
  13. # None Writes no trace information to the trace log file.
  14. # Unexpected Represents an unexpected code path and actions that should be monitored.
  15. # Monitorable Represents an unusual code path and actions that should be monitored.
  16. # High Writes high-level detail to the trace log file.
  17. # Medium Writes medium-level detail to the trace log file.
  18. # Verbose Writes low-level detail to the trace log file.
  20. #Create a List<DiagnosticsArea> to collect the Diagnostics Area
  21. $areaCollection = New-Object 'System.Collections.Generic.List[Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea]'
  23. #Add a DiagnosticsArea with the name Custom Area
  24. $customArea = New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea' -ArgumentList "Custom Area"
  25. #Add a DiagnosticsCategory, to the Custom Areas DiagnosticsCategories collection, with the name Business logic, EventSeverity set to Warning and TraceSeverity to Medium
  26. $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')))))
  27. #Add a DiagnosticsCategory, to the Custom Areas DiagnosticsCategories collection, with the name Data layer, EventSeverity set to Error and TraceSeverity to Medium
  28. $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')))))
  29. #Add the Custom Area to the List<DiagnosticsArea> collection
  30. $areaCollection.Add($customArea)
  32. #Create a new DiagnosticsArea witht the name Test Area and adds it to the List<DiagnosticsArea> collection
  33. $areaCollection.Add((New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsArea' -ArgumentList "Test Area"))
  35. #Get a IConfigManager from the SharePointServiceLocator
  36. $configManager =[Microsoft.Practices.SharePoint.Common.ServiceLocation.SharePointServiceLocator]::GetCurrent().GetInstance([Microsoft.Practices.SharePoint.Common.Configuration.IConfigManager])
  38. #Create a new DiagnosticsAreaCollection with the IConfigManager as parameter
  39. $configuredAreas = New-Object 'Microsoft.Practices.SharePoint.Common.Logging.DiagnosticsAreaCollection' $configManager
  41. #loop through the newly collection of diagnosticsareas
  42. $areaCollection | % {
  44. #get the instance from the current configuration
  45. $existingArea = $configuredAreas[$_.Name]
  47. #if the area the is null, we add add the area from the List<DiagnosticsArea> collection
  48. #else we loop through the collection we got from current configuration
  49. if($existingArea -eq $null)
  50. {
  51. $configuredAreas.Add($_)
  52. }
  53. else
  54. {
  55. #loop through the collection we got from current configuration
  56. $customArea.DiagnosticsCategories | % {
  58. #get the category instance from the $existingArea (DiagnosticsArea)
  59. $existingCategory = $existingArea.DiagnosticsCategories[$_.Name]
  60. #if the category is null, we add to the current configuration
  61. if($existingCategory -eq $null)
  62. {
  63. $existingArea.DiagnosticsCategories.Add($_);
  64. }
  65. }
  66. }
  67. }
  68. #save the current configuration
  69. $configuredAreas.SaveConfiguration()

The demo code.