\u201eDiese Kunden mussten nicht darauf warten, dass eine neue Funktion ver\u00f6ffentlicht wird. Stattdessen benutzten sie die Tools, die NinjaOne bereits bereitstellt, darunter Skripting, APIs, benutzerdefinierte Felder und dynamische Richtlinien, und entwickelten genau die L\u00f6sungen, die ihre jeweilige Umgebung erforderte. Darin liegt die St\u00e4rke einer Plattform, die auf Erweiterbarkeit ausgelegt ist: Wenn Sie eine spezifische L\u00f6sung ben\u00f6tigen, stehen Ihnen die erforderlichen Bausteine zur Verf\u00fcgung, um sie sofort umzusetzen, anstatt bis zum n\u00e4chsten Quartal warten zu m\u00fcssen.\u201c<\/p>\n
F\u00fcr die meisten Unternehmen ist Patching kein einfacher Prozess. Change Advisory Boards, stufenweise Rollouts, durch die Konfigurationsmanagement-Datenbasis (CMDB) gesteuerte Wartungsfenster, j\u00e4hrliche Einfrierperioden und Compliance-Kalender f\u00fchren dazu, dass der klassische Patch Tuesday den betrieblichen Anforderungen bei Weitem nicht gerecht wird. K\u00f6nnen die eingesetzten Tools mit diesen Anforderungen nicht Schritt halten, m\u00fcssen IT-Teams h\u00e4ufig Spreadsheets mit manuellen Prozessen verkn\u00fcpfen und darauf hoffen, dass keine kritische Aufgabe \u00fcbersehen wird.<\/p>\n
NinjaOne arbeitet mit Gro\u00dfunternehmen 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\u00f6tigten. Im Folgenden werden zwei dieser Erfolgsgeschichten vorgestellt.<\/p>\n
Ein Gro\u00dfunternehmen hatte \u00fcber Jahre hinweg eine veraltete Plattform f\u00fcr das Konfigurationsmanagement eingesetzt. Die L\u00f6sung erf\u00fcllte zwar ihren Zweck, verursachte jedoch enorme Infrastrukturkosten, da sie dedizierte Server, Verteilungspunkte, Datenbank-Backends und VPN-Verbindungen f\u00fcr Remote-Ger\u00e4te erforderte.<\/p>\n
Das Unternehmen wollte zu NinjaOne wechseln, bef\u00fcrchtete jedoch, dass sein bestehender Patching-Prozess ein kaum \u00fcberwindbares Hindernis f\u00fcr die Einf\u00fchrung darstellen k\u00f6nnte. Es hatte ein stufenweises Rollout-Modell entwickelt, bei dem Patches in mehreren Phasen im gesamten Unternehmen bereitgestellt wurden. Zun\u00e4chst wurden sie in einer kleinen Testgruppe ausgerollt, anschlie\u00dfend auf Erstanwender:innen ausgeweitet, danach in den Unternehmensstandorten implementiert und schlie\u00dflich mehrere Wochen sp\u00e4ter an den Au\u00dfenstandorten installiert. F\u00fcr jede Phase war eine bestimmte Verz\u00f6gerung auf Grundlage des Ver\u00f6ffentlichungszeitpunkts der Microsoft-Patches festgelegt. Dar\u00fcber hinaus durften einige Phasen ausschlie\u00dflich w\u00e4hrend n\u00e4chtlicher Wartungsfenster durchgef\u00fchrt werden, um Beeintr\u00e4chtigungen des Gesch\u00e4ftsbetriebs zu vermeiden.<\/p>\n
Eine derartige Logik nach dem Prinzip \u201eVer\u00f6ffentlichungstag plus N Tage\u201c ist in den meisten Tools f\u00fcr Endpunkt-Management nicht standardm\u00e4\u00dfig verf\u00fcgbar. Auch die drei Plattformen, die das Unternehmen vor NinjaOne gepr\u00fcft hatte, boten diese Funktion nicht.<\/p>\n
Mithilfe der Skripting-Engine von NinjaOne entwickelte der Kunde ein Kontrollskript, das automatisch vor jedem Patch-Zyklus ausgef\u00fchrt wird. Das Skript f\u00fchrt die erforderlichen Datumsberechnungen durch, ermittelt den ma\u00dfgeblichen Ver\u00f6ffentlichungstermin des jeweiligen Monats, ber\u00fccksichtigt die f\u00fcr die Bereitstellungsphase des Ger\u00e4ts festgelegte Verz\u00f6gerung und pr\u00fcft anschlie\u00dfend, 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\u00e4\u00df zu \u00fcberspringen und die Pr\u00fcfung beim n\u00e4chsten Durchlauf erneut vorzunehmen.<\/p>\n
F\u00fcr das Team, das die t\u00e4glichen Patching-Aufgaben verwaltet, vereinfachte das Skript den gesamten Prozess erheblich. Administrator:innen m\u00fcssen keinerlei Code bearbeiten, sondern w\u00e4hlen lediglich die entsprechende Bereitstellungsphase aus einem Dropdown-Men\u00fc in NinjaOne aus. Alle weiteren Schritte \u00fcbernimmt das Skript. Soll die Verz\u00f6gerung f\u00fcr eine bestimmte Gruppe angepasst werden, muss lediglich der entsprechende Wert im Dropdown-Men\u00fc ge\u00e4ndert werden.<\/p>\n
Mittlerweile hat das Unternehmen seine bisherige Patching-Infrastruktur vollst\u00e4ndig au\u00dfer Betrieb genommen. Dedizierte Server und VPN-Verbindungen f\u00fcr Remote-Laptops sind nicht mehr erforderlich. Alle Ger\u00e4te beziehen Patches nun direkt vom jeweiligen Anbieter \u00fcber das Internet. Gleichzeitig beh\u00e4lt das Unternehmen das bew\u00e4hrte stufenweise Rollout-Verfahren bei, jedoch ohne den damit zuvor verbundenen Infrastruktur- und Verwaltungsaufwand.<\/p>\n
Ein Gro\u00dfunternehmen verwaltet eine Anzahl von Servern, die mehrere Betriebssysteme umfasst. F\u00fcr jeden Server in der Umgebung ist in der Configuration Management Database, kurz CMDB, ein Wartungsfenster hinterlegt. Dieser Datensatz enth\u00e4lt den Umgebungstyp, den jeweiligen Wochentag sowie den Zeitraum, in dem das Patching durchgef\u00fchrt werden darf. \u00dcber s\u00e4mtliche Server hinweg ergeben sich daraus mehrere Dutzend unterschiedliche Kombinationen von Wartungsfenstern.<\/p>\n
Eine zus\u00e4tzliche Herausforderung besteht darin, dass der Patching-Kalender nicht auf regelm\u00e4\u00dfig wiederkehrenden Mustern basiert. Stattdessen werden die Patches an konkreten, bereits ein Jahr im Voraus geplanten Terminen eines jeden Monats installiert. Dar\u00fcber hinaus gilt w\u00e4hrend der gesch\u00e4ftlich intensivsten Zeit des Jahres eine j\u00e4hrliche Einfrierperiode, in der keine Patches auf Produktionssysteme angewendet werden d\u00fcrfen. Zudem verf\u00fcgen einzelne Server \u00fcber spezifische Kennzeichnungen. Einige d\u00fcrfen w\u00e4hrend des Patchings nicht neu gestartet werden, andere erhalten ausschlie\u00dflich Neustarts ohne Patch-Installation und wieder andere erfordern eine vollst\u00e4ndig manuelle Bearbeitung.<\/p>\n
Vor der Einf\u00fchrung von NinjaOne verwaltete das IT-Team s\u00e4mtliche Abl\u00e4ufe manuell. Spreadsheets dokumentierten, welche Server zu welchem Zeitpunkt gepatcht wurden, w\u00e4hrend informell weitergegebenes Erfahrungswissen bestehende L\u00fccken schlie\u00dfen musste. So wurden einige Ger\u00e4te \u00fcbersehen und einzelne Patches nicht installiert.<\/p>\n
NinjaOne beseitigte diese Komplexit\u00e4t, indem die CMDB \u00fcber drei aufeinander aufbauende Automatisierungsebenen direkt mit der Richtlinien-Engine von NinjaOne verbunden wurde:<\/p>\n
Mithilfe dieser Automatisierungen kann das Unternehmen s\u00e4mtliche Server automatisch am richtigen Datum, zum richtigen Zeitpunkt und in der vorgesehenen Reihenfolge patchen. Die CMDB bleibt dabei das f\u00fchrende System f\u00fcr die Verwaltung der Wartungsfenster, w\u00e4hrend NinjaOne die darin hinterlegten Vorgaben ohne manuelle Eingriffe umsetzt. Ein Prozess, der zuvor Spreadsheets und zahlreiche Abstimmungsgespr\u00e4che erforderte, l\u00e4uft nun vollst\u00e4ndig automatisiert ab.<\/p>\n
Keiner dieser Kunden forderte NinjaOne dazu auf, eine neue Funktion zu entwickeln. Statt eine Funktionsanfrage einzureichen und auf eine zuk\u00fcnftige Ver\u00f6ffentlichung zu warten, benutzten sie die bereits verf\u00fcgbaren Tools von NinjaOne, darunter Skripting, API, benutzerdefinierte Felder und dynamische Richtlinien, und entwickelten damit genau die Skripte, die ihre jeweilige Umgebung erforderte.<\/p>\n
Darin liegt der Unterschied zwischen einem Tool und einer Plattform. Ein Tool erf\u00fcllt die Aufgaben, f\u00fcr die es entwickelt wurde. Eine Plattform hingegen stellt die erforderlichen Bausteine bereit, um individuelle Anforderungen selbst umzusetzen.<\/p>\n
Enterprise-IT-Teams m\u00fcssen h\u00e4ufig komplexe Patching-Kalender, CMDB-Integrationen, stufenweise Rollouts und betriebliche Einschr\u00e4nkungen ber\u00fccksichtigen, die sich nicht ohne Weiteres \u00fcber ein Dropdown-Men\u00fc abbilden lassen. NinjaOne stellt ihnen die notwendigen Bausteine zur Verf\u00fcgung, um auch solche Anforderungen erfolgreich umzusetzen. Nicht irgendwann, sondern heute.<\/p>\n