„Diese Kunden mussten nicht darauf warten, dass eine neue Funktion veröffentlicht wird. Stattdessen benutzten sie die Tools, die NinjaOne bereits bereitstellt, darunter Skripting, APIs, benutzerdefinierte Felder und dynamische Richtlinien, und entwickelten genau die Lösungen, die ihre jeweilige Umgebung erforderte. Darin liegt die Stärke einer Plattform, die auf Erweiterbarkeit ausgelegt ist: Wenn Sie eine spezifische Lösung benötigen, stehen Ihnen die erforderlichen Bausteine zur Verfügung, um sie sofort umzusetzen, anstatt bis zum nächsten Quartal warten zu müssen.“
Für die meisten Unternehmen ist Patching kein einfacher Prozess. Change Advisory Boards, stufenweise Rollouts, durch die Konfigurationsmanagement-Datenbasis (CMDB) gesteuerte Wartungsfenster, jährliche Einfrierperioden und Compliance-Kalender führen dazu, dass der klassische Patch Tuesday den betrieblichen Anforderungen bei Weitem nicht gerecht wird. Können die eingesetzten Tools mit diesen Anforderungen nicht Schritt halten, müssen IT-Teams häufig Spreadsheets mit manuellen Prozessen verknüpfen und darauf hoffen, dass keine kritische Aufgabe übersehen wird.
NinjaOne arbeitet mit Großunternehmen zusammen, die diesen Kompromiss nicht hinnehmen wollten. Anstatt auf die Umsetzung einer Funktionsanfrage zu warten, verwendeten sie die Skripting-Engine, die API, benutzerdefinierte Felder und Dynamic Policies von NinjaOne, um genau die Patching-Workflows zu entwickeln, die sie benötigten. Im Folgenden werden zwei dieser Erfolgsgeschichten vorgestellt.
Entwicklung eines besseren Patching-Skripts mit NinjaOne
Ein Großunternehmen hatte über Jahre hinweg eine veraltete Plattform für das Konfigurationsmanagement eingesetzt. Die Lösung erfüllte zwar ihren Zweck, verursachte jedoch enorme Infrastrukturkosten, da sie dedizierte Server, Verteilungspunkte, Datenbank-Backends und VPN-Verbindungen für Remote-Geräte erforderte.
Das Unternehmen wollte zu NinjaOne wechseln, befürchtete jedoch, dass sein bestehender Patching-Prozess ein kaum überwindbares Hindernis für die Einführung darstellen könnte. Es hatte ein stufenweises Rollout-Modell entwickelt, bei dem Patches in mehreren Phasen im gesamten Unternehmen bereitgestellt wurden. Zunächst wurden sie in einer kleinen Testgruppe ausgerollt, anschließend auf Erstanwender:innen ausgeweitet, danach in den Unternehmensstandorten implementiert und schließlich mehrere Wochen später an den Außenstandorten installiert. Für jede Phase war eine bestimmte Verzögerung auf Grundlage des Veröffentlichungszeitpunkts der Microsoft-Patches festgelegt. Darüber hinaus durften einige Phasen ausschließlich während nächtlicher Wartungsfenster durchgeführt werden, um Beeinträchtigungen des Geschäftsbetriebs zu vermeiden.
Eine derartige Logik nach dem Prinzip „Veröffentlichungstag plus N Tage“ ist in den meisten Tools für Endpunkt-Management nicht standardmäßig verfügbar. Auch die drei Plattformen, die das Unternehmen vor NinjaOne geprüft hatte, boten diese Funktion nicht.
Vereinfachtes Patching ohne zusätzlichen Infrastrukturaufwand
Mithilfe der Skripting-Engine von NinjaOne entwickelte der Kunde ein Kontrollskript, das automatisch vor jedem Patch-Zyklus ausgeführt wird. Das Skript führt die erforderlichen Datumsberechnungen durch, ermittelt den maßgeblichen Veröffentlichungstermin des jeweiligen Monats, berücksichtigt die für die Bereitstellungsphase des Geräts festgelegte Verzögerung und prüft anschließend, ob das Patching am aktuellen Tag erfolgen soll. Ist dies der Fall, wird der Patch-Vorgang gestartet. Andernfalls weist das Skript NinjaOne an, den Zyklus ordnungsgemäß zu überspringen und die Prüfung beim nächsten Durchlauf erneut vorzunehmen.
Für das Team, das die täglichen Patching-Aufgaben verwaltet, vereinfachte das Skript den gesamten Prozess erheblich. Administrator:innen müssen keinerlei Code bearbeiten, sondern wählen lediglich die entsprechende Bereitstellungsphase aus einem Dropdown-Menü in NinjaOne aus. Alle weiteren Schritte übernimmt das Skript. Soll die Verzögerung für eine bestimmte Gruppe angepasst werden, muss lediglich der entsprechende Wert im Dropdown-Menü geändert werden.
Mittlerweile hat das Unternehmen seine bisherige Patching-Infrastruktur vollständig außer Betrieb genommen. Dedizierte Server und VPN-Verbindungen für Remote-Laptops sind nicht mehr erforderlich. Alle Geräte beziehen Patches nun direkt vom jeweiligen Anbieter über das Internet. Gleichzeitig behält das Unternehmen das bewährte stufenweise Rollout-Verfahren bei, jedoch ohne den damit zuvor verbundenen Infrastruktur- und Verwaltungsaufwand.
Anbindung einer CMDB an NinjaOne für vollständig automatisiertes Patching
Ein Großunternehmen verwaltet eine Anzahl von Servern, die mehrere Betriebssysteme umfasst. Für jeden Server in der Umgebung ist in der Configuration Management Database, kurz CMDB, ein Wartungsfenster hinterlegt. Dieser Datensatz enthält den Umgebungstyp, den jeweiligen Wochentag sowie den Zeitraum, in dem das Patching durchgeführt werden darf. Über sämtliche Server hinweg ergeben sich daraus mehrere Dutzend unterschiedliche Kombinationen von Wartungsfenstern.
Eine zusätzliche Herausforderung besteht darin, dass der Patching-Kalender nicht auf regelmäßig wiederkehrenden Mustern basiert. Stattdessen werden die Patches an konkreten, bereits ein Jahr im Voraus geplanten Terminen eines jeden Monats installiert. Darüber hinaus gilt während der geschäftlich intensivsten Zeit des Jahres eine jährliche Einfrierperiode, in der keine Patches auf Produktionssysteme angewendet werden dürfen. Zudem verfügen einzelne Server über spezifische Kennzeichnungen. Einige dürfen während des Patchings nicht neu gestartet werden, andere erhalten ausschließlich Neustarts ohne Patch-Installation und wieder andere erfordern eine vollständig manuelle Bearbeitung.
Vor der Einführung von NinjaOne verwaltete das IT-Team sämtliche Abläufe manuell. Spreadsheets dokumentierten, welche Server zu welchem Zeitpunkt gepatcht wurden, während informell weitergegebenes Erfahrungswissen bestehende Lücken schließen musste. So wurden einige Geräte übersehen und einzelne Patches nicht installiert.
NinjaOne beseitigte diese Komplexität, indem die CMDB über drei aufeinander aufbauende Automatisierungsebenen direkt mit der Richtlinien-Engine von NinjaOne verbunden wurde:
- Automatisierte Synchronisierung: Ein Skript wird nach einem festgelegten Zeitplan ausgeführt, liest das Wartungsfenster jedes Servers aus der CMDB aus und überträgt die relevanten Informationen in benutzerdefinierte Felder des entsprechenden NinjaOne-Geräts. Wird das Wartungsfenster eines Servers in der CMDB geändert, übernimmt NinjaOne diese Änderung automatisch. Eine manuelle Neuzuweisung von Richtlinien ist daher nicht erforderlich.
- Kalenderbasierte Freigabesteuerung: Einmal jährlich trägt ein Administrator die Starttermine der monatlichen Patch-Zyklen in die benutzerdefinierten Felder von NinjaOne ein. Anschließend gleicht ein täglich ausgeführtes Skript das aktuelle Datum mit diesen Feldern ab und legt anhand eines einzigen Werts fest, ob das Patching durchgeführt werden darf. In einer Patch-Woche für Nicht-Produktionssysteme sind ausschließlich entsprechende Server berechtigt. In einer Produktionswoche gilt dies ausschließlich für Produktionsserver. Während einer Änderungssperre oder einer Woche ohne geplantes Patching werden keine Patch-Vorgänge ausgeführt. Somit lässt sich die gesamte Umgebung über einen einzigen Wert steuern.
- Dynamische Richtlinien mit mehrstufiger Zielgruppendefinition: Für jedes individuelle Wartungsfenster wird eine eigene dynamische Richtlinie eingerichtet. Diese Richtlinien berücksichtigen mehrere Zielkriterien, darunter die Umgebung des Geräts, den zugewiesenen Tag, den festgelegten Zeitraum und den aktuellen Status des Patching-Kalenders. Ein Gerät wird nur dann einer Richtlinie zugeordnet, wenn sämtliche Bedingungen erfüllt sind. Ist die kalenderbasierte Freigabe deaktiviert, erfüllt kein Gerät die Kriterien einer Richtlinie. Sobald sie aktiviert wird, werden ausschließlich die vorgesehenen Server berücksichtigt.
Mithilfe dieser Automatisierungen kann das Unternehmen sämtliche Server automatisch am richtigen Datum, zum richtigen Zeitpunkt und in der vorgesehenen Reihenfolge patchen. Die CMDB bleibt dabei das führende System für die Verwaltung der Wartungsfenster, während NinjaOne die darin hinterlegten Vorgaben ohne manuelle Eingriffe umsetzt. Ein Prozess, der zuvor Spreadsheets und zahlreiche Abstimmungsgespräche erforderte, läuft nun vollständig automatisiert ab.
Das Gesamtbild
Keiner dieser Kunden forderte NinjaOne dazu auf, eine neue Funktion zu entwickeln. Statt eine Funktionsanfrage einzureichen und auf eine zukünftige Veröffentlichung zu warten, benutzten sie die bereits verfügbaren Tools von NinjaOne, darunter Skripting, API, benutzerdefinierte Felder und dynamische Richtlinien, und entwickelten damit genau die Skripte, die ihre jeweilige Umgebung erforderte.
Darin liegt der Unterschied zwischen einem Tool und einer Plattform. Ein Tool erfüllt die Aufgaben, für die es entwickelt wurde. Eine Plattform hingegen stellt die erforderlichen Bausteine bereit, um individuelle Anforderungen selbst umzusetzen.
Enterprise-IT-Teams müssen häufig komplexe Patching-Kalender, CMDB-Integrationen, stufenweise Rollouts und betriebliche Einschränkungen berücksichtigen, die sich nicht ohne Weiteres über ein Dropdown-Menü abbilden lassen. NinjaOne stellt ihnen die notwendigen Bausteine zur Verfügung, um auch solche Anforderungen erfolgreich umzusetzen. Nicht irgendwann, sondern heute.
Erfahren Sie mehr unter https://www.ninjaone.com/de/patch-management/
