Knowledgebase

Die wahrscheinlichste Ursache für dieses Problem ist ein Windows-Update, das Microsoft kürzlich veröffentlicht hat. Wir konnten dieses Problem in TreeSize Version 9.8.1 und UltraSearch Version 4.8.2 beheben. Bitte aktualisieren Sie daher nach Möglichkeit Ihre Software. Sollte dies nicht möglich sein, ziehen Sie bitte in Betracht, das Windows-Update KB5094126 zu deinstallieren.

DataCentral hat eine Berechtigungsprüfung implementiert.

Obwohl Dateien indiziert sein können, auf welche nicht jeder Nutzer Zugriff hat, liefert DataCentral automatisch nur Suchergebnisse, auf die der entsprechende UltraSearch-Nutzer auch wirklich Zugriff hat.

Im Normalfall wird 1 Lizenz zum Ausführen von SpaceObServer und DataCentral auf einem Server gebraucht, sowie n Lizenzen von UltraSearch Professional für n Personen, die die Indizes von DataCentral durchsuchen können.

Die Datenmenge im Index und die Anzahl der Suchen sind unlimitiert.

Bitte öffnen Sie UltraSearch, wechseln Sie zu Optionen > Sonstiges > Mit einem DataCentral-Dienst verbinden und klicken Sie auf die Schaltfläche Verbindung testen. Falls die Verbindungsprüfung fehlschlägt, fahren Sie bitte mit folgenden Optionen fort:

1. Verfügbarkeit des Dienstes und Netzwerkverbindung prüfen
   Stellen Sie sicher, dass der Dienst SpaceObServer DataCentral auf dem SpaceObServer-Hostsystem ausgeführt wird und die DataCentral REST-Schnittstelle in SpaceObServer aktiviert ist.
   Öffnen Sie https://hostname:port/healthz. Der Endpunkt muss Healthy zurückgeben.
   Stellen Sie sicher, dass die DataCentral-Verbindung nicht durch eine Firewall blockiert wird. Der Standardport ist 5149.
   Öffnen Sie in SpaceObServer Start > Optionen > Indexdienst und prüfen Sie, ob der DataCentral-Server aktiviert ist und denselben Port verwendet, der auch in UltraSearch konfiguriert ist.
2. Das von DataCentral verwendete Zertifikat prüfen
   Prüfen Sie in SpaceObServer unter Start > Optionen > Indexdienst, welches Zertifikat derzeit für den DataCentral-Dienst konfiguriert ist.
   Vergleichen Sie den dort angezeigten Zertifikat-Fingerabdruck mit dem in UltraSearch konfigurierten Zertifikat bzw. Fingerabdruck.
   In UltraSearch können Zertifikatseinstellungen nur im Administrationsmodus geändert werden.
   Wenn UltraSearch ohne explizite Zertifikatsparameter installiert wurde, validiert es das DataCentral-Zertifikat standardmäßig per Fingerabdruck und speichert den Fingerabdruck der ersten Verbindung für die spätere Kommunikation.

