MOSS 2007 Suche und unerwarteter Fehler.

Ich bin ein Typ, der unheimlich gerne selbst die Lösung findet. Hier kann ich mich geradezu verzetteln, rein verrennen. Nicht immer günstig. Zwei Tage habe ich nun verzweifelt geforscht, gefühlt das halbe Internet durchforstet, um eine Lösung für das Problem einer “nicht funktionierenden” Suche auf MOSS 2007 zu finden, die zu einem zunächst “unerwarteten Fehler führte”. Ein typisches Erlebnis aus meiner Hassliebe zu Sharepoint.

Was ist ein unerwarteter Fehler?

MOSS 2007 ist nicht unbedingt auskunftsfreudig, wenn es um Fehler geht. Hier sind zunächst einige Einstellungen in der Datei  web.config nötig, die man im entsprechenden virtuellen Verzeichnis findet. Standardmäßig ist dies C:/Inetpub/wwwroot/wss/VirtualDirectories/80

Sobald man customErrors mode=”true” customErrors mode=”OFF” sowie SafeMode callStack=”true” gesetzt hat, wird statt der lapidaren Meldung “es ist ein unerwarteter Fehler aufgetreten” nun eine detaillierte ASP Fehlermeldung angezeigt.

In meinem Fall lieferte das System den Fehler Zugriff auf ein NullObjekt: Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnLoad
Das Problem ist bekannt. Ich bin kein Einzelfall. Das ist schon mal schön. Die Lösung, so konnte man googlen, wäre, das WebPart zu löschen und neu hinzuzufügen. Sharepoint Designer sei Dank, alles easy going. Auch MOSS 2007 schlug dies vor. Dies führte jedoch zu einer weiteren, mindestens genauso lapidaren Fehlermeldung, diesmal als Dialogfeld: Es seien Fehler aufgetreten, das gewünschte Webpart könne nicht hinzugefügt werden.

Lösungsansätze für dieses oder ähnliche Probleme

Das eigentliche Problem bei der Lösungsfindung ist, dass ähnliche Symptome auf unterschiedliche Probleme zurückzuführen sind und damit unterschiedlicher Therapien bedürfen.

Ein Zwischenschritt war  die Frage nach Berechtigungen, bereits für den Crawlprozess. Es gibt idealerweise zwei Konten, die für die Suche zuständig sind: ein Dienstkonto für den Suchdienst und ein Zugriffskonto für den Suchdienst. Beide dürfen keine Administratorenrechte auf dem Portal haben. Eine Sache, die es zu überprüfen gilt, sollte es hier zu Fehlermeldungen kommen, ist die Authentifizierungsmethode innerhalb der Webanwendung.

Ein weiterer Schritt ist die Überprüfung der Rechte am Komponentendienst oSearch sowohl für das Dienst als auch das Zugriffskonto.

Die Lösung, die nun letztendlich zum Erfolg führte, war eine andere, aber sie war konsequent, - sobald man den passenden Knopf kennt. Die Suche funktionierte nämlich, nachdem sämtliche Rechteprobleme gelöst waren, auf dem Server selbst problemlos.

Der Server kennt von jeher nur seinen Kurznamen, ich nenne ihn mal server1. Von außen zugänglich ist der Server aber natürlich nicht durch seinen Kurznamen sondern über server1.meineDomain.de und noch schlimmer über server1.ast1.ast2.meineDomain.de. Dazwischen hängt noch ein DNS Server ohne DHCP (DNS also hier nur als nötiges Übel für eine notwendige und funktionierende Active Directory Rolle) - so dass die Konstruktion nur dann funktioniert, wenn jener Server als DNS Server fest eingetragen wird, damit die Namensauflösung denn auch wirklich funktioniert.

Es war nun nur noch nötig, die alternativen Zugriffszuordnungen anzupassen. Zu finden in der Zentraladministration -> Vorgänge -> Globale Konfiguration. Simpel eigentlich, wenn man weiß wie und wo.

