Ein, auf den ersten Blick, merkwürdiges Phänomen bei der SharePoint 2010 Farm eines Kunden. Das Setup der Farm besteht aus zwei Web Front-end Servern, einem Application- und einem Crawl Server sowie drei FAST Servern.

In den Crawl Logs für eine bestimmte Content Source traten plötzlich mehrere hunderttausend Errors derselben Art auf. Ich versuchte als erstes, die in den Logs erwähnten URLs direkt vom Crawl Server aus im Browser zu erreichen. Keine der URLs war erreichbar, weder mit dem Farm Admin Account noch mit dem Content Access Account. Die erste Beunruhigung machte sich breit: Sind die Seiten nicht mehr erreichbar – aber warum gibt es noch keinen allgemeinen Aufschrei?

2013-09-11_130306

The SharePoint item being crawled returned an error when requesting data from the web service.

Was ist da los?
Daraufhin habe ich versucht den Status einer der nicht erreichbaren Site Collections vom Crawl Server aus in Powershell zu überprüfen.

2013-09-11_130327

Laut Powershell Resultate gibt es die entsprechenden Site Collections gar nicht (mehr). Jetzt begann es merkwürdig zu werden. Ein Blick in die Central Administration (läuft auf dem Application Server) zeigte nämlich ein völlig anderes Bild; gemäss Central Administration gab es die, von Powershell als nicht auffindbar gemeldeten, Site Collections sehr wohl. Doch eines hatten alle nicht auffindbaren Site Collections gemeinsam; sie waren in der gleichen Content Datenbank. Die Statusüberprüfung der Content DB via Central Administration zeigte diese als gestartet, und mit 13 Site Collections gefüllt, an. Soweit so gut, aber in den Resultaten von get-spspcontentdatabase (vom Crawl Server aus) fehlte genau diese Content DB.

2013-09-11_130335

Wie konnte das sein?
Die Central Administration zeigt im Grunde die grafisch aufbereiteten Ergebnisse, von Powershell Befehlen ausgeführt – auf dem Server, auf dem sie läuft – und ausgeführt mit dem Account, unter welchem sie betrieben wird.
Erste Vermutung: Gibt es vielleicht ein Berechtigungsproblem mit dem Farm Admin User und allenfalls dem Content Access Account auf dem SQL Server? Unwahrscheinlich, erstens gab es dort keine Änderungen. Warum sollte es nur eine Datenbank betreffen und müsste die Fehlermeldung dann nicht eher in die Richtung „Access denied“ gehen?

Kurze Gegenprobe: Gleicher Befehl auf dem Crawl Server unter dem Kontext des Farm Admin Accounts -> gleiches Ergebnis.
The content database could not be found.
Wenn aber die Central Administration diese Datenbank kennt, bleibt nur noch eine Möglichkeit offen: get-spspcontentdatabase vom Application Server, sowohl mit dem Farm Admin Account oder meinem Admin Account, wird die Datenbank als Resultat liefern. So war es auch. Gleiches galt auch für die beiden Web Front-end Server, was auch der Grund war, warum es keinen direkten Einfluss auf den End-User zu diesem Zeitpunkt hatte. Die Seiten waren durchgehend erreichbar.

Fazit
Es muss ein Server-spezifisches Problem sein.
Was für ein Problem hat der Crawler und wie kann es sein, dass es sich das nur in einer Datenbank äussert? Möglich wäre gewesen, dass die eine Content Datenbank mit einem anderen Connection String als alle anderen DBs zum SQL verbindet und es zum Beispiel bei den SQL Aliases einen lokal zerschossen hat, aber ein kurze Überprüfung hat diese Theorie ad acta gelegt.

  • Berechtigungen: OK
  • Verbindung SQL: OK
  • Auffällige Event in den Logs: Keine
  • Der obligatorische Serverneustart: Keine Veränderung
  • Internet Recherche: Keine schnellen Hinweise

Also musste es etwas sein, was für den Server so korrekt zu sein scheint, aber nicht mit der tatsächlichen Situation übereinstimmt: Ein Caching Problem.

Lösung
Jeder SharePoint Server speichert die Informationen der Configuration DB Objekte lokal im Configuration Cache, um die Anzahl Abfragen an die Config DB zu verringern. Dieser Cache kann aufgrund diverser Probleme (z.B. SQL Timeouts während einer Änderung in der Config DB) inkonsistent werden und bedarf eines manuellen Eingriffes, damit der Server sich den Cache neu aufbaut.

Kurzbeschreibung Vorgehensweise

  1. OWS TimerJob Service stoppen
  2. Backup der cache.ini unter Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
  3. Löschen aller XML Dateien unter Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
  4. Cache.ini mit dem Notepad öffnen und die dortige Zahl löschen und mit der Zahl 1 ersetzen.
  5. OWS TimerJob Service wieder starten, der TimerJob Config Refresh wird nun die gelöschten XML Files neu und als korrekten Abbild der Config DB erstellen.

Ergebnis
Nachdem der Objekt Cache auf dem Crawler neu aufgebaut wurde, war das Ergebnis der Powershell Cmdlets mit den anderen Servern wieder konsistent und auch die Crawl-Komponente konnte die Site Collections der vermissten Content DB wieder erfolgreich crawlen.

Weitere Informationen
Clear the SharePoint Configuration Cache
http://blogs.msdn.com/b/josrod/archive/2007/12/12/clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx

What Is a Configuration Cache and Why Do I Care About It?
http://blogs.technet.com/b/chad/archive/2009/11/25/tip-8_3a00_-what-is-a-configuration-cache-and-why-do-i-care-about-it_3f00_.aspx