12
Gründe GEGEN automatisierte RMM Windows Server Updates (Patchmanagement)
Hallo liebe Admins,
mir wurde die große Ehre zuteil, für unser IT-Dienstleistungsunternehmen eine Kosten- und Risikoanalyse für das oben genannte Thema zu erstellen.
Aktuell werden alle Softwareupdates (auch die Windows Updates) auf allen Kundenservern von Technikern gestaffelt via Fernwartung installiert und die Systeme anschließend getestet bzw. kontrolliert und geplant neu gestartet.
Nun möchte unser Vorstand, dass aufgrund der hohen Zeitersparnis, die Windows Updates via RMM-System (Automox, Ninjaone, Atera, Servereye, etc.) installiert werden.
Wunschvorstellung: die Technikerstunden auf einen Bruchteil reduzieren bei gleichbleibenden Einkünften - soweit (kaufmännisch) nachvollziebar.
Ich wollte mal nach euren Erfahrungen fragen, da hier im Forum bestimmt viele die Windows Updates an Servern über RMM oder WSUS installieren - habt ihr Probleme?
Da es immer noch einige große IT-Dienstleister und auch Unternehmen gibt, die sich bewusst GEGEN ein automatisiertes installieren der Updates über RMM entschieden haben, muss es ja Gründe geben die dagegen sprechen?
Klar kontrolliert man auch bei RMM welche Updates für welche Server freigegeben werden und bestimmt den genauen Installationszeitpunkt und den Zeitpunkt des Neustarts - die Installation und der Neustart passieren dann jedoch ohne Techniker.
Ich habe schon öfter gelesen, dass die bekannten RMM-Tools oft Updates auslassen, teilweise nicht installieren, Fehler nicht korrekt weiter geben usw...
Vielleicht können ja auch mal die berichten, die bereits ein RMM System im Einsatz haben.
Vielen Dank für jeden Beitrag, hoffe ihr habt reichlich Erfahrung mit und ohne Patchmanagement
Lg, Michael
mir wurde die große Ehre zuteil, für unser IT-Dienstleistungsunternehmen eine Kosten- und Risikoanalyse für das oben genannte Thema zu erstellen.
Aktuell werden alle Softwareupdates (auch die Windows Updates) auf allen Kundenservern von Technikern gestaffelt via Fernwartung installiert und die Systeme anschließend getestet bzw. kontrolliert und geplant neu gestartet.
Nun möchte unser Vorstand, dass aufgrund der hohen Zeitersparnis, die Windows Updates via RMM-System (Automox, Ninjaone, Atera, Servereye, etc.) installiert werden.
Wunschvorstellung: die Technikerstunden auf einen Bruchteil reduzieren bei gleichbleibenden Einkünften - soweit (kaufmännisch) nachvollziebar.
Ich wollte mal nach euren Erfahrungen fragen, da hier im Forum bestimmt viele die Windows Updates an Servern über RMM oder WSUS installieren - habt ihr Probleme?
Da es immer noch einige große IT-Dienstleister und auch Unternehmen gibt, die sich bewusst GEGEN ein automatisiertes installieren der Updates über RMM entschieden haben, muss es ja Gründe geben die dagegen sprechen?
Klar kontrolliert man auch bei RMM welche Updates für welche Server freigegeben werden und bestimmt den genauen Installationszeitpunkt und den Zeitpunkt des Neustarts - die Installation und der Neustart passieren dann jedoch ohne Techniker.
Ich habe schon öfter gelesen, dass die bekannten RMM-Tools oft Updates auslassen, teilweise nicht installieren, Fehler nicht korrekt weiter geben usw...
Vielleicht können ja auch mal die berichten, die bereits ein RMM System im Einsatz haben.
Vielen Dank für jeden Beitrag, hoffe ihr habt reichlich Erfahrung mit und ohne Patchmanagement
Lg, Michael
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8013347936
Url: https://administrator.de/contentid/8013347936
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Wir haben ein Ringverteilungssystem mit ACMP aufgebaut. D.h. DEV-Systeme werden gleich am Mittwoch aktualisiert. Danach am Tag X definierte Keyusers und Test-Server und die Woche drauf dann alle verbleibende Systeme. Inzwischen wird 100% der Software über ACMP paketiert, getestet und verteilt bzw. im Self-Service Portal bereitgestellt. War ein langer, steiniger Weg aber mit Beginn der Pandemie Gold wert und es läuft und läuft...
Gruß,
Dani
Wunschvorstellung: die Technikerstunden auf einen Bruchteil reduzieren bei gleichbleibenden Einkünften - soweit (kaufmännisch) nachvollziebar.
kann ich absolut nachvollziehen. Personal wachst nicht auf den Bäumen...Da es immer noch einige große IT-Dienstleister und auch Unternehmen gibt, die sich bewusst GEGEN ein automatisiertes installieren der Updates über RMM entschieden haben, muss es ja Gründe geben die dagegen sprechen?
Kann man sich wenn man wert auf Sicherheit legt, kann man sich das eigentlich nicht mehr leisten. CVEs schießen wie Kartoffeln aus dem Boden. Zumal auch einige ISO Zertifizierungen entscheidend sein kann. Anderseits wie groß ist der Schaden, wenn eine Malware solch ein Netzwerk eindringt und evtl. sogar wochen- oder monatelang nichts mehr geht. Beispiel gab es in den letzten 36 Monate genug - von klein bis groß.Ich wollte mal nach euren Erfahrungen fragen, da hier im Forum bestimmt viele die Windows Updates an Servern über RMM oder WSUS installieren - habt ihr Probleme?
natürlich. Fast jeden Patchday klemmt es irgendwo... das ist einfach ab einer bestimmten Größe, Anzahl von Anwendungen und Eigenentwicklungen normal. Wichtig ist, dass jeder Patch auch wieder deinstalliert werden kann. Was bei der Verwendung von WSUS nicht möglich ist.Wir haben ein Ringverteilungssystem mit ACMP aufgebaut. D.h. DEV-Systeme werden gleich am Mittwoch aktualisiert. Danach am Tag X definierte Keyusers und Test-Server und die Woche drauf dann alle verbleibende Systeme. Inzwischen wird 100% der Software über ACMP paketiert, getestet und verteilt bzw. im Self-Service Portal bereitgestellt. War ein langer, steiniger Weg aber mit Beginn der Pandemie Gold wert und es läuft und läuft...
Gruß,
Dani
Zitat von @SoftBoot:
Da es immer noch einige große IT-Dienstleister und auch Unternehmen gibt, die sich bewusst GEGEN ein automatisiertes installieren der Updates über RMM entschieden haben, muss es ja Gründe geben die dagegen sprechen?
Da es immer noch einige große IT-Dienstleister und auch Unternehmen gibt, die sich bewusst GEGEN ein automatisiertes installieren der Updates über RMM entschieden haben, muss es ja Gründe geben die dagegen sprechen?
Es ist wie bei jedem produktivitätssteigernden Hilfsmittel:
In der einen Variante fallen Lizenzkosten an, und es wird in vergleichsweise geringer Zahl hochqualifziertes Personal benötigt, das Automatisierungskonzepte in großem Maßstab verstehen, verlässlich steuern und überwachen kann. In der anderen fallen keine Lizenzkosten an, und es wird in vergleichweisweise hoher Zahl moderat qualifiziertes Personal benötigt, das einfache repetitive Tätigkeiten ausführt.
Der Arbeitsmarkt sowie die Kosten- und Lohnstruktur wird für Unternehmen in Industrienationen gewöhnlich dazu führen, dass Hilfsmittel und wenig hochqualifiziertes Personal eingesetzt werden.
Grüße
Richard
Zitat von @Dani:
Wichtig ist, dass jeder Patch auch wieder deinstalliert werden kann. Was bei der Verwendung von WSUS nicht möglich ist.
Wichtig ist, dass jeder Patch auch wieder deinstalliert werden kann. Was bei der Verwendung von WSUS nicht möglich ist.
Wie kommst Du zu dieser Aussage? Updates lassen sich doch sogar über den WSUS selbst wieder entfernen.
Oder verstehe ich Dich gerade falsch?
Hallo,
das hat, wie immer mit den Anforderungen und Möglichkeitgen zu tun.
Besonders bei KMUs ohne Testumgebung kann ein fehlerhaftes Update sehr lustige Nebeneffekte haben.
Ich als IT-Dienstleister hatte das damals für ein paar Kunden aktiviert.
Jeweils KMUs mit <5 PCs ohne AD.
Dann kam (natürlich) Murphy um die Ecke.
Ein Kunde hatte nachts seine PCs an, in der Nacht gab es ein fehlerhaftes Updates was Microsoft als Notfallupdate veröffentlich hat. Also haben diese 5 PCs das Update installiert und neu gestartet. Danach zeigten alle nur noch einen blauen Bildschirm.
Ja, ist eine unglückliche Situation.
Eine zentrale Verwaltung und ein zentrales Patchmanagement erhöhen die Sicherheit deutlich.
Aber sie stellen gleichzeitig auch ein Risiko dar über das man sich Gedanken machen muss.
Beim Patchmanagement kann man z.B. eine Testumgebung haben wo Updates n Tage vorher installiert werden.
Stefan
das hat, wie immer mit den Anforderungen und Möglichkeitgen zu tun.
Besonders bei KMUs ohne Testumgebung kann ein fehlerhaftes Update sehr lustige Nebeneffekte haben.
Ich als IT-Dienstleister hatte das damals für ein paar Kunden aktiviert.
Jeweils KMUs mit <5 PCs ohne AD.
Dann kam (natürlich) Murphy um die Ecke.
Ein Kunde hatte nachts seine PCs an, in der Nacht gab es ein fehlerhaftes Updates was Microsoft als Notfallupdate veröffentlich hat. Also haben diese 5 PCs das Update installiert und neu gestartet. Danach zeigten alle nur noch einen blauen Bildschirm.
Ja, ist eine unglückliche Situation.
Eine zentrale Verwaltung und ein zentrales Patchmanagement erhöhen die Sicherheit deutlich.
Aber sie stellen gleichzeitig auch ein Risiko dar über das man sich Gedanken machen muss.
Beim Patchmanagement kann man z.B. eine Testumgebung haben wo Updates n Tage vorher installiert werden.
Stefan
Moin,
Gruß,
Daniel
Wie kommst Du zu dieser Aussage? Updates lassen sich doch sogar über den WSUS selbst wieder entfernen.
Oder verstehe ich Dich gerade falsch?
es gibt Updates die du nicht mehr deinstallieren kannst.Oder verstehe ich Dich gerade falsch?
Gruß,
Daniel
Mahlzeit,
das liegt dann jedoch am Update. Von wo das Update zur Verfügung gestellt wird spielt keine Rolle.
Wenn ich mich nicht ganz irre, gibt es in der API vom WSUS sogar einen Flag der solche Updates kennzeichnet...
Aus technischer Sicht macht es durchaus Sinn Aktualisierungen zu automatisieren, wo es geht.
Gruß
das liegt dann jedoch am Update. Von wo das Update zur Verfügung gestellt wird spielt keine Rolle.
Wenn ich mich nicht ganz irre, gibt es in der API vom WSUS sogar einen Flag der solche Updates kennzeichnet...
Aus technischer Sicht macht es durchaus Sinn Aktualisierungen zu automatisieren, wo es geht.
Gruß
1
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
Denn sollte es zu einem Fehler kommen, bei dem mir mehr Server ausfallen, als ich am Folgetag Techniker zur verfügung habe, habe ich als IT-Dienstleistungsunternehmen ein Problem.
Hier sehe ich den Vorteil bei der manuellen Installation. Werden die Updates durch einen Techniker installiert und dieser stellt während der Installation ein seltsames Verhalten fest oder hat die ersten Fehler, kann er gegensteuern und sich gleich an die Fehlerbereinigung machen bzw. die restlichen Updates aussetzen...
Denn sollte es zu einem Fehler kommen, bei dem mir mehr Server ausfallen, als ich am Folgetag Techniker zur verfügung habe, habe ich als IT-Dienstleistungsunternehmen ein Problem.
Hier sehe ich den Vorteil bei der manuellen Installation. Werden die Updates durch einen Techniker installiert und dieser stellt während der Installation ein seltsames Verhalten fest oder hat die ersten Fehler, kann er gegensteuern und sich gleich an die Fehlerbereinigung machen bzw. die restlichen Updates aussetzen...
Zitat von @SoftBoot:
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
Denn sollte es zu einem Fehler kommen, bei dem mir mehr Server ausfallen, als ich am Folgetag Techniker zur verfügung habe, habe ich als IT-Dienstleistungsunternehmen ein Problem.
Hier sehe ich den Vorteil bei der manuellen Installation. Werden die Updates durch einen Techniker installiert und dieser stellt während der Installation ein seltsames Verhalten fest oder hat die ersten Fehler, kann er gegensteuern und sich gleich an die Fehlerbereinigung machen bzw. die restlichen Updates aussetzen...
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
Denn sollte es zu einem Fehler kommen, bei dem mir mehr Server ausfallen, als ich am Folgetag Techniker zur verfügung habe, habe ich als IT-Dienstleistungsunternehmen ein Problem.
Hier sehe ich den Vorteil bei der manuellen Installation. Werden die Updates durch einen Techniker installiert und dieser stellt während der Installation ein seltsames Verhalten fest oder hat die ersten Fehler, kann er gegensteuern und sich gleich an die Fehlerbereinigung machen bzw. die restlichen Updates aussetzen...
Das ist ja gehüpft wie genudelt...
Sowohl kann man mit einem RMM Updates Kundenweisen timen als auch manuell alle Server parallel (auf einen 4K Monitor bekommt man 10-12 Remote-Sitzungen unter) zu updaten (schrotten).
Und durch die seltenere Installation, erhöht sich das Risiko "neue Freunde" zu bekommen.
Stefan
Moin,
Wichtig ist, dass die Server und Anwendungen mit einer oder mehreren Schablonen geplant, installiert und dokumentiert werden. Vor allem keine individuelle Sonderlocken sondern weitestgehend Standardisierung. Das bringt natürlich kurzfristig einen Mehraufwand mit sich. Langfristig können vorhandene Ressourcen für andere Themen verplant werden. Natürlich gibt es bei jedem Update einer Anwendung x% an Systemen, die ein Problem haben könnten. Aber das ist irgendwann der Menge geschuldet. Darum gibt es eigentlich für kritische Anwendungen auch immer Testsysteme...
Gruß,
Dani
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
man kann hier durch aus parallele ziehen. Es soll Konzerne geben, die über eine zentrale IT unter anderem das UEM für alle Gesellschaften im Unternehmen verwalten und bereitstellen. Da kann es um weit aus mehr als 100.000 Clients und 10.000 Servern gehen.Wichtig ist, dass die Server und Anwendungen mit einer oder mehreren Schablonen geplant, installiert und dokumentiert werden. Vor allem keine individuelle Sonderlocken sondern weitestgehend Standardisierung. Das bringt natürlich kurzfristig einen Mehraufwand mit sich. Langfristig können vorhandene Ressourcen für andere Themen verplant werden. Natürlich gibt es bei jedem Update einer Anwendung x% an Systemen, die ein Problem haben könnten. Aber das ist irgendwann der Menge geschuldet. Darum gibt es eigentlich für kritische Anwendungen auch immer Testsysteme...
Gruß,
Dani
Zitat von @SoftBoot:
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
Wobei man auch etwas differenzieren muss, ob man in einer IT-Abteilung für das eigene Unternehmen tätig ist oder als IT-Dienstleister für eine Vielzahl an Unternehmen.
Die Ökonomie bleibt innerhalb desselben Wirtschaftsraumes dieselbe. Dem fügt sich eure Geschäftsleitung ja gerade.
Rechnungen für das monatliche manuelle Installieren von Updates haben in Deutschland dieselbe Akzeptanz wie ein Tiefbauunternehmen, das mit Spaten auf der Baustelle anrückt, wo ein Bagger Standard ist. Das ist nicht wettbewerbsfähig. Umgekehrt: Man kann es so aufziehen, wenn man genügend Kunden findet, denen das Wie egal ist, und der Preis stimmt. Dann zwingt der Preis aber auch irgendwann zur internen Effizienzssteigerung - gleiches Ergebnis.
Unsere Server werden automatisiert upgedatet, vorher wird aber ein Snapshot gemacht, auf den im Falle eines Fehlers zurückgesetzt werden kann. Nächste Nacht wird der Snapshot gelöscht.
Gleiche Server wie z.B. DHCP Cluster werde aufgeteilt, einer wird an einem Tag upgedatet der andere ein paar Tage später.
Funktioniert bei uns ganz gut.
Gleiche Server wie z.B. DHCP Cluster werde aufgeteilt, einer wird an einem Tag upgedatet der andere ein paar Tage später.
Funktioniert bei uns ganz gut.
Hallo Michael,
wir haben seit Jahren das BatchPatch im Einsatz und installieren bei rund 150 Servern die Microsoft Updates automatisch. Die Updates kommen vom WSUS, wo ich bestimme, was installiert wird und was nicht.
Nach dem Update kommt eine eMail, ob alles "richtig" installiert wurde, oder eben nicht. Da muss dann halt nachgearbeitet werden. Von Hand logischerweise.
Und es braucht halt auch ein gutes Monitoring, welches dann auch anzeigt, wenn etwas nach dem reboot nicht mehr so tut wie es sein sollte.
Für uns hat sich auch bewährt, dass wir die NICHT Microsoft Dienste in der Regel auf "Automatisch verzögert" gestellt haben, um weniger Probleme nach einem Reboot zu haben.
Wir installieren ca. 2 Wochen NACH Veröffentlichung auf der Testumgebung und eine Woche später auf unseren Prod Systeme.
Einzig was ich vermisse, sind die kleinen 3th party Applikationen aktuell zu halten
Also z.B. Acrobat Reader, Notepad++, Winzip, VMware Tool's und solches Gedöns.
Wir setzten in Zukunft auf NinjaOne um eben auch diese 3th party Tools automatisiert zu installieren.
Gründe dagegen sind eher schwer zu finden. Es ist eine Risiko Abwägung.
Immer alles von Hand zu machen ist sehr Zeitintensiv und somit Kostenintensiv und wird dann auch gerne mal vernachlässigt. Und wo Hand angelegt wird, gibt es oft auch Fehler die gemacht werden. Diese kann man bei der Automatisierung eliminieren.
Das Risiko sich etwas "einzufangen", weil man nicht Up to date ist, ist hier vermutlich deutlich grösser.
Und bei uns kommt erschwerend noch hinzu, dass wir ein 7x24 Betrieb sind, wo man nicht immer alles gleichzeitig updaten kann. Sprich sehr viele Server werden NACHTS auf den neusten Stand gebracht. Wenn du hier Dienstleister findest, dann hat dies intensive Kosten zur Folge, die niemand bezahlen möchte.
Es gibt dann noch eine Hand voll Systeme, welche wir dann an einem bestimmten Tag im Monat halbautomatisch installieren, da sie Business Kritisch sind und wir sofort intervenieren können, wenn es nicht so läuft, wie es sollte.
Ich bin der Meinung ohne Automatisierung geht es zukünftig nicht mehr.
Ein Dienstleister hat hier sicherlich immer ein Interesse dies nicht zu tun, bzw. so zu verkaufen, da er dann keine Stunden mehr verkaufen kann.
Viel Spass bei deiner Analyse.
Am Ergebnis wäre ich sehr interessiert.
Gruss Roland
wir haben seit Jahren das BatchPatch im Einsatz und installieren bei rund 150 Servern die Microsoft Updates automatisch. Die Updates kommen vom WSUS, wo ich bestimme, was installiert wird und was nicht.
Nach dem Update kommt eine eMail, ob alles "richtig" installiert wurde, oder eben nicht. Da muss dann halt nachgearbeitet werden. Von Hand logischerweise.
Und es braucht halt auch ein gutes Monitoring, welches dann auch anzeigt, wenn etwas nach dem reboot nicht mehr so tut wie es sein sollte.
Für uns hat sich auch bewährt, dass wir die NICHT Microsoft Dienste in der Regel auf "Automatisch verzögert" gestellt haben, um weniger Probleme nach einem Reboot zu haben.
Wir installieren ca. 2 Wochen NACH Veröffentlichung auf der Testumgebung und eine Woche später auf unseren Prod Systeme.
Einzig was ich vermisse, sind die kleinen 3th party Applikationen aktuell zu halten
Also z.B. Acrobat Reader, Notepad++, Winzip, VMware Tool's und solches Gedöns.
Wir setzten in Zukunft auf NinjaOne um eben auch diese 3th party Tools automatisiert zu installieren.
Gründe dagegen sind eher schwer zu finden. Es ist eine Risiko Abwägung.
Immer alles von Hand zu machen ist sehr Zeitintensiv und somit Kostenintensiv und wird dann auch gerne mal vernachlässigt. Und wo Hand angelegt wird, gibt es oft auch Fehler die gemacht werden. Diese kann man bei der Automatisierung eliminieren.
Das Risiko sich etwas "einzufangen", weil man nicht Up to date ist, ist hier vermutlich deutlich grösser.
Und bei uns kommt erschwerend noch hinzu, dass wir ein 7x24 Betrieb sind, wo man nicht immer alles gleichzeitig updaten kann. Sprich sehr viele Server werden NACHTS auf den neusten Stand gebracht. Wenn du hier Dienstleister findest, dann hat dies intensive Kosten zur Folge, die niemand bezahlen möchte.
Es gibt dann noch eine Hand voll Systeme, welche wir dann an einem bestimmten Tag im Monat halbautomatisch installieren, da sie Business Kritisch sind und wir sofort intervenieren können, wenn es nicht so läuft, wie es sollte.
Ich bin der Meinung ohne Automatisierung geht es zukünftig nicht mehr.
Ein Dienstleister hat hier sicherlich immer ein Interesse dies nicht zu tun, bzw. so zu verkaufen, da er dann keine Stunden mehr verkaufen kann.
Viel Spass bei deiner Analyse.
Am Ergebnis wäre ich sehr interessiert.
Gruss Roland
