Nachdem ich jetzt ein paar Testinstallationen von SharePoint durchgeführt habe, wollte ich kurz meine ersten Erfahrungen festhalten.
Die Installationsroutine von SharePoint 2013 verläuft an sich genauso wie die Installationen von SharePoint 2010. Ebenso hat sich die Oberfläche der Zentraladministration (vom Metro-Style mal abgesehen) nur marginal verändert und die Implementierung der Dienstanwendungen verläuft ebenfalls nahezu analog zu SP2010. Die verantwortlichen Personen wird es freuen, da die Einarbeitung doch deutlich vereinfacht wird. Das heißt allerdings auch, dass die “Problemkinder” (z.B. der Benutzerprofildienst oder die Suchdienstanwendung) weiterhin Kopfschmerzen verursachen können und werden.
Einer meiner ersten Schritte bei der Konfiguration einer SharePoint Infrastruktur ist das Aufsetzen der Suchdienstanwendung. Dies kann, je nach vorhandener Infrastruktur durchaus auch mal länger dauern. Hier gibt es verschiedene Ansätze, die Dienstanwendung zu implementieren:
- Der Konfigurationsassistent: Sinnvoll für Entwicklungsumgebungen aber in einer Produktionsumgebung nicht empfehlenswert. Es können beispielsweise keine eigenen Datenbanknamen oder Application-Pools vergeben werden. Dies sollte nur im Notfall, wenn wirklich nichts anderes mehr geht, verwendet werden.
- Die Zentraladministration: Mein bevorzugter Weg. ich bin da doch sehr GUI-lastig…
- Über Powershell: Sehr gut geeignet, wenn man schnell eine komplette Konfiguration hochziehen muss. Zusätzlich kann es die Konfiguration standardisieren und Flüchtigkeitsfehler können vermieden werden.
Ich habe mich, wie man bereits aus Punkt 2 erahnen kann, für die Konfiguration über die Zentraladministration entschieden. Dort fällt zunächst auf, dass sich die Dienste-Liste für die Suche verändert hat.
Es fehlt z.B. der Dienst für die SharePoint Foundation Suche, der manchmal doch für etwas Verwirrung gesorgt hat. Stattdessen gibt es nur einen “SharePoint Server Search”-Dienst. Versucht man diesen zu starten (analog zur Konfiguration von SharePoint 2010), erscheint folgende Fehlermeldung:
OK – der Start des Dienstes erfolgt also automatisch bei der Installation der Dienstanwendung. Dies geschieht wie gewohnt über “Application Management” –> “Manage Service Applications” –> “New” –> “Search Service Application”
Darauf folgt der ebenfalls bekannte Dialog zur Übergabe der Konfigurationsparameter wie z.B. Application Pool.
Im ersten Augenblick und beim ersten Durchklicken also alles wie gehabt, oder etwa doch nicht? Dem einen oder anderen Administrator werden sich spätestens beim Blick in das SQL Management Studio “die Haare zu Berge” aufstellen. Es gab während des Konfigurationsprozesses über die SharePoint Zentraladministration nämlich keine Möglichkeit, Datenbank-Namen zu vergeben… Dies äußert sich dann so, dass die “ungeliebten” GUIDs automatisch an die Datenbanknamen angehangen werden und im SQL Management Studio sieht das dann wie folgt aus:
Das gleiche Bild zeigt sich auf der Verwaltungsseite der Dienstapplikation (wenn es anders wäre, hätte ich mir auch Gedanken gemacht) nachdem die Suchdienstanwendung erfolgreich bereitgestellt wurde.
Die Frage, die sich nun stellt, ist natürlich: “Wie gebe ich saubere Datenbanknamen für die Suchdienstanwendung an?” – Die Antwort lautet natürlich: “PowerShell”. Eine etwas komplexere Anleitung kann hier gefunden werden.
Ich persönlich hoffe, dass dies erst mal noch ein Beta-“Feature” ist und man in der finalen Version die Datenbanknamen auch wieder über die Weboberfläche der Zentraladministration angeben kann, zumal eigentlich alle anderen Datenbanknamen über die Zentraladministration konfiguriert werden können. Ansonsten bleibt nur das o.g. PowerShell-Skript.
Wozu werden die Datenbanken nun von SharePoint benötigt:
- Search_Service_Application_DB: Die Datenbank speichert alle Konfigurationselemente, wie z.B. Inhaltsquellen, Crawl-Regeln oder die Suchtopologie.
- Search_Service_Application_AnalyticsReportingStoreDB: Die Datenbank speichert alle Userinteraktionen mit den Suchergebnissen, steuert die Relevanzeinstellungen und stellt Suchberichte bereit.
- Search_Search_Application_CrawlStoreDB: Speichert die gecrawlten Ergebnisse zwischen, bis diese im Index landen
- Search_Service_Application_LinkStoreDB: Speichert beispielsweise phonetische Variationen für die “People Search”, speichert und stellt Informationen über Links und die zugehörigen URLs bereit, führt eine Spracherkennung aus sobald der Index erstellt wird, analysiert die Dokumente und stellt das Property-Mapping her.
Dies war der erste kleine Wehrmutstropfen der neuen SharePoint Installation – ich denke, damit kann man leben…