Patch-Management für MSPs: eine Patch-Richtlinie für alle Kunden

Sie führen einen MSP. Bei drei Kunden ist Patchen eine Gewohnheit am Dienstagabend: Sie wissen, auf welchem Server die Buchhaltung läuft, welcher Laptop dem Geschäftsführer gehört und wen Sie anrufen, wenn ein Update den Drucker lahmlegt. Beim zehnten Kunden skaliert diese Gewohnheit nicht mehr. Jeder Kunde hat seine Ausnahmen, jeder Techniker gibt Updates ein wenig anders frei, und wenn ein Kunde fragt „Sind wir auf dem aktuellen Stand?“, kostet die Antwort einen Nachmittag.

Dieser Artikel richtet sich an Inhaber und technische Leiter von MSPs, die eine Patch-Richtlinie für alle Kunden wollen: was automatisch freigegeben wird, wie Sie in Ringen ausrollen, wie Sie mit Drittanbieter-Software und Servern umgehen und wie Sie einem Kunden zeigen, wo er steht. Am Ende lesen Sie, wie wir das in Xcellerate RMM umsetzen.

Kurz gesagt

• Schreiben Sie die Richtlinie einmal, je Gerätetyp: Arbeitsplätze, Server und kritische Server bekommen jeweils eigene Wartezeiten, Installationsfenster und Neustartregeln.
• Rollen Sie in Ringen aus: zuerst eigene Testgeräte, dann interne Rechner, dann Pilotkunden, dann alle.
• Patchen Sie Drittanbieter-Software mit demselben Ablauf wie das Betriebssystem, und starten Sie Server nie automatisch außerhalb eines Wartungsfensters neu.
• Geben Sie jedem Kunden einen Monatsbericht: Patch-Status je Gerät, was installiert wurde, was fehlschlug und was Sie bewusst zurückgestellt haben.

Warum Patchen beim zehnten Kunden scheitert

Patchen scheitert selten, weil ein Techniker nicht weiß, wie es geht. Es scheitert, weil die Regeln in den Köpfen stecken. Ein Techniker gibt mittwochs alles frei, ein anderer wartet eine Woche, ein dritter überspringt den Server des Kunden, der sich letztes Jahr über einen Neustart beschwert hat. Nichts ist aufgeschrieben, also ist nichts einheitlich, und niemand kann zeigen, was tatsächlich passiert ist.

Eine Patch-Richtlinie löst das. Sie ist ein kurzes Dokument, idealerweise eine Einstellung in Ihrem RMM, und beantwortet für jedes Gerät vier Fragen: Welche Updates werden automatisch freigegeben, nach wie vielen Tagen, in welchem Zeitfenster, und darf das Gerät selbst neu starten? Sind diese Antworten festgehalten, wird Patchen zu einem Prozess, den Sie prüfen können, statt zu einer Gewohnheit, auf die Sie hoffen.

Die Richtlinie in einer Tabelle

Beginnen Sie bei Gerätetypen, nicht bei Kunden. Die meisten MSPs brauchen drei. Die Zahlen unten sind ein Beispiel zum Anpassen, keine Regel:

Warum überhaupt eine Wartezeit? Einige Tage geben der Community Zeit, ein fehlerhaftes Update zu melden, bevor es Ihre Kunden erreicht. Warum unterschiedliche Fenster? Arbeitsplätze patchen Sie am besten, wenn Pause ist, Server, wenn niemand arbeitet.

Ergänzen Sie dann Ausnahmen je Kunde, nicht je Gerät: Ein Kunde mit Nachtschichten bekommt ein anderes Fenster für seine Arbeitsplätze; ein Kunde mit einer empfindlichen Fachanwendung bekommt seinen Server in die kritische Klasse. Halten Sie jede Ausnahme mit Begründung fest.

Ringe: die eigenen Geräte zuerst

Ein Update-Ring ist eine Gerätegruppe, die Updates in derselben Stufe erhält. Ein einfacher Aufbau für einen MSP hat vier:

1. Testring: einige eigene Geräte, die jedes Update zuerst bekommen.
2. Interner Ring: der Rest Ihres eigenen Büros.
3. Pilotring: ein oder zwei Kunden, die etwas tolerieren, gut dokumentiert sind und wissen, dass sie Pilot sind.
4. Breiter Ring: alle anderen.

Jeder Ring wartet auf den vorherigen. Macht ein Update im Test- oder internen Ring etwas kaputt, blockieren Sie es, bevor es einen Kunden erreicht. Ringe liefern auch eine klare Antwort, wenn ein Kunde fragt, warum er ein Update nicht am ersten Tag bekommen hat: Das ist Absicht.

Drittanbieter-Software ist die eigentliche Lücke

