none
Suchanwendungstopologie in SharePoint Server 2019 RRS feed

  • Frage

  • Ich habe testweise einen SharePoint Server 2019 auf einem Domänencontroller als Einzelserver aufgesetzt (Windows Server 2019, AMD, 8 logische Kerne á 4,4 GHz, 32 GB RAM, 1,3 TB freier Festplattenspeicher, Sprachpaket Deutsch, ebenfalls mit installiert und einwandfrei laufend der Exchange Server 2019). Läuft soweit gut. Bei der Erstellung der Suchdienstanwendung gerät das Ganze allerdings ins Stocken. Hierfür habe ich drei separate verwaltete AD-Konten angelegt, worauf die Suchanwendungstopologie allerdings in keinster Weise aktiviert wurde (warum auch immer). Ich habe daher sowohl als Suchdienstkonto als auch für die beiden Anwendungspools jeweils das Admin-Konto genommen (was ja in SharePoint 2010 jedenfalls tadellos funktioniert hat). Die Suchanwendungstopologie wird dann zwar erstellt, jedoch nie vollständig. Schon für die Indexpartition 0 wird in PowerShell die Meldung "node not found" angezeigt, in der Zentraladministration kommt als Status unter Suchanwendungstopologie das rote Kreuz. Dabei bin ich auf zwei Fehler gestoßen:

    1. Unter C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Nodes\XXXXXX\IndexComponent1 findet sich nur eine leere Node.config. In der Log-File wird natürlich auf diesen Fehler hingewiesen. Ich habe dann testweise die Node.config aus dem Ordner \QueryProcessingComponent1 rüberkopiert, womit zumindest diese Fehlermeldung umgangen wird.

    2. Die microsoft.ceres.coreservices.node.dll soll (z.B.) aus dem Ordner \Applications\Shared geladen werden, der aber nicht vorhanden ist. Ich habe diese Unterordner also unter C:\Program Files\Microsoft Office Servers\16.0\Search\Runtime\1.0\Applications\Shared erstellt und die microsoft.ceres.coreservices.node.dll dort hineinkopiert, die auch geladen wird. Ersatzweise kann man auch die (fehlenden) Unterordner \Microsoft.Ceres.CoreServices.Node\v4.0_16.0.0.0__71e9bce111e9429c erstellen unter C:\Windows\Microsoft.NET\assembly\GAC_64\Microsoft.Ceres.CoreServices.Node\v4.0_16.0.0.0__71e9bce111e9429c und es dort hineinkopieren, was ebenfalls geladen wird.

    Nunmehr ist die Indexpartition "nur noch" degraded, unter Status in der PowerShell heißt es dann:
    List of degraded components: Microsoft.Ceres.SearchCore.Query.MarsLookupComponent.MarsLookupComponent; Microsoft.Ceres.ContentEngine.Operators.BuiltIn.CieOperatorSource; Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ExternalEvaluatorSource; IndexComponent1.EvaluationEngine; IndexComponent1.CIRepository; IndexComponent1.CIEComponent; IndexComponent1.ImsQueryInternalComponent; IndexComponent1.InteractionEngineComponent; IndexComponent1.QueryPipelineFunctionsSource; IndexComponent1.RemoteSharepointComponent; IndexComponent1.QueryPipelineComponent;

    Lediglich der Crawler hat ein grünes Häkchen, der Rest ist gelb (degraded). Der Trick mit dem Cache leeren unter C:\ProgramData\Microsoft\SharePoint\Config (also das Löschen aller XML-Files und das setzen von 1 in der cache.ini) bringt nichts. Die Rücksetzung des nicht vorhandenen Indexes bringt ebenfalls nichts. Die zusätzliche Eintragung von Berechtigungen der eingetragenen Accounts unter "Dienstanwendungen verwalten" ebenso nichts. Der verwaltete Metadatendienst und der Statusdienst sind installiert. Zusätzlich habe ich noch testweise in MS-SQL direkte Berechtigungen zum Zugriff auf die Suchdatenbanken durch die Accounts SPSearchDBAdmin, WSS_ADMIN_WPG und WSS_WPG erteilt - bringt nichts. Die Berechtigungen für die Benutzer WSS_ADMIN_WPG & Co. auf die relevanten Ordner im regulären Dateisystem sind standardmäßig gesetzt mit Vollzugriff. Ich habe das jeweils ausprobiert mit einem frisch aufgesetzten SharePoint in englischer Sprache, zwei weitere Male mit vorher und nachher installiertem Sprachpaket für Deutsch. Ein Problem mit der Sprachkodierung ist daher wohl auszuschließen (es sei denn, die Sprachkodierung des Betriebssystems wäre der Fehler). Eine Kreierung und Aktivierung einer neuen Topologie bringt ebenfalls nichts. MemoryLimit in der noderunner.ini unter C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Settings sowie der noderunner.exe.config unter C:\Program Files\Microsoft Office Servers\16.0\Search\Runtime\1.0 habe ich jeweils auf 0 gesetzt (also ohne Limit), testweise beide auf 512 MB. Erfolglos. NET Framework ist u.a. in Version 3.5 installiert.

    Sobald ich übrigens die microsoft.ceres.coreservices.deployment.dll mit in die erstellten Unterordner kopiere, wird diese geladen und die Topologie wird wieder überhaupt nicht geladen. Hinzuweisen bleibt noch darauf, daß die microsoft.ceres.coreservices.node.dll in der Version 16.0.0.0 geladen werden soll, jedoch nur in der Version 16.0.10337.12109 vorhanden ist (was aber wohl nicht das Problem ist).

    Wenn ich in der von mir nach \IndexComponent1 herüberkopierten Node.config in Zeile 34 den auskommentierten System.Diagnostics.XmlWriterTraceListener aktiviere, wird die app_tracelog.svclog erstellt, wo sich sogleich diese Meldungen finden:

    Eine Ausnahme wird verarbeitet. Ausnahmedetails: System.ServiceModel.FaultException [Microsoft.Ceres.CoreServices.Services.Container.StaleServiceReferenceException]: No service with the the given service ID (178) in the service registry.

    Aktivitäts-ID: {00000000-0000-0000-0000-000000000000} (Anm.: Es wird tatsächlich auf 00000..., also ins Leere referenziert)

    EventID 131075: Fehler beim Lesen aus der Pipe: Die Pipe wurde beendet. (109, 0x6d).

    In der Ereignisanzeige tritt dann noch die Fehlermeldung auf:

    SharePoint Server Search: Das Inhalts-Plug-In kann nicht initialisiert werden - die Liste der CSS-Adressen ist nicht festgelegt.

    Anzumerken ist, daß im Abschnitt <services> der eigens reinkopierten Node.config kein Binding angegeben ist, dort heißt es:

    <endpoint address="" binding="netTcpBinding" bindingConfiguration="CertificateWithTransport" contract="Microsoft.Ceres.InteractionEngine.Services.ProcessingEngine.IProcessingEngine" />

    In dem betreffenden Abschnitt heißt es auskommentiert: This section is loaded by SharePoint Base to determine currrent (search) service application. Wenn ich dann als endpoint address folglich net.pipe://localhost:32843/...ID.../SearchService.svc einfüge (ID = GUID bzw. Name des virtuellen Verzeichnisses der SharePoint Web Services im IIS), dann meldet es wieder "Node not found".

    Zu guter Letzt habe ich dann mal den SharePoint Server 2019 von der deutschen Image-Datei installiert, wo das gleiche Problem auftritt. Für die IndexComponent1 wurde dieses mal eine halb fertige Node.config mit 2 kB erstellt, die irgendwo in Zeile 44 abgeschnitten war (ein ander Mal war es irgendwo anders abgeschnitten), aber bis dort hin exakt identisch mit der Node.config aus dem Ordner \QueryProcessingComponent1. An dieser Stelle ist auf jeden Fall irgendwo der Wurm drin. Ein Konflikt aus den Sprachversionen kann damit zumindest wohl ausgeschlossen werden.

    Ich glaube also, mittlerweile alle Eventualitäten und Varianten durchgespielt zu haben. Lediglich das viel beschriebene Klonen der Topologie habe ich nicht durchgeführt, da ja das Klonen einer nicht funktionierenden Konfiguration wohl sinnlos ist. Es ist wohl müßig darauf hinzuweisen, daß der Crawler nach setzen der Durchforstungsregel zwar endlos crawlt, jedoch keinerlei Ergebnisse liefert. Wäre dankbar für etwaige Lösungsansätze! Es sollte wohl möglich sein, die Suche in dieser Konfiguration irgendwie zum Laufen zu bringen?

    • Bearbeitet Uwe Martens Sonntag, 11. August 2019 06:30
    Freitag, 9. August 2019 16:04

