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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.