Freigeben über

Patchen - Aber bitte Richtig!

  • Artikel

Das „Patchen“ einer Produktivumgebung
erweist sich immer wieder als durchaus knifflige Angelegenheit.

Ein eingespielter Patch kann nicht wieder entfernt werden.
Die Eingriffe und Änderungen beziehen sich auf das gesamte System und haben zu viele Abhängigkeiten um eine De-Installation in einem zeitlich vertretbaren Rahmen möglich zu machen.

Und dennoch! Allen Spruchweisheiten trotzend (Vorsicht ist die Mutter der Porzellankiste) spielen einige "Mutige" (no Risk -> no Fun) die neuesten Patches scheinbar gedankenlos in die Umgebung und erleben dann unter Umständen eine böse Überraschung.
Obwohl "Murphys Gesetze" hinreichend bekannt sind, wird mal eben das Wochenende genutzt um das System auf den neusten Stand zu bringen.

Ein Beispiel aus der Praxis: Ein junger Admin wollte einen Patch auf einer virtuellen Maschine austesten. Ohne jegliches Backup spielte er den Patch auf der virtuellen Maschine ein. Der Test ging schief. Kein Problem, dachte sich der junge Admin, nehme ich mir doch eine neue "virtuelle Maschine". Bis hierhin keine Schwierigkeit. Doch als die neue Maschine denselben Fehler zeigte wurde er blass. Er hatte nicht bedacht, dass die Datenbanken auf einem physikalischen Server liegen welche aus den virtuellen Maschinen angesteuert werden. AUTSCH! 

Hintergrund
Microsoft prüft Patches vor Auslieferung. Doch beschränkt sich das Testen auf behobenen Fehler und grundsätzliche Funktionen einer Standard-Installation. Individuelle Kundenumgebungen sowie der Einfluss der Patches auf 3rd-Party Applikationen werden nicht getestet. So können zum Beispiel individuelle Anpassungen, manuell oder durch zusätzliche Software, Nebeneffekte bekommen.

Daher gilt: Prüfen Sie vor dem Einspielen ob Ihr Testsystem an einen separaten SQL Server bzw. eine gesonderte SQL Instanz angebunden ist um ggf. unschöne Nebenwirkungen auf Ihrem Produktiven SQL Server zu vermeiden.

  • Behebt der Patch das Problem wirklich?
  • Lässt sich der Patch ohne Probleme installieren?
  • Ist das System nach Installation des Patches komplett funktionstüchtig?

Trotzdem!
Selbst wenn der Patch in der Test/Development-Umgebung fehlerfrei angewendet und getestet werden konnte besteht immer noch ein Risiko in der Produktionsumgebung. Denn aus Erfahrung wissen wir, dass sich Test- und Produktivumgebung oftmals in Größe und / oder Design unterscheiden.