Antworten

  • Bezugnehmend auf mein vorstehendes Posting habe ich folgende Lösung gefunden: Um die Suchanwendung des SharePoint Server 2019 auf dem selben nativen Rechner parallel zum Exchange Server 2019 zum Laufen zu bringen, muß zunächst ein verzögerter Start des Dienstes "Microsoft Exchange Search Host Controller" konfiguriert werden. Den Starttyp des Dienstes auf Automatisch (verzögerter Start) zu setzen, genügt nicht, weswegen die folgenden Schritte erforderlich sind:

    1. Die Dienste-Verwaltungskonsole aufrufen (z.B. durch Eingabe von services.msc in der CMD-Konsole) und den Starttyp für den Dienst "Microsoft Exchange Search Host Controller" auf manuell setzen.
    2. Gehe zu → Start → Windows-Verwaltungsprogramme → Aufgabenplanung, Rechtsklick in das Task-Feld und dann "Neue Aufgabe erstellen" und bezeichnen als "Start Microsoft Exchange Search Host Controller" oder was auch immer.
    3. Unter Trigger auf "Neu" klicken und "Beim Start" auswählen, das Kontrollkästchen Verzögern für markieren, aus den vordefinierten Optionen 15 Minuten auswählen und auf 10 Minuten setzen (was auf jedem System ausreichen sollte).
    4. Unter Aktionen auf "Neu" klicken und "Programm starten" auswählen, Program/Script auf NET setzen und unter Argumente hinzufügen START "Microsoft Exchange Search Host Controller"  eingeben.
    5. Bei der abschließenden Aufforderung zur Eingabe der Benutzerkontoinformationen das Paßwort (z.B.) des Domänen Administrator-Accounts eingeben.
    6. Die Datei Node.config aus dem Ordner C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Nodes\XXXXXX\QueryProcessingComponent1 nach C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Nodes\XXXXXX\IndexComponent1 kopieren (für XXXXXX  siehe die ID der betreffenden Node; Datei überschreiben, sofern vorhanden).
    7. Neustart des Servers (hilfsweise den Dienst "Microsoft Exchange Search Host Controller" manuell stoppen, den Dienst "SharePoint Search Host Controller" neu starten und dann den "Microsoft Exchange Search Host Controller" wieder starten, abschließend einen IIS Reset auslösen).
    • Als Antwort markiert Uwe Martens Dienstag, 20. August 2019 23:54
    Dienstag, 20. August 2019 23:54

