Heute war mal wieder so ein Tag, der einen die Haare raufen lässt: Geplant ist eine Migration von SharePoint 2013 nach SharePoint SE. Allerdings nicht Standard, sondern eine etwas ungewöhnlichere Konfiguration: Mit ADFS zur Authentifizierung gegen einige Active Directories im Hintergrund.

Hierzu ist u.A. eine spezielle Logon-Page implementiert worden, die je nach Client-IP auf ADFS- oder auf Windows-Authentication weiterleitet (vairam-svs/spautosignin). Damit sollen die Suchserver die Windows Authentication erhalten, was bei der alten Umgebung einwandfrei funktioniert hat. Nur diesmal eben nicht.

Das Phänomen: Der Crawler bricht der Crawl-Vorgang direkt mit einer Warnung ab:

The start address https://xxx.xxx.xx cannot be crawled. Context: Application ‘Search_Service_Application’, Catalog ‘Portal_Content’ Details: Item not crawled due to one of the following reasons: Preventive crawl rule; Specified content source hops/depth exceeded; URL has query string parameter; Required protocol handler not found; Preventive robots directive. (0x80040d07)

Die erste Idee …

Natürlich hatte ich erst mal die Authentifizierung im Sinn (“query string parameters”), bei der MySite hat alles funktioniert. Also den kompletten Code der Extension auseinander genommen, verändert, getestet usw. Dabei habe ich dann tatsächlich noch einen Fehler gefunden, der aber nicht relevant war: Der Redirect auf Windows Authentication funktionierte nicht, weil der DisplayName des ClaimsAuthenticationProviders unter bestimmten Umständen nicht “Windows Authentication”, sondern “Windows-Authentifizierung” enthält (*ächz*). Hat dann aber auch nichts am Fehler geändert.

… war ein Reinfall. Nächste, bitte!

Nächster Schritt: Alles Suchrelevante auf Verbose stellen und 300MB ULS-Log durchforsten. Auch nichts verwertbares. Aber irgendwas war komisch, im IIS-Log des WFE steht nur ein Request drin, nämlich auf die “robots.txt”. Und nun steht da drin “Disallow: /”!

Die Erklärung

SharePoint seit mindestens 2019 hat einen Mechanismus, der vor externen Crawlern schützen soll. Der wird automatisch aktiviert, wenn eine Web Application Anonymous Access aktiv hat. OK, meine WebApp hat das nicht, aber Windows Authentication und Claims Based Authentication gleichzeitig. Und CBA fällt auch in diese Kategorie (warum auch immer), daher generiert SharePoint dann automatisch dieses robots.txt, die vom Crawler selbst auch berücksichtigt wird.

Die Lösung

Die Deaktivierung der Funktion ist ganz einfach: XmlSitemap-Feature auf der obersten Site aktivieren:

Enable-SPFeature XmlSitemap -Url https://xxx.xxx.xx/

Das sorgt automatisch für eine Deaktivierung der Funktion und schon kann der Crawler wieder richtig crawlen.

Fazit: Es läuft wie immer, je schwerer nachvollziehbarer ein Problem und je mehr Aufwand man betreibt, um dem Problem auf den Pelz zu rücken, desto einfacher ist die Lösung am Ende …