Christoph Vollmann

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

Monat: November 2016

♫ 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ß 😀

Fokus auf die Plattform

Momentan bin ich mit der COMPAREX SharePoint Roadshow unterwegs in verschiedenen Städten Deutschlands (diese Woche noch in Düsseldorf und in Hamburg).

Ein Thema, welches ich behandle, sind mobile Anwendungen für SharePoint. Prinzipiell gibt es ja tausend Möglichkeiten mobile Anwendungen für SharePoint zu erstellen (Auf der Roadshow spreche ich über die neueste Möglichkeit – nämlich PowerApps und Flow). Dabei steht eine grundsätzliche Überlegung im Vordergrund: Der Fokus auf die Plattform.

Was heißt „Fokus auf die Plattform“?

Zwei Kernaussagen stecken dahinter: Die Konzentration der Geschäftslogik hin zum SharePoint sowie die ausschließliche Datenhaltung innerhalb der SharePoint Plattform.

Beides sind, wenn man sie genauer betrachtet, extreme Aussagen. Sie haben bereits Dateifreigaben in ihrem Unternehmen. Auch Spezialanwendungen und -datenbanken sind sicherlich im Einsatz. Dieses können, werden und sollten Sie nicht zu SharePoint migrieren. Bei Dateifreigaben ist das wünschenswert, aber eine komplette Migration in den SharePoint ist beispielsweise für ISO-Dateien, Images von virtuellen Maschinen oder allgemein „Ausführbare Dateien“ wenig sinnvoll.

Weiterhin sind die Kosten, eine Spezialanwendung auf SharePoint-Basis neu zu implementieren meist zu hoch – es fehlt schlicht am sinnvollen ROI.

Aber: Was bereits heute mit SharePoint möglich ist, ist das Durchsuchen von allen möglichen Daten und Datenquellen innerhalb und außerhalb des Unternehmens. Sowohl Dateifreigaben, Webseiten, externe Datenbanken, usw. lassen sich ganz wunderbar in einem Suchindex vereinen und können von dort aus über eine einheitliche Schnittstelle abgegriffen werden.

Business Logik – ditto. SharePoint ist eine offene Plattform. Eine ganze Reihe von standardisierten Schnittstellen steht jedem Entwickler und jedem Anwender zur Verfügung. Sollte also die Business Logik nicht direkt im SharePoint implementiert worden sein, so finde ich, dass es ein erstrebenswertes Ziel ist zumindest Trigger für diese Logik über SharePoint geben zu können. Auch hier helfen Web-Requests und die Workflow Plattform (egal ob 2010 oder 2013) weiter.

Warum der Fokus?

Mit der Einführung von PowerApps und Flow wird eines deutlich. In Zukunft wird es noch mehr Möglichkeiten geben, SharePoint und SharePoint Inhalte auf verschiedenste Geräte zu übertragen, darzustellen und zu verändern. Stelle man sich jetzt vor, dass jede Möglichkeit die man nutzt auch bedeutet die Geschäftslogik zu implementieren, hat man für jede Anpassung dieser Logik massiven Aufwand vor sich. Diesen kann und sollte man vermeiden.

Die von Microsoft bereitgestellten Anwendungen arbeiten natürlich mit einer Vielzahl von Schnittstellen. Meines Erachtens ist die Verbindung zum SharePoint allerdings die mächtigste. Wo sonst können Sie Daten und Dateien umfangreich anreichen, Inhalte aus tausenden Quellen durchsuchen, Versionierung abbilden, Unternehmensstrukturen unterstützen, Projekte managen und all das noch mit externen Partner zusammen erledigen. Ich würde eine PowerApp heute nutzen, um Inhalte aus dem SharePoint zielgerichtet für meine Mitarbeiter auszuspielen. Weiterhin liegt der größte Nutzen von Flow darin, dass ich von SharePoint generierte Inhalte wunderbar verteilen kann sowie Inhalte aus externen Quellen jetzt noch leichter an meinen SharePoint bringen kann.

Wer zukünftig auf diese neuen Technologien nicht verzichten möchte und den Aufwand zur Einführung der selben möglichst gering halten will, hat meines Erachtens nur eine Chance, wenn er sich auf eine Plattform (namentlich SharePoint) konzentriert. PowerApps alleine werden nämlich – wer hätte es gedacht – auch nicht das Allheilmittel für alle Ihre Anforderungen an eine mobile Anwendung sein. Sich darauf zu versteifen die PowerApp mit möglichst viel Logik auszustatten wird sich als Sackgasse herausstellen.

Backup aller Websitesammlungen erstellen

Backup allgemein

Seine SharePoint Farm zu sichern ist natürlich essenziell. SharePoint bietet dafür Möglichkeiten via „Backup-SPFarm“ ein passendes Backup zu erstellen, auch viele Drittanbieter bieten Lösungen an.

Einzelne Websitesammlungen

Manchmal ist es allerdings notwendig, einzelne Websitesammlungen statt einer kompletten Inhaltsdatenbank wiederherzustellen. Dafür kann der Befehl „Backup-SPSite“ resp. „Restore-SPSite“ genutzt werden.

Und jetzt: Automatisieren

Um ein regelmäßiges Backup zu erstellen, habe ich hier ein Skript zusammengestellt, welches alle Websitesammlungen einer Farm sichert. Wahlweise mit dem Datum und der Uhrzeit als Prefix.

Hier also das Skript:

Aufzurufen ist das Skript mit mindestens einem Parameter:

Beispielhafte Ausgabe:
backupallsites

Das Ergebnis im Dateiverzeichnis:
backupallsites_files

Dieses Skript kann man beispielsweise auch in die Windows Aufgabenplanung übernehmen und so neben den regelmäßigen Farm-Backups auch ein Backup aller Sammlungen in einzelnen Dateien sichern.

P.S.: Jetzt muss ich nur noch die MySites herausfiltern – Update folgt 🙂

Aktuelles Patch-Level ermitteln und lesbar ausgeben

Dank der großartigen Arbeit von Nauplius, die eine Sammlung der Updates+API pflegen, gibt’s jetzt eine sehr simple Möglichkeit das aktuelle Patchlevel der SharePoint Farm zu prüfen.

In diesem Skript wird die API von https://sharepointupdates.com/ genutzt, um eine lesbare Versionsbezeichnung der Farm zu bekommen. Sollte man dieses Skript nicht auf einem SharePoint Server ausführen können oder wollen, reicht es auch als Parameter die $BuildVersion anzuführen.

Beispielhafter Aufruf:

Ausgabe:

getcurrentpatchlevel

Ich hoffe, es hilft dem ein oder anderen weiter. Für Verbesserungsvorschläge bin ich immer dankbar.

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 ↑