Regeln und Grundsätze

  • Das Produkt „Project Server“ setzt auf SharePoint Server auf und ist somit von SharePoint abhängig. Unsere Empfehlung ist daher den SharePoint-Server ebenfalls auf den gleichen Patch-Level zu bringen. Gleiches gilt unbedingt für die Project Professional Installationen in Ihrer Umgebung.

  • Ein Hotfix sollte nur zur Anwendung kommen, wenn damit auch wirklich ein Fehler behoben werden kann. In vielen Fällen kann der Admin "warten" bis zum nächsten Service Pack. Die Patch-Struktur ist seit langem "kumulativ". Dann braucht nur der letzte Patch angewendet werden.
    Weiterführende Informationen finden Sie auf dem Blog von Stefan Gossner:
    https://blogs.technet.com/b/stefan_gossner/archive/2013/03/21/common-question-what-is-the-difference-between-a-pu-a-cu-and-a-cod.aspx

  • Den Patch vorher Testen
    Eine Kopie der Produktionsumgebung in eine Test/Development-Umgebung überführen. Dort den Patch einspielen. Prüfen ob der Patch ohne Probleme angewendet werden kann (Fehler dringend beachten, Event-Log, ULS-Log, Error-Log).
    Ein konkreter Zeitplan mit allen Aktivitäten, Risiken und "Was-wäre-wenn" Szenarien ist sehr hilfreich, sowie wie die Planung und Bekanntgabe einer „System Downtime“ an die Endbenutzer.

  • Die Test-Umgebung nach einem vorgegebenem Plan systematisch Testen
    Es ist nicht ausreichend zu prüfen ob ein bereits aufgetretener Fehler vor dem Patch nun behoben ist. Ein Test-Team sollte nach einem Testplan systematisch das System untersuchen.

  • In einer vorgegebenen Reihenfolge die Systeme Patchen
    Der Blog-Eintrag unseres Kollegen Steve Chen sollte beachtet werden:
    >>>>> 
    Recommended Update sequence of packages: As commented by the escalation folks at Microsoft, it should be sufficient to apply only the SharePoint Server2010 “Uber” packages (aka MOSS14; SPS2010) as these contains the SharePoint Foundation packages (aka WSSv4; MSF2010) as well. But still there is a recommendation to stick on the "old common" approach...

    Extract:   Best practice (this is my opinion and is the result of daily support challenges and issues, that are related to this process!) For any given build you may find that it is not necessary to install a SharePoint Foundation 2010 update before you install a SharePoint Server 2010 update.

    This flexibility in the installation sequence is part of the software update system design. However, there might be times where it is necessary to remove this flexibility in order to properly fix a specific issue.
    I personally recommend that you always install SharePoint Foundation 2010 patches before installing SharePoint Server 2010 patches.

    This best practice ensures that you will always be successful when installing updates and keeps you on the save side.

    Install Order
    - start with the Foundation update
    - then run the Psconfig wizard 
    - reboot if prompted 
    - install now the server packages 
    - then run the Psconfig wizard again 
    - reboot once more if prompted 
    - check for errors on logs! 
    - check on Central admin page -> Upgrade and Migration -> Upgrade status / product and patch installation status

    Repeat this for each server in farm.

    As per this Link now: https://technet.microsoft.com/en-us/sharepoint/ff800847.aspx "...it is no longer necessary to install the SharePoint Foundation cumulative update and then install the SharePoint Server cumulative update."
    Well yes, its true and you can do so if it is more applicable for your Environment. but I still may recommend to follow as above to keep the best consistency for any updates as well for future. But yeah, if you don't want to go the extra step, for common CU updates, the server package (SharePoint) or the full Project Server package suffices all your needs, ;-)
    <<<<< 
    Quellen: https://technet.microsoft.com/en-us/sharepoint/ff800847.aspx, https://blogs.technet.com/b/steve_chen/archive/2010/09/29/build-numbers-cube-sheet-for-sharepoint-2010.aspx#updatesequence

Was kann alles schief gehen?
Grundsätzlich birgt das Patchen einer Project Server Farm Risiken in sich die jedoch durch vorheriges Testen der Patchinstallation auf einem dedizierten Testsystem minimiert werden können. Jeder Patch schreibt eine ausführliche Log-Datei. SharePoint-Server und Project-Server legen die Log-Dateien in den Pfad des ULS-Logs. Das lokale Event-Log ist ebenfalls eine wichtige Quelle.

Links und Weiteres
SharePoint Patch Reference
https://blogs.msdn.com/b/josrod/archive/2013/06/12/sharepoint-patch-reference.aspx
Office SustainedEngineering
https://blogs.technet.com/b/office_sustained_engineering/?Redirected=true
Deploy software updates for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc263467.aspx
Software updates overview for SharePoint 2013
https://technet.microsoft.com/en-us/library/ff806329.aspx
Install a software update (SharePoint 2013)
https://technet.microsoft.com/en-us/library/ff806338.aspx
Updates for SharePoint 2010 Products
https://technet.microsoft.com/en-us/sharepoint/ff800847.aspx
10 Best Practices and Recommendations
https://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=453