3. Authentifizierung und SPN-Konfiguration prüfen
   Testen Sie in UltraSearch die Verbindung zur IP-Adresse des SpaceObServer-DataCentral-Hosts. Wenn die Verbindung über die IP-Adresse funktioniert, aber nicht über den Servernamen, hängt das Problem typischerweise mit Kerberos/SPNs zusammen. Bei Verbindungen über die IP-Adresse wird in der Regel NTLM verwendet, bei Verbindungen über den Hostnamen bevorzugt Kerberos.
   Wenn die Verbindungsprüfung mit dem Hostnamen Die Verbindung konnte nicht aufgebaut werden zurückgibt, können Sie
   1) NTLM (IP-Adresse nutzen) als Authentifizierungsmethode nutzen (aus Sicherheitsgründen nicht empfohlen; funktioniert nicht, wenn NTLM per Gruppenrichtlinie deaktiviert ist)
   2) GGfs. das Passwort des Dienstkontos neu setzen um einen AES-Schlüssel sicherzustellen
   3) Kerberos funktionsfähig machen, indem Sie die SPN-Konfiguration in Ihrem Active Directory korrigieren (siehe unten).
   
   Unter welchem Konto läuft der DataCentral-Dienst?
   - Lokales System / Netzwerkdienst: In der Regel ist keine SPN-Konfiguration nötig, die vorhandenen HOST/-SPNs des Computerkontos decken auch HTTP/ ab. Registrieren Sie keine HTTP/-SPNs für den Servernamen an einem anderen Konto, das führt genau zu diesem Fehler.
   - Dediziertes Domänenkonto: Registrieren Sie die HTTP-SPNs für dieses Dienstkonto (nicht für das Computerkonto). Beachten Sie dabei den folgenden Hinweis.
   
   Wichtig: Ein expliziter HTTP/-SPN für den Servernamen wirkt sich auf den ganzen Host aus.
   Solange kein eigener HTTP/-SPN existiert, löst Active Directory HTTP/servername über den HOST/-SPN des Computerkontos auf. Registrieren Sie HTTP/servername am Dienstkonto von DataCentral, erhalten Clients ab dann für jeden HTTP- bzw. HTTPS-Dienst auf diesem Host ein Kerberos-Ticket für das Dienstkonto von DataCentral. Andere HTTP-basierte Dienste, die unter dem Computerkonto laufen, können dann nicht mehr per Kerberos authentifiziert werden, z. B. die Windows-Remoteverwaltung (WinRM/PowerShell-Remoting), IIS-Websites oder WSUS. setspn -S und setspn -X warnen dabei nicht, da kein doppelter SPN entsteht. Dienste mit einer anderen Dienstklasse, z. B. Dateifreigaben (CIFS/) oder Remotedesktop (TERMSRV/), sind nicht betroffen.
   Laufen auf dem Host weitere HTTP-basierte Dienste, verwenden Sie stattdessen einen eigenen DNS-Namen für DataCentral (siehe unten).
   
   SPNs prüfen und korrigieren
   Das Ändern von SPNs erfordert Schreibrechte auf das Attribut servicePrincipalName des Kontos (z. B. Domänen-Admin oder delegiert).
   1) Verwenden Sie setspn -L <Dienstkonto>, um die aktuell gesetzten SPNs zu prüfen. Benötigt wird ein SPN für jeden Namen, über den UltraSearch den Server anspricht, z. B. HTTP/servername und HTTP/servername.domain.tld sowie ggf. DNS-Aliase. Der Port (z. B. 5149) ist nicht Teil des SPN.
   2) Prüfen Sie mit setspn -Q HTTP/servername und setspn -Q HTTP/servername.domain.tld, ob diese SPNs bereits einem anderen Konto zugeordnet sind. setspn -X listet doppelte SPNs in der Domäne auf.
   3) Ist ein SPN einem falschen Konto zugeordnet, entfernen Sie ihn dort mit setspn -D <SPN> <falsches Konto>.
   4) Verwenden Sie setspn -S <SPN> <Dienstkonto>, um einen fehlenden SPN hinzuzufügen. Meldet setspn -S einen doppelten SPN, ist dieser bereits einem anderen Konto zugeordnet (siehe 2 und 3).
   5) Löschen Sie auf dem UltraSearch-Client die zwischengespeicherten Kerberos-Tickets mit klist purge (oder melden Sie sich ab und wieder an) und wiederholen Sie die Verbindungsprüfung.
   Kerberos setzt außerdem voraus, dass der Client Mitglied der Domäne (bzw. einer vertrauten Domäne) ist und die Systemzeit von Client und Server um höchstens 5 Minuten abweicht.
   
   Eigenen DNS-Namen für DataCentral verwenden (empfohlen bei Domänenkonto)
   Mit einem eigenen DNS-Namen, z. B. sosdatacentral.domain.tld, erhält DataCentral einen eigenen HTTP/-SPN. Der HTTP/-SPN des Servernamens bleibt beim Computerkonto, und die übrigen HTTP-basierten Dienste des Hosts funktionieren weiter per Kerberos. Dafür muss der neue Name im Zertifikat von DataCentral enthalten sein, und UltraSearch muss DataCentral über diesen Namen ansprechen.
   1) Legen Sie im DNS einen A-Eintrag (keinen CNAME) an, der auf die IP-Adresse des DataCentral-Servers zeigt, z. B. per PowerShell auf dem DNS-Server: Add-DnsServerResourceRecordA -ZoneName domain.tld -Name sosdatacentral -IPv4Address <IP-Adresse>. Bei einem CNAME bildet der Client den SPN aus dem Zielnamen, also wieder aus dem Servernamen. Prüfen Sie die Namensauflösung auf dem Client mit Resolve-DnsName sosdatacentral.domain.tld.
   2) Wurden zuvor HTTP/-SPNs für den Servernamen am Dienstkonto registriert, entfernen Sie diese mit setspn -D HTTP/servername <Dienstkonto> und setspn -D HTTP/servername.domain.tld <Dienstkonto>.
   3) Registrieren Sie die SPNs für den neuen Namen am Dienstkonto mit setspn -S HTTP/sosdatacentral <Dienstkonto> und setspn -S HTTP/sosdatacentral.domain.tld <Dienstkonto>.
   4) Stellen Sie ein Zertifikat mit dem neuen Namen aus, z. B. über Ihre Unternehmens-CA. Das vom SpaceObServer-Installer erzeugte Zertifikat enthält den neuen Namen nicht. Das Zertifikat muss den neuen Namen als alternativen Antragstellernamen (SAN) enthalten (sosdatacentral.domain.tld, ggf. zusätzlich sosdatacentral), für die Serverauthentifizierung zugelassen sein und einen privaten Schlüssel haben. Importieren Sie es in den Zertifikatspeicher Lokaler Computer > Eigene Zertifikate und geben Sie dem Dienstkonto Leserechte auf den privaten Schlüssel.
   5) Wählen Sie das neue Zertifikat in SpaceObServer unter Optionen > Indexdienst aus und starten Sie den DataCentral-Dienst neu.
   6) Tragen Sie in UltraSearch (Administrationsmodus) sosdatacentral.domain.tld als DataCentral-Server ein und aktualisieren Sie den Zertifikat-Fingerabdruck.
   7) Löschen Sie auf dem Client die Kerberos-Tickets mit klist purge und prüfen Sie die Verbindung. klist sollte danach ein Ticket für HTTP/sosdatacentral.domain.tld anzeigen.
   8) Optional: Prüfen Sie mit Test-WSMan -ComputerName servername.domain.tld -Authentication Kerberos, ob die Remoteverwaltung des Hosts wieder per Kerberos funktioniert. Ohne -Authentication sendet Test-WSMan eine anonyme Anfrage und sagt über Kerberos nichts aus.
   Danach erreicht UltraSearch DataCentral per Kerberos nur noch über den neuen Namen. Über den Servernamen erhält der Client ein Ticket für das Computerkonto, das DataCentral unter dem Domänenkonto nicht annehmen kann.
   
   

