Windows Search. Ein tolles Feature für „kleine Dateiserver“, so wie es Microsoft gerne mal nennt. Allerdings ist nicht ganz klar,
wo der kleine Dateiserver anfängt, oder wo er aufhört. Aber das ist ja ein anderes Thema.
Die Windows Suche (Windows Search) würde ich als datenbankgestützte Client/Server Anwendung bezeichnen. Grundsätzlich stellt der Client die Suchanfrage über eine „Named-Pipe“ an den Server.
Funktioniert dies nicht korrekt, so sucht der Client per SMB und greift dazu auf jeden Ordner und jede Datei auf dem Dateiserver zu. Dies führt unweigerlich zu Performanceproblemen, im Netz und auf dem Dateiserver.
Windows Search, einmal installiert, gibt es nicht wirklich viel zu konfigurieren. Das Netz ist voll von Bildern und Screenshots. Ich verschone euch hier mal damit. Die Indizierung baut eine Datenbank (Datenbank-Datei und Transaktionsprotokolle) und verschiedene Indexdateien auf.
In einer größeren Umgebung nutzt man gerne die Möglichkeiten
, die einem geboten werden. So auch bei einem Dateiserver. Der Dateiserver wird z.B. per Softwareverteilung installiert und stellenweise konfiguriert (sprich alle erforderlichen Rollen und Feature werden installiert).
Somit haben wir einen fertig installierten Dateiserver
, der seine Richtlinien und Einstellungen z.B. per Gruppenrichtlinien erhält. Neben den allgemeinen Richtlinien im Bezug auf IT-Grundschutz, Datensicherheit und Monitoring können natürlich auch andere Einstellungen vorgenommen werden:
– Ordnerstruktur für den Dateiserver anlegen
– NTFS Rechte auf die Ordnerstruktur vergeben
– Freigaben erstellen (!)
– Windows Suche konfigurieren (Pfad der Suchdatenbank und zu indizierende Laufwerke bzw. Ordner)
– usw.
Allerdings ist es so wie im richtigen Leben :-).
Man kann alles beachten und „richtig“ machen und es funktioniert dennoch nicht so, wie man es plant oder erwartet.
So ist es leider auch mit der Windows Suche. Stellt man die Freigaben (die später am Client gemappt werden) mittels einer Gruppenrichtlinie bereit, so kann es sein, dass die Windows Suche (genauer gesagt die entfernte Suche – Remote Search) von einem Arbeitsplatz aus nicht funktioniert. Das liegt daran, das die Freigabeberechtigungen nicht korrekt in der Registry hinterlegt werden, wenn die Freigaben per Gruppenrichtlinie erstellt werden!
Prüfung, ob die Windows Suche funktioniert:
von einem Arbeitsplatz aus
– (Netzwerklaufwerke sind verbunden)
– Windows Explorer öffnen
– Netzwerklaufwerk auswählen in dem gesucht werden soll und oben rechts im Windows Explorer den Suchbegriff eingeben
Die Suche sollte, je nach Datenbestand, recht schnell alle Ergebnisse auf einmal liefern.
Sollte das nicht so sein und die Suche „sucht sich einen Wolf“ (sprich, der grüne Balken in der Adresszeile des Windows Explorers findet kein Ende)
ist das ein Indiz dafür, das die Suche (Remote-Search) nicht so läuft, wie es eigentlich sein sollte.
(zeitgleich) am Dateiserver prüfen
– (am Arbeitsplatz, die Suche offen lassen)
– Computerverwaltung öffnen
– im Bereich ‚System‘ den Punkt ‚Freigegebene Ordner‘ öffnen und ‚Geöffnete Dateien‘ auswählen
– im Bereich ‚Geöffnete Dateien‘ sollten nun mindestens 2 geöffnete Verbindungen zur Named-Pipe namens \MsFteWds aufgelistet werden
–> dann ist alles in Ordnung und die Windows Suche funktioniert!
– dies sollte man unbedingt für alle Freigaben entsprechend testen!
Sollte dem aber nicht so sein, so funktioniert die entfernte Windows Suche zwischen Dateiserver und dem Arbeitsplatz nicht so wie sie sollte.
Dies kann unter anderem damit zu tun haben, das die Freigabeberechtigungen auf den Freigaben des Dateiservers nicht korrekt (durch die Gruppenrichtlinie, die die Freigaben erzeugen soll) in die Registry eingetragen wurden. Standardmäßig wird, wenn die Freigabe per GPO erstellt wird, die Systemgruppe ‚Jeder‘ mit ‚Vollzugriff‘ als Freigabeberechtigung gesetzt. Dies funktioniert soweit auch; die Nutzer können Dateien lesen und auch ändern/speichern/erstellen. Allerdings gilt dies nicht für den Dienst ‚Windows Search‘, der scheinbar die Registry tatsächlich auswertet.
Hierzu schauen wir uns die Freigabeberechtigungen (bei den Freigaben, die über eine GPO erstellt wurden) über die Computerverwaltung mal an. Öffnet man die ‚Eigenschaften‘ der Freigabe und wechselt den Tab zu ‚Freigabeberechtigungen‘, so stellt man fest, das die Berechtigung ‚Jeder‘ mit ‚Vollzugriff‘ augenscheinlich korrekt vergeben ist.
Prüft man nun aber den dazugehörigen Eintrag in der Registrierung, so stellt man fest, das dieser einfach fehlt!
– Registrierung mittels ‚regedit.exe‘ öffnen
– in den Zweig ‚HKEY_MACHNIE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares\Security‘ wechseln
– hier sollte es für jede Freigabe einen Eintrag geben
– fehlt dieser Eintrag vom Typ ‚REG_BINARY‘, so haben wir den ‚Übeltäter‘
Um diesen Fehler zu beseitigen, öffnen wir wieder die Eigenschaften der Freigabe über (oder es ist noch geöffnet) die Computerverwaltung ‚System\Freigegebene Ordner\Freigaben‘;
Wechseln auf den Tab ‚Freigabeberechtigungen‘ und ändern einfach die Berechtigung für ‚Jeder‘ (Vollzugriff weg – Übernehmen – Vollzugriff wieder auswählen – Übernehmen).
Diesen Schritt für alle betroffenen Freigaben wiederholen!
Danach prüfen wir, ob es nun einen Eintrag in der Registrierung (‚HKEY_MACHNIE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares\Security‘) für die Freigabe(n) gibt.
Die Windows Suche von einem Arbeitsplatz aus noch mal testen. Nun sollte der Kontakt zur Named-Pipe hergestellt werden und die Suche sollte funktionieren.
Good luck…
Hinweis: das oben Beschriebene sind Erfahrungen, die ich in einer Microsoft IT-Infrastruktur auf Basis von Windows Server 2008 R2 (SP1) gesammelt habe. Durch entsprechende Patchstände oder andere Installationen oder Editionen der Systeme kann es natürlich sein, dass das Verhalten der Systeme sich anders darstellt!