SharePointCommunity
Die deutschsprachige Community für SharePoint, Microsoft 365, Teams, Yammer und mit Azure

Sponsored by

Willkommen im Forum Archiv.
Einträge sind hier nicht mehr möglich, aber der Bestand von 12 Jahren SharePoint-Wissen ist hier recherchierbar.




Problem SPSearch4

Unbeantwortet Dieser Beitrag hat 2 Antworten

Ohne Rang
4 Beiträge
Frank Zander erstellt 11 Jan. 2011 14:19
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Hallo Sharepoint Freunde,

ich habe mittlerweile eine Menge Zeit mit dem Thema verbracht und einen Produktiven SP Foundation 2010 am laufen.

In den letzten Tagen kamen aber vermehrt Hinweise darüber, das die Suchfunktion nicht ginge.

Ich habe mir die Anwendungsprotokolle mal genauer angesehen und genau eine Warnung, die alle 5Minuten genau 2 mal zutrifft.

Ereignis-ID: 14

Details, dort habe ich 2 Varianten des Fehlers:

1. Dieses Element konnte nicht durchforstet werden, da das Repository nicht innerhalb des angegebenen Timeouts reagiert hat. Durchforsten Sie das Repository später, oder erhöhen Sie den Timeoutwert auf der Seite 'Proxy und Timeout' in der Suchverwaltung. Sie können auch versuchen, die Durchforstung dieses Repositorys für Zeiten geringer Auslastung zu planen.   (0x80040d7b)

2. Das Durchforstungsmodul konnte nicht mit dem Server kommunizieren. Überprüfen Sie, ob der Server verfügbar ist und ob der Firewallzugriff ordnungsgemäß konfiguriert ist. Wenn das Repository vorübergehend nicht verfügbar war, wird dieser Fehler durch eine inkrementelle Durchforstung behoben.   (0x80041200)

 

Zu meiner Contentdatenbank, die Daten wurden aus einem alten WSS 3.0 migriert und das hat bisher keine Probleme gemacht.

Ob die Suche jemals funktionierte, kann ich nicht sagen, da ich sie leider nicht getestet habe :/
Wenn man sie nutzen wollte, hat sie nichts gefunden. Es sieht so aus, auch anhand der Warnungen, das der Crawler nicht richtig läuft.

Ich wollte erst einmal testen, ob ein Administratoraccount und nicht mein eingeschränkter Suchdienst User die Warnung behebt.
Dazu bin ich in der Administrationszentrale nach Anwendungsverwaltung und dann Dienste auf dem Server verwalten gegangen. Dort dann SharePoint Foundation-Suche geklickt.

Dort wollte ich den User ändern.. Dummerweise habe ich es geschafft, den NETZWERKDIENST und nicht den lokalen Admin Account zu wählen und zu speichern.. Schande über mich!

Das löst nun ein weiteres Problem aus. Ich kann weder den User über den gleichen Pfad wieder ändern noch über Sicherheit -> Dienstkonten konfigurieren..

Ich erhalte immer die Fehlermeldung

Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Führen Sie die Problembehandlung mit Microsoft SharePoint Foundation aus.

Korrelations-ID: 9a5d83ef-d21a-4d20-9afe-b6afd9b4cb17

Datum und Uhrzeit: 11.01.2011 14:18:14

Natürlich immer eine neue ID.


Kann ich das irgendwie wieder rückgängig machen?

Kann ich den Crawler User per Shell setzen und den Dienst wieder mit richtigem Account starten?

Versucht habe ich schon das ändern über services.msc und über den Shell Befehl "Set-SPSearchService -CrawlAccount <STRING>". Leider hat mich das nichts weiter gebracht.

 

Ich hoffe ihr könnt mir weiter helfen.

 

Danke

Grüße
Frank

 

 

*edit:

 

Ich habe das ganze mal in den Logs anhand der ID verfolgt.

Da sich die ID Geändert hat, hier die neue Fehlermeldung:

Fehler

Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Führen Sie die Problembehandlung mit Microsoft SharePoint Foundation aus.

Korrelations-ID: 240fc276-c18a-4c3b-bb69-74f2411a1b24

Datum und Uhrzeit: 11.01.2011 16:01:04

 

Passender Log dazu:

