Patchprozess

Es wurde schon viel über Patch-Management geschrieben und auf der Seite Update und Patchmanagement habe ich selbst schon technische Details veröffentlicht. Diese Seite widmet sich mehr dem organisatorischen Aspekt eines Patch-Managements.

Die Seite ist noch nicht ganz fertig

Microsoft veröffentlicht in regelmäßigen Abständen Aktualisierungen für Windows, Exchange, Forefront und andere Komponenten, die unsere Server betreffen. Auch andere Hersteller (z.B. HP Firmware, Netzwerkkartentreiber, SCOM-Agenten) werden gelegentlich aktualisiert.

Gerade wer Cluster einsetzt, sollte seine Server nicht "automatisch" nachts aktualisieren und rebooten lassen. Das macht sich nicht gut, wenn alle Clusterknoten zur gleichen Zeit "offline" gehen. Exchange Updates benötigen zudem eine bestimmte Reihenfolge der Rollen. Daher ist ein „Automatisches Patchen“ auf jeden Fall zu unterbinden. Eine zentrale Patch-Lösung kann aber die Server inventarisieren und ausstehende Patches melden bzw. zur Installation anbieten. Da sich auf dem Server selbst in der Regel kein Administrator anmeldet, wäre auch ein Reporting oder eine Benachrichtigung per Mail (Ausstehende Updates auf Server xxx) wünschenswert

Zudem sind die verschiedenen Updates zu unterscheiden in

  • Dringende Updates
    Diese beheben Sicherheitslücken oder grobe Fehler, die möglichst umgehend eingespielt werden sollen.
    Es kann auch dringende Updates für Exchange geben, die einen Fehler eines vorhergehenden Updates beheben
    Diese Updates sollten umgehend bewertet und vom Ergebnis abhängig umgesetzt werden
  • Normale Betriebssystem Updates
    Werden zu geplanten Patch-Zeiten installiert
  • Exchange Updates
    Diese sind nicht mit den Windows Updates synchron, sondern werden vom Exchange Team veröffentlicht. Oft lösen Sie allgemeine Fehler, die nicht häufig sind. Manchmal betreffen Sie aber auch kritische oder Lastprobleme, z.B. insbesondere mit mobilen Endgeräten. Dann kann eine Installation schneller ratsam sein. Dies ist individuell zu prüfen.
  • Patternfiles (Antivirus, Endpoint Protection)
    Werden automatisch verteilt und installiert.

Es müssen nicht immer alle Updates zeitgleich eingespielt werden. Es kann durchaus ratsam sein, wenige dringende Updates vorzuziehen und die normalen Updates zu einem länger geplanten Termin zu installieren.

Updates für Virenscanner o.ä. werden hingegen laufend automatisch installiert. Wenn ein Update veröffentlich wird, sollte umgehend bewertet werden, wie „Dringend“ es für die eigene Umgebung ist. Ohne Dringlichkeit kann die Installation durchaus verzögert werden um z.B. von Problemen anderer Installationen zu profitieren.

Bewertung der Patches

Sobald ein neues Update für eine installierte Komponente veröffentlich sind, startet ein Evaluierungsprozess

  • Bewertung bezüglich der Dringlichkeit
    Wird ein Sicherheitsloch gefixt, welches ein Risiko für die Umgebung darstellt ?
    Wird ein Softwareproblem gefixt, welches nicht warten kann (z.B. Gefahr Datenverlust oder Ausfall)
    Wird ein aktuelles Problem gefixt
    Gibt es Abhängigkeiten zu beachten (z.B. Exchange Update und Antivirus/Backup)
  • Bestimmen der Dringlichkeit
    • Dringend
      -> Installation innerhalb von 7 Tage „Rapid Deployment“
    • Normal
      -> Patch wird am nächsten geplanten Termin installiert. In der Regel innerhalb von 3 Monaten

Patch-Reihenfolge

Generell sollten Updates IMMER zuerst in einem Testfeld installiert werden. Damit ist sichergestellt dass Updates dort auf ihre Tauglichkeit und Abhängigkeiten der individuellen Konfiguration getestet werden können.

Zudem ist damit sichergestellt, dass das Testfeld immer aktueller oder den gleichen Stand wie die Produktion darstellt. Durch das Update im Testfeld kann besser abgeschätzt werden, wie lange die individuellen Updates dauern und ob weitere Vorarbeiten erforderlich sind.

Patch-Prozess

Der Ablauf des Patchen erfolgt in der TestUmgebung und ProduktionsUmgebung identisch und ist pro Server durchzuführen:

  1. Ankündigung/Veröffentlichung der Wartungsarbeiten
    Wenn es ein „schwarzes Brett“ oder einen Verteiler gibt, sollte dort die geplante Wartung angekündigt werden. So sollte Helpdesk und andere Abteilungen darüber Kenntnis haben
  2. Kontrolle der „Gesundheit“
    Es macht keinen Sinn mit Updates anzufangen, wenn nicht alle Systeme „grün“ sind. Die verbleibenden Systeme müssen durch die Unterbrechung des Betriebs eines Servers die Last nicht nur aufnehmen, sondern auch das kurzfristige Anwachsen verkraften.
  3. Geplante „Außerbetriebnahme“ des Server
    Erst dann kann der Server, welcher zum Update ansteht, geplant außer Betrieb genommen werden. Da alle Dienste „hochverfügbar“ sind, sollten die Anwender keine oder nur kurze Unterbrechungen bemerken.
    Die „Außerbetriebnahme“ erfolgt entsprechend der Dienste:
    CAS: z.B. Loadbalancertest.html umbenennen
    DAG: „Schwenken der Datenbanken“
    HuB: Beenden der Dienste
    Zudem muss der Server im Monitoring in den „Wartungsmode“ gestellt werden. Dies verhindert Alarme, Tickets und Eskalationsketten aber es verhindert vor allem auch „Reparaturskripte“ (Automatisch oder durch anderen Admin), die z.B. einen gerade beendeten Dienst wieder starten wollen.
    Dann sollte kontrolliert werden, dass der Server wirklich keine Last mehr hat und die Anwender die anderen Server nutzen, z.B. IISLog, PerformanceCounter
  4. Installation Update/ Anpassungen/Restart
    Nun kann der Server aktualisiert werden. Auch Neustarts sind möglich
  5. Funktionstest mit Client
    Nach der Installation der Updates muss die Funktion des Servers kontrolliert werden. Dies ist je Rolle zu prüfen, z.B.
    CAS: Zugriff eines Client per OWA oder Outlook unter umgehung des LB (z.B. per HOSTS)
    HuB: Kontrolle des Mailfluss
    DAG: Kontrolle der Datenbank Replikation und Clusterhealth
  6. Monitoring
    Die Überprüfungen der Funktion durch SCOM u.a. sind auch in der Wartung aktiv. Sie starten nur keine Eskalation oder Reparatur. Die Meldungen in SCOM sind zu kontrollieren und zu bestätigen.
    Zuletzt wird der Server wieder aus dem Wartungsmodus entfernt. SCOM überwacht nun den Server auch wieder aktiv.
  7. Server wieder in Betrieb nehmen
    DAG: Datenbanken wieder „verteilen“
    CAS: Zugang der Clients wieder freischalten (.z.B. Loadbalancertest.html)
  8. Kontrolle der erfolgreichen Zugriffe durch Clients
    z.B. IISLog, PerformanceCounter
  9. Update der Ankündigung/Statusmeldung 

Weitere Links