Alle Antworten

  • Hi Uwe,
    hast Du mit PowerShell die Suchanwendung erstellt? Wenn ja, wie sieht der Script aus?


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Sonntag, 11. August 2019 06:46
  • Servus! Nein, das habe ich über die Zentraladministration gemacht.
    • Bearbeitet Uwe Martens Sonntag, 11. August 2019 06:50
    Sonntag, 11. August 2019 06:49
  • Hi Uwe,
    ich habe gerade einen neuen SP 2019 On-Premise installiert und konfiguriert und habe mit der Suchanwendung keine Probleme gehabt. Es dauert einige Minuten, bis auch die Suchtopologie vollständig funktioniert.

    In Deinen Ausführungen steht, dass Du den SharePoint Server auf dem gleichen Rechner wie der DC installiert hast. Das sollte man nicht tun. Bei mir besteht die Minimaltopologie aus DC, SQL Server, SP Server, OOS und WF Farm. Beim Durchforsten kommt lediglich das leidige Problem mit dem Durchforsten von sps3 wegen fehlenden Rechten. Das Durchforstungskonto muss als Administrator in der Nutzerprofildienstanwendung mit dem Recht "Retrieve people and data for search crawlers" eingetragen sein.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks


    Dienstag, 13. August 2019 07:20
  • Servus und danke für Deine Bemühungen! Ich hätte da zwei Fragen zu Deinem System:

    1. Was steht bei Dir in der node.config der IndexComponent1? Es wäre bei meinem System erst mal zu klären, wieso bei der Erstellung der Topologie diese node.config manchmal unvollständig ist.

    2. Welche Authentifizierung ist bei Dir in den SharePoint Web Services im IIS eingetragen? Einmal war es bei mir (scheinbar von Haus aus) nur "anonym", ein andermal "Windows". Anzumerken ist auch hier, daß in sämtlichen web.config Dateien der virtuellen Verzeichnisse (bzw. deren Anwendungen) keinerlei Bindungen eingetragen sind (was aber der Funktionalität beispielsweise des Metadatendienstes keinen Abbruch tut).

    Die beiden Anwendungen http://localhost:32843/...ID.../SearchAdmin.svc und http://localhost:32843/...ID.../SearchService.svc sind bei mir im Browser übrigens aufrufbar (bei https bringt es eine Zertifikatsfehlermeldung).

    Mögliche Ursache ist bei mir vielleicht auch die gemeinsame Verwendung der noderunner.exe durch den Exchange Server und den SharePoint Server - und damit natürlich auch die gemeinsame Verwendung der Default Website: Hier habe ich für den Exchange Server eine Subdomain der Domäne als http- und https-Bindungen samt korrektem Zertifikat hinterlegt (was aber ja die net.tcp-Bindung nicht betrifft).

    Auf jeden Fall habe ich den Anspruch, das alles auf einem Einzelserver (zwangsweise als Domänen Controller) zum Laufen zu bringen. Ich setze nötigenfalls mal ein virtuelles Betriebssystem auf oder installiere den SharePoint auf einem anderen Server, um zu sehen, wo da die Unterschiede liegen.

    • Bearbeitet Uwe Martens Dienstag, 13. August 2019 08:55
    Dienstag, 13. August 2019 07:57
  • Da hier ja scheinbar recht wenig los ist, habe ich das mal im englischsprachigen Forum gepostet unter Search Application Topology in SharePoint Server 2019.
    Dienstag, 13. August 2019 21:24
  • Hi Uwe,
    so tief bin ich nicht in die Details eingestiegen, da es bei mir auf Anhieb funktioniert hat. Viel wichtiger für sind andere Details wie Office Online und Workflows. Da scheint man bei Microsoft noch Probleme zu bearbeiten.

    Eine Sache ist mir aufgefallen. Wenn der SharePoint Server mit der Suchanwendung neu durchgestartet wird, gibt es manchmal Probleme, die aussehen wie inkonsistente Daten und den erfolgreichen Start der Topologie verhindern. Die Durchforstung läuft dann auch unendlich. Mit der Neuanlage der Suchanwendung war das Problem dann immer beseitigt.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Mittwoch, 14. August 2019 07:30
  • Mittlerweile habe ich den SharePoint Server 2019 mal auf einem zweiten Server aufgesetzt, auf dem kein Exchange Server installiert ist - dort funktioniert die Suche und es wird für die IndexComponent1 dann keine Node.config benötigt. Darauf habe ich auf dem Domänen Controller mal den Dienst "Microsoft Exchange Search Host Controller" angehalten - und sodann funktionieren auch alle SharePoint Suchkomponenten (die Unterordner C:\Program Files\Microsoft Office Servers\16.0\Search\Runtime\1.0\Applications\Shared sind dann nicht mehr notwendig). Es wäre also die Frage, in wie fern die beiden Dienste "Microsoft Exchange Search Host Controller" und "SharePoint Search Host Controller" (die ja auf jeweils unterschiedliche noderunner.exe aus eigenen Ordnern zugreifen) miteinander kollidieren bzw. in wie fern die net.pipe Bindungen und sonstigen DNS-Einstellungen des SharePoint Servers durch den Exchange Server beeinträchtigt werden und welche zusätzlichen Einstellungen (insb. in der jeweiligen hostcontrollerservice.exe.config) ggf. vorzunehmen sind, um den SharePoint Server und den Exchange Server zusammen auf einem Server zum Laufen zu bringen.

    Montag, 19. August 2019 11:10
  • Hi Uwe,
    ich gehe davon aus, dass die geleichzeitige Installation des SharePoints und Exchange Server unter dem gleichen Server Betriebssystem nicht unterstütz ist. Hast Du eine Aussage gefunden, das so etwas unterstützt wird?

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Montag, 19. August 2019 11:22
  • Servus - nein, das habe ich nirgends gefunden. Allerdings ist das gerade für kleinere Projekte ja das Naheliegenste - zumal die Funktionen des Exchange Servers ja in die des SharePoint Servers integriert werden. Wie ich oben noch ergänzt habe, sind es also die beiden Dienste "Microsoft Exchange Search Host Controller" (Pfad: C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\hostcontrollerservice.exe) und "SharePoint Search Host Controller" (Pfad: C:\Program Files\Microsoft Office Servers\16.0\Search\HostController\hostcontrollerservice.exe), die miteinander kollidieren. Und hier sollte sich ja wohl in absehbarer Zeit eine Lösung finden.
    Montag, 19. August 2019 11:48
  • Bezugnehmend auf mein vorstehendes Posting habe ich folgende Lösung gefunden: Um die Suchanwendung des SharePoint Server 2019 auf dem selben nativen Rechner parallel zum Exchange Server 2019 zum Laufen zu bringen, muß zunächst ein verzögerter Start des Dienstes "Microsoft Exchange Search Host Controller" konfiguriert werden. Den Starttyp des Dienstes auf Automatisch (verzögerter Start) zu setzen, genügt nicht, weswegen die folgenden Schritte erforderlich sind:

    1. Die Dienste-Verwaltungskonsole aufrufen (z.B. durch Eingabe von services.msc in der CMD-Konsole) und den Starttyp für den Dienst "Microsoft Exchange Search Host Controller" auf manuell setzen.
    2. Gehe zu → Start → Windows-Verwaltungsprogramme → Aufgabenplanung, Rechtsklick in das Task-Feld und dann "Neue Aufgabe erstellen" und bezeichnen als "Start Microsoft Exchange Search Host Controller" oder was auch immer.
    3. Unter Trigger auf "Neu" klicken und "Beim Start" auswählen, das Kontrollkästchen Verzögern für markieren, aus den vordefinierten Optionen 15 Minuten auswählen und auf 10 Minuten setzen (was auf jedem System ausreichen sollte).
    4. Unter Aktionen auf "Neu" klicken und "Programm starten" auswählen, Program/Script auf NET setzen und unter Argumente hinzufügen START "Microsoft Exchange Search Host Controller"  eingeben.
    5. Bei der abschließenden Aufforderung zur Eingabe der Benutzerkontoinformationen das Paßwort (z.B.) des Domänen Administrator-Accounts eingeben.
    6. Die Datei Node.config aus dem Ordner C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Nodes\XXXXXX\QueryProcessingComponent1 nach C:\Program Files\Microsoft Office Servers\16.0\Data\Office Server\Applications\Search\Nodes\XXXXXX\IndexComponent1 kopieren (für XXXXXX  siehe die ID der betreffenden Node; Datei überschreiben, sofern vorhanden).
    7. Neustart des Servers (hilfsweise den Dienst "Microsoft Exchange Search Host Controller" manuell stoppen, den Dienst "SharePoint Search Host Controller" neu starten und dann den "Microsoft Exchange Search Host Controller" wieder starten, abschließend einen IIS Reset auslösen).
    • Als Antwort markiert Uwe Martens Dienstag, 20. August 2019 23:54
    Dienstag, 20. August 2019 23:54