Christoph Vollmann

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

Schlagwort: SharePoint (Seite 1 von 3)

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.

Vorbereitung für SharePoint 2016 MinRoles: Suchkomponenten manuell verschieben

Nach der Installation des „Feature Pack 1“ (sprich dem November 2016 CU) für SharePoint 2016 ist es jetzt auch für kleinere Farmen möglich das MinRole-Konzept zu fahren.

Oft wurden diese Farmen aber mit der „traditionellen“ Herangehensweise aufgesetzt. So kommt es beispielsweise häufig vor, dass meine Kunden eine Verteilung von Suchkomponenten vorfinden. Auf Frontend-Servern habe ich klassischerweise bisher die Query- und Index-Komponenten platziert, während auf den App-Servern die Analytics, Crawl, Content Processing und Admin Komponente ihre Dienste verrichtet haben.

Bei der Konvertierung zu MinRoles gibt es daraufhin natürlich Probleme. Im Kern geht es darum, dass die Suchkomponenten jetzt überhaupt nicht mehr auf Frontend-Servern, sondern auf dedizierten Search Servern oder kombinierten Application and Search Servern zu platzieren sind.

Folgende Meldung bekam also mein Kunde:

„Sie müssen Suchkomponenten manuell verschieben, bevor Sie die Suchserverrolle in eine andere Rolle konvertieren.“

Verschieben der Suchkomponenten

Suchkomponenten im SharePoint zu verschieben oder auch zu erweitern folgt immer einem gleichen Prozess:

  1. Vorhandene Suchtopologie klonen
  2. Änderungen der Komponenten am Klon vornehmen
  3. Neue Suchtopologie aktivieren
  4. Alte Suchtopologie löschen

Bei der Verschiebung in diesem Fall ist aber daran zu denken, dass der Index nicht einfach gelöscht werden kann, sondern repliziert und dann vom alten Server entfernt werden muss. Faktisch habe ich dies bei dem Kunden mit allen Komponenten getan. Unser Plan lief also folgendermaßen:

  1. Vorhandene Suchtopologie klonen
  2. Neue Komponenten für Administration, Crawling, Analyse und Inhaltsverarbeitung auf dem App-Server erstellen
  3. Neue Suchtopologie aktivieren
    (An dieser Stelle gibt es die Komponenten von Web-Frontend-Server doppelt. Unter anderem wird aber auch der Suchindex repliziert – was mir sehr entgegenkommt)
  4. Nochmals die Topologie klonen
  5. Alle Komponenten auf dem Web-Frontend-Server entfernen
  6. Diese neue Topologie aktivieren
  7. Alle alten Topologien löschen

Mein PowerShell für diesen Fall (Die Servernamen sind natürlich zu ersetzen):

Danach finden sich alle Suchkomponenten auf dem App-Server.

Das ist Schritt 1 für diesen Kunden gewesen. Schritt 2 war die Verschiebung des Distributed Cache. Danach konnte die Konvertierung zu MinRoles durchgeführt werden.

In eigener Sache: MCSA für Office 365 geschafft

Heute habe ich meine zweite Prüfung zum Thema Office 365 abgelegt und darf mich jetzt offiziell MCSA für Office 365 schimpfen.

Nach dem es letzte Woche um das Managen von Identitäten und die lokale Anbindung ging, standen heute die Services selber im Vordergrund. Bei den Vorbereitungen ist mir aufgefallen, wie wenig man selbst doch von Exchange bzw. Skype for Business und deren Möglichkeiten wusste. Insbesondere die Möglichkeiten zur Lenkung von Inhalten in Exchange via MailTips, Transportregeln und DLP-Regeln haben mich ehrlich überrascht. Manches Thema, welches in der Vergangenheit von mir als SharePoint Berater mit SharePoint-Mitteln gelöst wurde, kann auch gut über andere Systeme gelöst werden, die einfach zukünftig zu meinem Portfolio zählen müssen.

Es wird klar, dass über den Tellerrand zu schauen in die kommende Arbeit hineingehört. Der reine „SharePoint Berater“ wird aussterben. Wenn ich nicht alle anderen Produkte und Services (gerade im Office 365- und Azure-Umfeld) mit in Betrachtung ziehe, bin ich in absehbarer Zukunft arbeitslos 🙂

Ich bin gespannt auf die Zukunft und freue mich darauf.

SharePoint 2016 Feature Pack 1: Anpassen des App Launchers

Das Feature Pack 1 für SharePoint 2016 ist veröffentlicht. Und zwar „getarnt“ als ein normales Update. „November 2016 PU“ trägt also jetzt den Codenamen „Feature Pack 1“.