Okay…

mögt Ihr alten Sharepoint-Hasen sagen, das sei ja wohl total klar gewesen. Ich Autodidakt sehe das etwas anders. Die Fehlermeldungen, die mir unterwegs in kleinen Variationen unterkamen, ließen auf alles mögliche schließen und Google half mit tollen Tipps bis zu hin “Neuinstallation”.

Kürzlich habe ich via Joe Oleson gelesen, was man als Sharepoint Profi denn so alles müsse. Vom Profi bin ich weit entfernt, auch ein Zertifkat habe ich leider nicht, - wäre dann wohl doch mal eine Investition? Trotzdem habe ich mich gefreut, dass ich die genannte Liste dann wenigstens in Grundzügen abdecken kann und vom Meisten wenigstens schon mal was gehört habe. In die tieferen Weihen eines Active Directory oder eines DNS Servers einzusteigen, das war allerdings bisher nicht der Plan. Meine Stärken liegen dann wie immer eher im Konzept.

Viele der Lösungsansätze führen mich in die Untiefen nicht nur der Sharepoint Maschinerie sondern auch des Windows Servers und vielfach ahne ich nur noch, was ich da gerade tun muss, lese kurz nach und bin dann wieder einen Schritt weiter - manchmal auch mit der Ahnung, dass, gerade wenn es um Berechtigungen geht, das ein oder andere ein Risiko darstellt und daher nicht das Mittel der Wahl ist.

Wenn ich mich dann so durchgehangelt und durchgebissen habe, immer am Rand der Verzweiflung und zum Schluss natürlich auch ein bisschen mit Stolz erfüllt, dann frage ich mich, was ich denn eigentlich noch alles können sollte, um das Gefühl zu haben, dieses Monster (ja, so empfinde ich es manchmal) wirklich im Griff zu haben.

Wahrscheinlich erfreuen sich Troubleshooting Kurse höchster Beliebtheit. Denn allein von einer Fehlermeldung annähernd in die richtige Richtung zu kommen, gestaltet sich gelegentlich als einigermaßen tricky. Was ich nun alles im Einzelnen ausprobiert habe, kann ich, inklusive der vielen VM Ware Snapshots eigentlich kaum mehr reproduzieren, obwohl ich jeden Schritt dokumentiert habe.

In diesem Sinne haben sich der Computerhund und ich erstmal einen ausgedehnten Spaziergang verdient, um die nächsten, hoffentlich weniger mit Fallstricken bedachten Schritte zu überdenken…

 

5 Antworten zum Beitrag “MOSS 2007 Suche und unerwarteter Fehler.”

  1. am 18 Feb 09 um 11:43 meint

    Max

    True bei Customerrors geht aber nicht :

    Quelle:

  2. am 18 Feb 09 um 11:45 meint

    Max

    customErrors mode=”On|Off|RemoteOnly”

  3. am 18 Feb 09 um 11:48 meint

    Anne-Kathrin

    Danke für den Hinweis, es muss natürlich ON heißen…! Habs korrigiert

  4. am 18 Feb 09 um 12:54 meint

    Max

    Nein es muss OFF heissen, standardmäßig ist es auf ON :-)

    Off:
    Verwirrend —- Specifies that custom errors are disabled.
    Hier stehts —- The detailed ASP.NET errors are shown to the remote clients and to the local host.

    On:
    Verwirrend —- On Specifies that custom errors are enabled.
    Hier stehts —- If no defaultRedirect attribute is specified, users see a GENERIC ERROR. The custom errors are shown to the remote clients and to the local host.

  5. am 18 Feb 09 um 12:59 meint

    Anne-Kathrin

    Nein, das finde ich nicht verwirrend. Denn Custom bedeutet wohl in dem Fall “angepasst an die Nutzungssituation”.

    Verwirrend ist dann wohl nur etwas, das ich mal so nebenbei hier unbedacht zu korrigieren versuche… Vielen Dank :-)))

Auch was dazu sagen?