Betriebssystem-Updates sind der einfache Teil: Windows, macOS und Linux haben jeweils ihren eigenen Update-Mechanismus, und die meisten RMMs beherrschen ihn. Die Lücke ist alles andere: Browser, PDF-Reader, Java, Zoom und die übrigen Anwendungen, die Benutzer installieren und niemand aktualisiert.

Behandeln Sie sie wie das Betriebssystem: dieselben Freigaberegeln, dieselben Ringe, dieselben Fenster. Führen Sie je Kunde eine Liste der unterstützten Drittanbieter-Software und entscheiden Sie, was mit dem Rest geschieht (entfernen oder mit einer schriftlichen Notiz beim Kunden belassen).

Server: nie ohne Fenster neu starten

Der schnellste Weg, das Vertrauen eines Kunden zu verlieren, ist ein ungeplanter Neustart mitten am Tag auf dem Server, auf dem seine Fachanwendung läuft. Drei Regeln:

• Keine automatischen Neustarts von Servern außerhalb eines vereinbarten Wartungsfensters.
• Vereinbaren Sie das Fenster schriftlich mit dem Kunden, in der Zeitzone des Kunden.
• Sorgen Sie bei kritischen Servern dafür, dass während des Fensters jemand erreichbar ist, der die Dienste danach prüft.

Der Nachweis: der Bericht, den Ihr Kunde sieht

Eine Richtlinie schafft erst Vertrauen, wenn der Kunde sieht, dass sie wirkt. Schicken Sie jedem Kunden einmal im Monat einen kurzen Patch-Bericht:

• Patch-Status je Gerät: der Anteil der zutreffenden Updates, der installiert ist.
• Was im letzten Monat installiert wurde, und was fehlgeschlagen ist.
• Was Sie bewusst zurückgestellt oder blockiert haben, und warum.
• Geräte, die Aufmerksamkeit brauchen: seit Wochen offline, wartend auf einen Neustart oder nicht mehr unterstützt.

Gehen Sie ihn im monatlichen oder vierteljährlichen Review durch. So wird Patchen von unsichtbaren Kosten zu einer Leistung, die der Kunde sieht.

So machen wir es in Xcellerate RMM

Xcellerate RMM ist unser RMM: source-available unter der FSL, auf Ihren eigenen Servern oder in unserer EU-Cloud. Patch-Management ist Teil des source-available Kerns. So bildet sich die Richtlinie oben darin ab:

• Betriebssysteme und Drittanbieter-Software: Windows Update, apt/yum unter Linux und softwareupdate unter macOS, dazu ein Katalog verbreiteter Drittanbieter-Anwendungen, die demselben Freigabe- und Planungsablauf folgen.
• Patch-Richtlinien je Gruppe: automatische Freigabe, Zurückstellungsfristen, Wartungsfenster und Neustartverhalten, einmal eingerichtet und einer Gruppe zugewiesen. Benannte Patch-Strategien mit eigenen Zeitplänen und Regeln lassen sich jedem Agenten oder jeder Gruppe zuweisen.
• Freigeben, zurückstellen oder blockieren im Stapel: offene Patches über die gesamte Flotte prüfen und ihren Status in einem Vorgang ändern.
• Update-Ringe: Sie wählen, welchem Update-Ring jeder Tenant folgt, damit frühe Builds von Kunden im Produktivbetrieb fernbleiben.
• Details und Verlauf je Gerät: was auf jedem Gerät installiert, ausstehend oder fehlgeschlagen ist, und ein Protokoll jeder Installation mit Ergebnis und Zeitpunkt.
• Compliance-Score und Berichte: der Prozentsatz installierter zutreffender Patches je Gerät oder Gruppe, ein exportierbarer Compliance Report für den Kunden und eine Benachrichtigung, wenn der Score unter einen von Ihnen festgelegten Schwellenwert fällt.

Die Funktionsseite zum Patch-Management gibt den Überblick, und die Dokumentation zum Patch-Management führt Schritt für Schritt durch das Anlegen einer Richtlinie. Sie wollen es auf eigenen Servern betreiben? Die Installationsanleitung beschreibt das Self-Hosting.

Nutzen Sie neben Ihrem RMM auch eine PSA? Xcellerate RMM und Xcellerate OPS sind zwei getrennte Produkte, und eine fertige Verbindung zwischen beiden gibt es noch nicht. RMM + PSA all-in-one oder Best-of-Breed hilft Ihnen zu entscheiden, was Ihr Stack braucht.

Testen Sie die Richtlinie an Ihrer eigenen Flotte: dauerhaft kostenlos auf eigenen Servern oder 14 Tage Cloud-Test. Kostenlos starten