Wenn die Verbindungsprüfung erfolgreich ist, folgen Sie bitte diesen Schritten:

1. Vorhandensein von Scan/Index prüfen 
   Wenn die Suche keine Ergebnisse liefert, prüfen Sie, ob der Ordner, in dem Sie suchen, bereits von SpaceObServer/DataCentral gescannt und indiziert wurde.  
   Prüfen Sie bei Inhaltssuchen, ob der Volltextindex für den Scan aktiviert ist.  
   Prüfen Sie auch, ob ein UltraSearch-Ausschlussfilter aktiv ist.
2. Protokolle auf dem DataCentral-Server prüfen
   Prüfen Sie das Windows-Ereignisprotokoll auf Fehler von SpaceObServer Agent und SpaceObServer DataCentral.
   Wenn eine Datei durchsuchbar sein sollte, aber nicht gefunden wird, wurde sie möglicherweise aufgrund eines im Ereignisprotokoll angezeigten Indizierungsproblems nicht indiziert.

Die Geschwindigkeit von DataCentral hängt von vielen Faktoren ab.

Die Geschwindigkeit der Dokumentenindexierung hängt ab von:

• der Anzahl der tatsächlich indexierbaren Dateien (xlsx und txt sind indexierbar, exe jedoch nicht)
• der Größe der Dateien
• dem Dateityp (txt-Dateien sind in der Regel schneller als xlsx/pdf)
• der Hardware (RAM und CPU, inklusive der Anzahl der Kerne)
• dem Speicherort des Index (vermeide HDD-Festplatten oder Netzwerk-Speicher, bevorzuge eine angebundene SSD-Festplatte)

