So oder so ähnlich erscheinen bei manchen Installationen immer wieder Fehler im EventLog:

Machine 'SMPDEMO (SharePoint - www.smartpoint.at80(_LM_W3SVC_0133750053_ROOT))' failed ping validation and has been unavailable since '01.01.1900 00:00:01'

Eine temporäre Lösung war bist jetzt immer wieder das Request Management neu zu konfigurieren und zu hoffen das die Fehlermeldung nun endgültig das Weite sucht. Vorab gleich mal für alle leidgeplagten Kollegen - der Fehler verschwindet auch mit CU06/2013 nicht. Zum Glück jedoch hat schon jemand die Kernursache von diesem Problem gefunden - und zwar das am IIS (aus welchem Grund auch immer) die Methode "SPPING" nicht registriert wurde. Somit versteht jeder SharePoint Frontend nur Bahnhof wenn sie sich gegenseitig abfragen ;)

Also folgende Befehle (zum registrieren und testen) auf allen Frontends ausführen - und schwupps, keine Fehlermeldung mehr im Request Management.

$url = "http://smpdemo"
$myReq = [System.Net.HttpWebRequest]::Create($url)
$myReq.Method = "SPPING";
$response = $myReq.GetResponse();
$response.StatusCode

Import-Module WebAdministration
add-WebConfiguration /system.webserver/handlers "IIS:\" -value @{
name = "SPPINGVerbHandler"
verb = "SPPING"
path = "*"
modules = "ProtocolSupportModule"
requireAccess = "None"
}


Und bitte nicht vergessen die PowerShell als Administrator auszuführen - sonst gibts immer wieder unschöne Fehlermeldungen ;)

Over and Out

Endlich hat es auch die neue Stable Version von b2evolution auf coder.at geschafft. Einige Knackpunkte der alten Version sollen nun behoben sein - und so freut es mich - das viele meiner alten Postings über b2evo wohl als obsolete anzusehen sind. Welche das im Detail sind, gilt es noch rauszufinden ;)

Over and Out

Nach einigen doch relativ langen Sitzungen rund um das Thema SharePoint und Two Way Trusts habe ich nun einen kleinen Punkt gefunden den man mal gerne übersieht. Vorallem wenn man SharePoint mit gutem Account- und Rechtekonzept platziert. Vorallem in Migrationsszenarien kommt es gerne mal vor, das man den neuen SharePoint in einer neuen Domäne installiert. Wenn man nun den Effekt hat, das man trotz fehlerfreier Konfiguration nach wie vor keine Benutzer aus der alten Domäne über den People Picker findet - und somit auch nicht berechtigen kann, sei folgender Link wärmstens ans Herz gelegt. Was so eine kleine Berechtigung doch für ein großes Dilemma bei einer Testmigration auslösen kann ;)

http://technet.microsoft.com/en-us/library/cc816733%28v=ws.10%29.aspx

Over and out

Es kann schon mal passieren das man eine SharePoint Installation nicht mit dem Installationswizard macht (in meinem Fall ist jede Installation ohne den Wizard ;)). Hier gibt es aber einige Fallen, auf die ich mit diesem Post grob aufmerksam machen will. Einige Service Applikation können z.b. nicht über die grafische Oberfläche der Zentralverwaltung angelegt werden. Diese sind aber für andere Service Applications jedoch relativ wichtig - darum bleibt uns hier auch die PowerShell nicht verwehrt ;)

Session State Service Application

$sa = New-SPStateServiceApplication -Name "Session State Service Application"
New-SPStateServiceDatabase -Name "SharePoint_SessionStateServiceApplication" -ServiceApplication $sa
New-SPStateServiceApplicationProxy -Name "Session State Service Application" -ServiceApplication $sa -DefaultProxyGroup

Usage And Health Data Collection Service Application

Set-SPUsageService -LoggingEnabled 1 -UsageLogLocation "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS" -UsageLogMaxSpaceGB 5
New-SPUsageApplication -Name "Usage and Health Data Collection Service Application" -DatabaseName "SharePoint_UsageAndHealthDataCollectionServiceApplication" -UsageService (Get-SPUsageService)

Subscription Settings Service Application

