Christoph Vollmann

Erfahrungen und Tipps für Office 365 und SharePoint aus dem Berater-Leben

Schlagwort: SharePoint 2013

WordPress-Blog in die SharePoint Suche integrieren

SharePoint hat wohl eine der mächtigsten Suchengines am Markt. Nicht nur eine Einbindung von Quellen wie der SharePoint Farm selbst oder der internen Dateifreigabe in die Suche macht Sinn. Auch externe Quellen lassen sich bestens integrieren.

Zwei Möglichkeiten stehen dafür zur Wahl: Entweder man indexiert die Quelle selber mit Hilfe der SharePoint Suche, oder das „externe System“ beherrscht den OpenSearch Standard.

WordPress ist ein solches System, welches diesen Standard unterstützt. Um WordPress Blogs in die SharePoint Suche zu integrieren, sind folgende Schritte sinnvoll:

Anlage einer neuen Ergebnisquelle

Erster Schritt ist die Anlage einer neuen Ergebnisquelle. Dies ist über die Zentraladministration möglich.

  1. Auswahl der Suchdienstanwendung in der Dienstanwendungsübersicht
  2. In der Suchdienstanwendung auf „Ergebnisquellen“ klicken und „Neue Ergebnisquelle“ wählen
  3. Folgende Daten sind zu ergänzen:
    1. Name:
      Ein passender Name für den Blog (Ich habe einfach nur „Blog“ gewählt)
    2. Protokoll:
      OpenSearch 1.0/1.1
    3. Abfragetransformation:
      {searchTerms}
    4. Quell-URL – Hier wird es wichtig:
      Für WordPress nimmt man die Blog-URL und hängt „/feed/?s={searchTerms}“ an.
      Für diesen Blog also:

      {searchTerms} wird später durch den Suchbegriff durch SharePoint ersetzt. Die URL kann man natürlich vorher testen. Einfach {searchTerms} durch einen Begriff ersetzen und im Browser aufrufen: https://christoph.vollmann.co/feed/?s=SharePoint
    5. Anmeldeinformationen:
      Sollte der Blog aus dem Netz ohne Login erreichbar sein, reicht hier ein „Anonym: Diese Quelle erfordert keine Authentifizierung.“
  4. Das Ganze speichern. Im Ergebnis sollte es jetzt eine neue Quelle unter „Für diesen Suchdienst definiert“ geben:

Erstellung einer neuen Ergebnisseite im Suchcenter

Um diese Quelle nun zu nutzen stehen zwei Wege zur Verfügung. Weg Eins ist es, diese Quelle als neue Ergebnisseite im Suchcenter bereit zu stellen.

Dafür wechselt man in das gewünschte Suchcenter und geht dort in die Websiteinhalte in die Bibliothek „Seiten“.

In der Bibliothek erstellt man eine neue „Willkommenseite“ mit dem gewünschten Namen (das Seitenlayout in einem Suchcenter ist immer „Suchergebnisse“ – genau das was wir wollen)

Die neue Seite erscheint in der Bibliothek und kann jetzt bearbeitet werden:

Konfiguration der neuen Ergebnisseite

 

Im Bearbeitungsmodus passt man jetzt den WebPart „Suchergebnisse“ an:

 

Im WebPart-Menü wählt man „Abfrage ändern“:

Im Dialogfeld wählt man nun unter „Wählen Sie eine Abfrage aus“ die neue Quelle, Speichert die WebPart-Konfiguration und speichert dann die Seite ab:

Test

Nach Eingabe eines Begriffs sollten nun Ergebnisse aus dem Blog erscheinen:

Einbindung in die Suchnavigation

Nach Anlage der neuen Suchergebnisseite wechselt man nun in die Websiteeinstellungen auf „Sucheinstellungen“:

Dort kann die Navigation im Suchcenter unter „Suchnavigation konfigurieren“ und „Hyperlink hinzfügen“ erweitert werden:

Das Ergebnis

Die Suchergebnisseite steht nun allen Nutzern zur Verfügung um Blog-Ergebnisse zu finden.

Ein Suchbegriff, der einen Nutzer zum Bereich „Alles“ führt, wird übernommen, wenn er auch „Blog“ klickt.

Einbindung von Ergebnissen in die Standard-Suche

Zusätzlich zu eigenen Ergebnisseite kann diese Quelle auch in die normalen Suchergebnisse integriert werden.

Dazu erscheint bald ein eigener Artikel.

Unterschiede bei der Einbindung mit OpenSearch und eigener Indexierung

Ein Hinweis ist mir noch wichtig: Die SharePoint Suche indexiert bei dieser Methode die Inhalte des externen Blogs nicht!

Die Suche schickt die Anfrage an den Suchdienst von WordPress. Das heißt einerseits, dass keinerlei Platz für den Index der Inhalte auf SharePoint Seite vorgesehen werden muss, aber andererseits die Qualität der Ergebnisse auch vollständig von der externen Quelle abhängig sind.