Für ein kleines Laufwerk kann DataCentral in wenigen Minuten fertig sein, für größere Laufwerke kann es Stunden dauern und bei sehr großen Laufwerken mit mehreren TB an indexierbaren Dateien (exe-Dateien, Bilder, ... zählen nicht) kann es sogar Tage dauern. Kleinere Scans führen zu kleineren Indizes, welche tendenziell schneller durchsucht werden können. Die initiale Indizierung dauert am längsten. Das regelmäßige Updaten des Index sollte deutlich schneller sein, da nur Änderungen im Dateisystem auf den Index angewendet werden müssen.

SpaceObServer zeigt im Fenster „Scans konfigurieren" in der Spalte „Status" des Scans einen Fortschritt und eine Schätzung der verbleibenden Indexierungszeit an.

Die Performance der Suche ist in der Regel schneller als ohne DataCentral und hängt ab von:

• der Anzahl der durch die Suche gefundenen Dateien
• dem Suchbegriff und dessen Häufigkeit im Index
• dem Netzwerk zwischen dem UltraSearch-Client und dem DataCentral-Server

Unser Ziel ist es, den Großteil der Suchanfragen innerhalb weniger Sekunden auszuführen.

Wenn die Suchergebnisse von DataCentral stammen, dann zeigt UltraSearch links unten "via DataCentral" an.

Wenn etwas nicht funktioniert und Suchergebnisse nicht von DataCentral geliefert werden können, führt UltraSearch eine "Fallback"-Suche durch, welche den Zielordner manuell durchsucht.

Das ist möglich, der einfachste Weg hierfür ist die Benutzung eines kompakten Tools, das bei der Installation der kostenlosen Version des PDF-XChange Editors mit installiert wird.

Das Tool lässt sich standardmäßig unter dem Pfad "C:\Program Files\Tracker Software\Shell Extensions\XCShInfoSetup.exe" finden.

TreeSize und UltraSearch verwenden beide den dort ausgewählten und damit in Windows registrierten IFilter (für die Datei-Inhaltssuche) und den ebenfalls dort registrierten Vorschau-Handler (für die Datei-Vorschau).

Textbasierte Dateitypen können grundsätzlich sofort durchsucht werden und sollten keine Probleme verursachen, wenn die verwendete Suchsyntax korrekt ist.

Andere Dateitypen erfordern üblicherweise einen IFilter, um durchsucht zu werden.

Unsere Software verwendet den entsprechenden IFilter, der in Windows für das entsprechende Dateiformat installiert und registriert ist. Wenn die Inhaltssuche keine Ergebnisse findet oder an irgendeiner Stelle stecken bleibt, liegt das höchstwahrscheinlich am entsprechenden IFilter; wir sehen dies besonders häufig bei PDF-Dateien.

Für PDF-Dateien empfehlen wir, den Adobe IFilter zu installieren, da dieser sich als zuverlässig erwiesen hat. Das erfordert nicht die Installation des Adobe Acrobat Readers, es handelt sich hierbei um einen separaten Installer.

Bei der Installation eines neuen Programms für den entsprechenden Dateityp kann es sein, dass der bisher registrierte IFilter ersetzt wird und dadurch Probleme bei der Datei-Inhaltssuche entstehen. Wenn das der Fall ist, kann der bisher verwendete IFilter durch eine erneute Installation dessen wieder aktiviert werden. Bei PDF-Dateien gibt es auch eine alternative Möglichkeit, die hier beschrieben ist.

Das ist ein bekannter Fehler, den wir bereits behoben haben. Hierfür muss ein neuer Installer heruntergeladen werden, diesen finden Sie in dem folgenden FAQ-Eintrag verlinkt: https://knowledgebase.jam-software.de/7670

Wenn auf einen Suchpfad nicht zugegriffen werden kann, kann dies unterschiedliche Ursachen haben.

• Der Ordner existiert nicht oder wurde umbenannt.
• Dem aktuellen Nutzer fehlen die Zugriffsrechte auf den Ordner.
• Der Ordner befindet sich auf einem Netzlaufwerk, welches momentan nicht zur Verfügung steht.
• Der Ordner befindet sich auf einem portablen Laufwerk oder USB-Stick, welches nicht eingesteckt ist.