$sa = New-SPSubscriptionSettingsServiceApplication –ApplicationPool "SharePoint Application Pool" –Name "Subscription Settings Service Application" –DatabaseName "SharePoint_SubscriptionSettingsServiceApplication"
New-SPSubscriptionSettingsServiceApplicationProxy -Name "Subscription Settings Service Application" –ServiceApplication $sa -DefaultProxyGroup

Session State Database

Enable-SPSessionStateService –DatabaseName "SharePoint_SessionStateDatabase" –SessionTimeout 120

Search Service Application (auch wenn es durch das UI einfacher geht - aber saubere DB Namen sind mir hier lieber)

$SPAppPool = Get-SPServiceApplicationPool -Identity "SharePoint Application Pool" -ErrorAction SilentlyContinue

if (!$SPAppPool)
{
    $spAppPool = New-SPServiceApplicationPool -Name "SharePoint Application Pool" -Account "smartpointdev\svcspapp" -Verbose
}

Start-SPEnterpriseSearchServiceInstance ((Get-ChildItem env:computername).value) -ErrorAction SilentlyContinue
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance ((Get-ChildItem env:computername).value) -ErrorAction SilentlyContinue
$ServiceApplication = Get-SPEnterpriseSearchServiceApplication -Identity "Search Service Application" -ErrorAction SilentlyContinue

if (!$ServiceApplication)
{
    $ServiceApplication = New-SPEnterpriseSearchServiceApplication -Partitioned -Name "Search Service Application" -ApplicationPool $spAppPool.Name -DatabaseName "SharePoint_SearchServiceApplication"
}

$Proxy = Get-SPEnterpriseSearchServiceApplicationProxy -Identity "Search Service Application" -ErrorAction SilentlyContinue
if (!$Proxy)
{
    New-SPEnterpriseSearchServiceApplicationProxy -Partitioned -Name "Search Service Application" -SearchApplication $ServiceApplication
}

$ServiceApplication.ActiveTopology

$clone = $ServiceApplication.ActiveTopology.Clone()
$SSI = Get-SPEnterpriseSearchServiceInstance -local
New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $SSI
New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $SSI
New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $SSI
New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $SSI

Remove-Item -Recurse -Force -LiteralPath "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\INDEX" -ErrorAction SilentlyContinue
mkdir -Path "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\INDEX" -Force

New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $SSI -RootDirectory "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\INDEX"
New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $SSI
$clone.Activate()

Over and Out

Ich bin mir zwar nicht wirklich im klaren warum ich der einziger b2evo User weltweit bin, der dieses Problem hat - aber meine Blog Postings scheinen ein riesen Problem mit den "CodeBlock" Funktionen des gleichnamigen Plugins zu haben. Zum Beispiel funktioniert der Zeilenwechsel nicht - und somit sehen diese Blöcke mehr als fragwürdig aus.

Nach einer kleinen Recherche habe ich herausgefunden das meine Blog-Postings alle ein "\r" anstelle eine "\n" für den Zeilenumbruch verwenden. Das finde ich auch sehr in Ordnung - aber das CodeBlock Plugin hat damit so seine Probleme - denn das ist für "\n" ausgelegt. Also folgende Anpassungen solltet ihr durchführen wenn ihr ein vergleichbares Problem mit b2evo habt:

Änderungen in:
b2evo/plugins/code_highlight_plugin/_code_highlight.plugin.php

Code:
str_replace("\r", '', str_replace("[br]", $line_seperator, str_replace("[br]", $line_seperator, $block))));

Änderungen in:
b2evo/plugins/code_highlight_plugin/amcode.css

Code:
td.amc_line { padding:0 5px; font-size:0; width:auto; vertical-align: top; padding-top: 3px; }

Änderungen in:
b2evo/plugins/code_highlight_plugin/highlighters/php.highlighter.php

Code:
trim(str_replace("[br]", "\n", str_replace("[br]", "\n", $block))))."\n".'*/', true)

Änderungen in:
b2evo/plugins/code_highlight_plugin/highlighters/shell.highlighter.php

Code:
trim(str_replace("[br]", "\n", str_replace("[br]", "\n", $block))))."\n".'*/', true)

Over and Out