11.01.2011 16:01:04.31    w3wp.exe (0x1500)    0x1048    SharePoint Foundation    Monitoring    nasq    Medium    Entering monitored scope (Request (GET:https://XXX:41733/_admin/SPSearchServiceInstanceSettings.aspx?ServerId=d9163fac-491c-4c28-ac45-69528ccba374))   


11.01.2011 16:01:04.31    w3wp.exe (0x1500)    0x1048    SharePoint Foundation    Logging Correlation Data    xmnv    Medium    Name=Request (GET:https://XXX:41733/_admin/SPSearchServiceInstanceSettings.aspx?ServerId=d9163fac-491c-4c28-ac45-69528ccba374)    240fc276-c18a-4c3b-bb69-74f2411a1b24


11.01.2011 16:01:04.32    w3wp.exe (0x1500)    0x1048    SharePoint Foundation    Logging Correlation Data    xmnv    Medium    Site=/    240fc276-c18a-4c3b-bb69-74f2411a1b24


11.01.2011 16:01:04.34    w3wp.exe (0x1500)    0x1048    SharePoint Foundation    Runtime    tkau    Unexpected    System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.    bei Microsoft.SharePoint.Administration.SPProcessIdentity.GetCurrentUsername()     bei Microsoft.SharePoint.Search.Internal.UI.SPSearchServiceInstanceSettings.PopulateServiceAccount(SPProcessIdentity pi)     bei Microsoft.SharePoint.Search.Internal.UI.SPSearchServiceInstanceSettings.OnLoad(EventArgs e)     bei System.Web.UI.Control.LoadRecursive()     bei System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)    240fc276-c18a-4c3b-bb69-74f2411a1b24


11.01.2011 16:01:04.34    w3wp.exe (0x1500)    0x1048    SharePoint Foundation    Monitoring    b4ly    Medium    Leaving Monitored Scope (Request (GET:https://XXX:41733/_admin/SPSearchServiceInstanceSettings.aspx?ServerId=d9163fac-491c-4c28-ac45-69528ccba374)). Ausführungszeit=30,02253    240fc276-c18a-4c3b-bb69-74f2411a1b24


Alle Antworten

Ohne Rang
4 Beiträge
Frank Zander Als Antwort am 12 Jan. 2011 09:03
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Heute konnte ich den Dienst wieder Starten und habe die Rechte so weit angepasst.

Der Search Mechanismus geht wieder aber 2 Probleme habe ich noch.

 

1. Es gibt ein Berechtigungsproblem. Die Domänen User, die auf den SP zugreifen können zwar suchen, aber finden nichts. Mit einem Lokalen User der auf einer SP Site sucht (gleicher String auf der gleichen Seite) findet alles. Wo muss ich hier noch Berechtigungen für die Domäne setzen?

2. Ich bekomme immer noch die Warnungen im Log

Die Startadresse 'sts4s://XXX:41733/contentdbid={ca25c4d8-e811-420e-aaf4-b8537d7efa66}' kann nicht durchforstet werden.

Kontext: Anwendung 'Suchindexdateien_auf_dem_Suchserver', Katalog 'Search'

Details:
    Das Durchforstungsmodul konnte nicht mit dem Server kommunizieren. Überprüfen Sie, ob der Server verfügbar ist und ob der Firewallzugriff ordnungsgemäß konfiguriert ist. Wenn das Repository vorübergehend nicht verfügbar war, wird dieser Fehler durch eine inkrementelle Durchforstung behoben.   (0x80041200)

Port 4173 ist bei mir auch die Zentraladministration. Warum will er die Crawlen? Ist doch nicht nötig...

Ohne Rang
4 Beiträge
Frank Zander Als Antwort am 12 Jan. 2011 16:27
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Und weiter gehts..

 

1. Das Problem ist wohl schon bekannt, gibt auch einen schönen Blog Beitrag von Mat Stratton. Leider hilft der mir nicht ganz weiter. (Quelle: http://mattstratton.com/tech-tips/configuring-sharepoint-2010-search-in-a-one-way-trust-scenario)

Ich bekommen bei der Übergabe des Domain\XXXUserXXX an "New-SPManagedAccount" leider den fehler:

PS C:\Users\Administrator> New-SPManagedAccount

Cmdlet New-SPManagedAccount an der Befehlspipelineposition 1
Geben Sie Werte für die folgenden Parameter an:
Credential
New-SPManagedAccount : Der angegebene Wert wird für den {0}-Parameter nicht unt
erstützt.
Bei Zeile:1 Zeichen:21
+ New-SPManagedAccount <<<<
    + CategoryInfo          : InvalidData: (Microsoft.Share...wManagedAccount:
   SPCmdletNewManagedAccount) [New-SPManagedAccount], ArgumentException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewManag
   edAccount

PS C:\Users\Administrator>

Der scheint die Credentials nicht zu übergeben, mit einem Lokalen User klappt es natürlich Problemlos..

 

2. Das Problem ist auch bekannt, allerdings sehr selten. Problem ist hier das Windows Server Feature "Loopback check security". Das tritt auf, wenn der angesprochene name nicht gleich Hostname ist. Also wenn der Sharepoint über SP-Site.de angesprochen wird, aber der lokale hostname winSRVXY.domain.im.betrieb.de ist.

Dazu muss einfach dieses sicherheitsfeature ausgeschaltet werden, was auch nicht schlimm ist, sollte so eine Konfig vor liegen.

Dazu wie folgt vorgehen:

In der Registry muss

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck

als DWORD erstellt werden und den Wert "1" enthalten.

Nach einem Neustart des Servers sollten die Warnungen verschwinden und der Crawler Prozess sollte vollständig durchlaufen.

 

Eine weitere Möglichkeit, die bei mir auch zu traf, war das Crawlen des Admin Centers. Warum auch immer, war in der ContentDB das Crawlen angeschaltet. Ausgeschaltet und das Problem is auch behoben.

 

Ich hoffe, das hilft mal jemanden weiter.

 

Zu meinem Problem "1" bräuchte ich aber dennoch ein wenig Unterstützung.

Würde mich über jeden Tipp freuen.

 

viele grüße Frank