Kurz: Wenn die OpenSearch-Schnittstelle Schrott-Ergebnisse liefert, dann kann SharePoint auch nur Schrott-Ergebnisse verarbeiten und anzeigen.

♫ Don’t bring me down ♫ – Windows Update feat. SharePoint

Gestern war es soweit. Nach dem viele meiner Kollegen und ich seit langer Zeit erklären wie und wann man SharePoint Updates am vernünftigsten installiert und dass SharePoint Updates bitte, bitte, bitte nicht automatisch mit Windows Update verteilt werden sollen, ist es heute einem meiner Kunden dann doch passiert. In der Mail beschrieb er, dass ein Systemadministrator einen SharePoint Server aus einer 3-Server-SharePoint 2013-Farm fälschlicherweise für einen der normalen Webserver hielt und es deshalb für sinnvoll erachtete alle ausstehenden und freigegebenen Updates zu installieren. Hier fanden sich auch noch ausstehende SharePoint Updates.

Das Ergebnis auf einem SharePoint Server, dessen WSUS-Quelle nicht von Office-Patches für die Server bereinigt worden ist? Genau:

Updateverlauf

Updateverlauf mit SharePoint Patches

Es sieht nicht schlimm aus, aber wenn man bedenkt dass (1.) diese drei oben sichtbaren SharePoint Patches bei der Installation eine Downtime dieses Servers von ca. einer halben Stunde verursacht haben (u.a. ist der IIS während der Installation abgeschaltet) und (2.) die beiden anderen Server diese Updates noch nicht bekommen haben und auch noch nicht bekommen haben sollten?!

Es kann passieren, es ist passiert, was nun?

SharePoint folgt einem Motto aus einer – zum Glück – längst vergangenen Zeit: „Vorwärts immer, rückwärts nimmer“

SharePoint Updates lassen sich nicht mehr deinstallieren – zumindest nicht, wenn bereits eine SharePoint Farm im Einsatz ist und nicht nur Binär-Dateien installiert worden sind. Bei meinem Kunden läuft bereits eine Farm – dafür bin ich schließlich da.

Dieser eine von drei Servern wartete jetzt auf den zweiten Schritt, der Ausführung des Products Configuration Wizards (das hatte ich im Artikel „SharePoint Update ABC: Eine Orientierung für Orientierungslose“ im COMPAREX-Blog bereits hinlänglich erklärt).

Das eigentliche Wartungsfenster für die Farm „öffnet“ sich aber erst in rund 14 Tagen.  Eine weitere Downtime der anderen SharePoint Server – sowohl die Downtime während der Installation der Updates sowie die anschließende Downtime bei Ausführung des Wizards – ist nicht geplant und vor Allem mit den Anwendern der Plattform nicht kommuniziert.

Was habe ich getan?

Be brave. Ich habe den Wizard noch nicht ausgeführt, auch die Updates für die anderen Server habe ich noch nicht eingespielt. Ich halte es für das Beste bis zum Wartungsfenster abzuwarten und dann erst alle anderen Server mit Updates zu versorgen, mit dem Ziel danach wieder eine gleichmäßig gepatchte SharePoint Farm vor mir zu haben. Dieses Mal dann allerdings in einer etwas anderen Abfolge:

  1. CU (Alter: Heute minus 2 Monate) auf allen SharePoint Servern installieren.
  2. Fehlende Sicherheitsupdates, die via Windows Update schon auf einem der Server installiert sind, auf den restlichen Servern installieren.
  3. Configuration Wizard auf allen Servern nacheinander ausführen – beginnend mit dem Application-Server mit Zentraladministration.
  4. Tests und Sicherstellen der Funktionalität
  5. Ernstes Wort mit dem Administratoren-Team reden!

Bis zu diesem Zeitpunkt schimpft die SharePoint Farm allerdings über ihre missliche Situation:

installation_required

Da muss sie jetzt durch – denn Funktionseinschränkungen konnte ich dadurch zunächst keine beobachten.

Gibt’s Ideen? Bessere Ansätze für das Problem? Ähnliche Erfahrungen? Ich möchte es gerne wissen!

P.S.: ♫ Don’t bring me down, no no no no no ♫? Viel Spaß 😀

Upgrade aller Inhaltsdatenbanken

Während der Installation von Updates für SharePoint 2016 bekam ich die Meldung, dass das Upgrade nicht abgeschlossen werden konnte.

Die Meldung lautete:

Microsoft.SharePoint.Upgrade.SPUpgradeException: The upgraded database schema doesn’t match the TargetSchema

Das Problem lässt sich lösen, in dem alle Inhaltsdatenbanken via PowerShell aktualisiert werden. Hier das passende Skript dazu:

Danach den Configuration Wizard nochmals starten und das Upgrade durchführen.

© 2017 Christoph Vollmann

Theme von Anders NorénHoch ↑