Was steckt im Pack? Wie auf vielen Blogs zu lesen zumindest schon einmal eine wichtige Funktion: MinRoles umfassen jetzt auch die Kombination von „Frontend und Distributed Cache“ sowie „Application und Search“, was es für viele (wenn nicht gar alle) meiner Kunden leichter macht auf das MinRole-Konzept zu setzen ohne mindestens 4 SharePoint-Server im Einsatz zu haben.

Aber noch eine wichtige Funktion wurde ergänzt: Der App Launcher kann jetzt auch angepasst werden, ohne dass man ein Hybrid-Szenario mit Office 365 fahren muss.

Im folgenden möchte ich kurz zeigen, wie es zu aktivieren ist und welche Möglichkeiten sich ergeben.

Aktivierung des Features

Zunächst gibt’s ein passendes Feature, welches per PowerShell auf der Webanwendung aktiviert wird, auf der man die Tiles für den App Launcher verwalten will. Also:

Danach gibt es eine versteckte Liste, die über https://<deine-adresse>/Lists/Custom%20Tiles aufrufbar wird.

In dieser Liste werden die Links eingetragen, die im App Launcher erscheinen sollen. Die Liste verlangt zwingend eine Symbol-URL. Hierzu zwei Tipps.

  1. Wo bekomme ich passende Symbole her?
    Dazu nutze ich gerne das Metro Studio von Syncfusion. Das hat wirklich eine super Auswahl an „flachen“ Metro-Symbolen. Einfach das gewünschte Symbol mit Hintergrund Transparent exportieren.
  2. Wo speichere ich das Symbol?
    Es muss ein Speicherort sein, der von allen Nutzern gelesen werden kann, die auch den App Tile sehen werden. Also in meinem Fall einfach die Websiteobjekt-Bibliothek auf der Startseite. In Deinem Fall vielleicht eine Bibliothek innerhalb des Intranets o.ä.

Weiterhin kann ich hier auch noch eine Zielgruppe angeben. Diese unterscheidet sich im Vergleich zu bekannten SharePoint-Zielgruppen in einem entscheidenen Punkt: Ich kann auch AD-Gruppen angeben.

Ich sehe nur, was ich benutzen kann

Ein passendes Beispiel dazu: Ich habe eine Active Directory-Gruppe gebildet, die Zugriff auf eine bestimmte Fachanwendung haben. Diesen Nutzern kann ich jetzt einen Link im App Launcher präsentieren und ihn auf genau diese Gruppe einschränken. Nur Nutzer, die Mitglied in dieser Gruppe sind, sehen diesen App Tile und haben überhaupt Zugriff auf die Anwendung.
So erstelle ich für alle Nutzer ein passendes, angepasstes „Web-Startmenü“.

Gut. Wir speichern den Link. In diesem Fall ein Link zu diesem Blog:

 

Nach dem Speichern sehe ich erstmal nichts. Der Browser cached dieses Menü und auch ein „force-reload“ lässt ihn nicht neu laden. Im Developer-Menü (egal, ob Firefox, Chrome, IE oder Edge immer über F12 erreichbar) kann ich den JS-Befehl ClearSuiteLinksCache()  über die Konsole absetzen (Alle anderen Nutzer dürfen bis zu 24 Stunden warten!). Danach erscheint meine Kachel:

App Launcher überall gleich? Noch nicht.

Gut. Klappt ja. Nun ein Blick von einer anderen Webanwendung aus. Hier von der MySite:

Na klasse. Der App Launcher zeigt immer noch die normalen Tiles. Auch das Cache leeren bringt nichts.

Faktisch muss ich jeder Webanwendung mitteilen, wo meine Custom Tiles liegen. Das kann ich – wie so oft – über die PowerShell erreichen:

Leider ist es in diesem TechNet-Artikel genauso beschrieben, aber bisher bringt das nicht den gewünschten Erfolg.
Ich werde mich nochmal damit beschäftigen.

Für Hinweise wäre ich sehr dankbar!

SharePoint Entwicklungsfarm hoch- und runterfahren

Ich war gerade nochmal „kreativ“ und habe mir ein Skript gebaut, mit dem ich meine Hyper-V Maschinen für die SharePoint Farm zuhause hoch- und runterfahren kann.

Es beachtet die korrekte Reihenfolge. Erst geht die Basis rauf – also das AD und in meinem Fall der Router zum Netz, danach der SQL und dann die SharePoint VMs.

Das möchte ich euch natürlich nicht vorenthalten. Bitte ersetzt die Maschinen-Namen einfach durch eure eigenen Namen.
Die 10 Sekunden Wartezeit nach dem Start eines Blocks solltet ihr ggf. auch an eure Umgebung anpassen (bei manchen wird ein Start vielleicht länger dauern, andere hatten mehr Geld für ihre Workstation/Server als ich 😉 )

Ältere Beiträge

© 2017 Christoph Vollmann

Theme von Anders NorénHoch ↑